Your organization runs five Copilot agents (code review, issue triage, release notes, dependency updates, and security scanning) all configured to use the same shared GitHub App installation token stored in a central secrets manager. A security audit identifies this as a risk. What is the primary security concern with this architecture?
Select an answer to reveal the explanation.
Short Explanation
You're giving five agents one master credential, so a breach in any one agent exposes the full token across all five use cases. You can't revoke just the compromised agent without disrupting the others. Give each agent its own scoped token.
Full Explanation
Token isolation is a security architecture principle that mirrors least privilege at the credential level. When five agents share a single token, the blast radius of compromise is large: if the code review agent is exploited via prompt injection, the attacker now holds a token with the combined capabilities of all five agents, including security scanning privileges that can potentially read vulnerability data. It also creates an inability to revoke selectively: if the token is compromised, revoking it disrupts all five agents simultaneously, while per-agent tokens let you revoke the compromised agent's token while the other four continue operating. A shared token creates audit ambiguity because all five agents appear identical in the GitHub audit log, making it impossible to attribute a specific action to a specific agent. It also prevents scope creep control because each agent's token can be scoped to exactly the repositories and permissions it needs, while a shared token must accommodate the union of all five agents' requirements, which is invariably broader than any single agent needs. The correct architecture is to provision a separate GitHub App installation or separate fine-grained PAT for each agent, scoped to only that agent's repositories and permissions. The network-latency concern is an operational concern unrelated to the primary security risk. The claim that GitHub App tokens cannot be shared across multiple processes is incorrect; GitHub App tokens can be retrieved and used by multiple processes, so the issue is a security antipattern rather than a technical prohibition. The central secrets manager being a single point of failure for secret retrieval is a separate availability concern, not the primary security vulnerability identified by the shared-token architecture.