A security team identifies that in the current multi-agent system, the orchestrator passes its own GitHub authentication token to sub-agents in environment variables so they can perform API operations. What security risk does this pattern introduce, and what is the correct alternative?

The anti-pattern of passing the orchestrator’s authentication token to sub-agents creates two significant security problems.

Permission scope violation: the orchestrator’s token is scoped to everything the orchestrator needs to do, which may include repository administration, organization management, or other elevated permissions. Sub-agents typically need much narrower permissions. Any sub-agent receiving the orchestrator’s token gains all the orchestrator’s permissions, violating least privilege. That also means sub-agents can perform any action the orchestrator is authorized to perform, giving them broader permissions than they need and creating a single token compromise point.

Blast radius amplification: if any sub-agent is compromised through prompt injection, vulnerability exploitation, or misconfiguration, the attacker obtains the orchestrator’s full-permission token. This is equivalent to compromising the most privileged agent in the system through any one of potentially many sub-agents.

The correct alternative is independent credential isolation: each sub-agent authenticates with its own credential scoped to exactly the permissions it requires. The orchestrator does not delegate its own credential — instead, each agent in the system is independently provisioned with appropriate credentials at deployment time.

The risk that the token may expire, with the alternative of using a token with a longer lifetime, is incorrect because token expiry is a separate concern from the permission scope problem, and extending token lifetime would make the security situation worse, not better.

The risk that environment variable injection may fail in some execution environments, with the alternative of storing the token in a shared database that all agents query, is incorrect because storing the token in a shared database makes the credential accessible to any agent or service that can query the database, which is potentially a larger blast radius. It also does not address the core permission scope problem.

The risk that sub-agents may log the token value, with the alternative of encoding the token with base64 before passing it, is incorrect because base64 encoding is not encryption. Base64-encoded values are trivially decoded by any process that reads them. This provides zero security benefit — it is security theater.