This also is crucial to keep private tests for contests really private

More ideas:

• Agent is started by container entrypoint
• Agent requests a token from orchestrator
• Orchestrator marks this agent as authenticated in the database
• Agent stores the token in-memory
• Any new authentication attempts from this container/pod are always 401-ed (ID of the container is always known right after its creation so it should have been stored in the DB by the time processes in the container start network activity). Container IDs are inserted into publicly available data (TestExecutions) only after tests are assigned to an agent, i.e. by that time agent should have started and authenticated.

Service can implement app-to-app authentication using basic auth based on attached secrets. In Kubernetes it can be done using empty ServiceAccounts and TokenReview API

Agent pods can have a NetworkPolicy allowing egress to orchestrator and backend pods only, and also to all IPs outside of cluster range.

Two users in the save-agent pod: save-agent (uid 1100) and save-executor (uid 1200). All resources for execution are chown-ed for save-executor. The user save-agent is also a member of save-executor group to be able to read execution results. save-agent should launch save-cli as a user save-executor.
Then, it seems, save-agent can use Kubernetes secrets (namely ServiceAccount token mounted using volume projection) without executed tool having access to them.