Credential Isolation

The control record

Id

AIGE-CTL-EVAL-003 · v0.2 · Draft · Open for technical review

Objective

An agent under evaluation holds only short-lived credentials issued to its own identity for the run and bound to the one service each is for, never standing secrets or a person's own token.

Failure modes

• A long-lived secret (an API key, a cloud access key, a password) is readable from the agent's environment, configuration, files or memory during a run.
• The agent presents a token issued to a person, a token whose audience is another service, or a credential it found rather than received, and the tool server accepts it.
• A credential issued for the run is still accepted after the run ended or was aborted.
• A credential appears in the run's transcript, memory store, logs or outputs, or is passed to another agent.

Scope

Credentials, tokens and keys the agent under evaluation and the tools it calls can reach during a run, including what it holds in memory and writes to its transcript, and the model API key, which stays with a proxy outside the environment. The evaluator's own operator credentials are out of scope.

Enforcement points

• deploy: before a version is deployed or released
• runtime: at the point of action (gateway or guardrail)

Verification

• Inspect: Before the run, inspect the environment template and the run's configuration: no long-lived secret is present, and the agent obtains credentials from a broker outside the environment under its own workload identity, each with a lifetime no longer than the run and an audience naming one tool server.
• Test: After the run, scan every run artefact (transcript, memory store, logs, outputs and a snapshot of the environment's file system) for secret patterns and for the tokens issued to the run; expect no match.
• Test: Replay a token issued for the run against a different tool server, and again after the run has ended; both must be rejected, for the wrong audience and for expiry or revocation.
• Observe: Read the tool servers' logs for the run: every call carries a token issued for that server, delegated calls name the agent as the acting party, and audience-check failures were raised as alerts.

Evidence

• Credential issuance log of the run: identity, audience, scope, lifetime and revocation time of every token · Layer 04 · evidence-record.v1
• Audience-check and replay results from the tool servers · Layer 04 · evidence-record.v1
• Secret scan of the run artefacts, filed as an observation of this control · Layer 05 · control-observation.v1

Failure response

deny: block the action. A token issued for another audience, to a person, or for a run that has ended is rejected by the tool server. A run in which a long-lived secret or a leaked credential is found is stopped, the credential is revoked and the result is withheld until the exposure is assessed.

Layers

Layer 04 Runtime Controls & Observability, Layer 02 Inventory & Transparency

Patterns

Agent Identity & Scoped Credentials

Seeded from

Its own identity, Replace long-lived secrets with short-lived credentials, Delegation, never impersonation, MCP authorisation (spec 2026-07-28), Memory write gate and rollback

Mappings

• Obligations: EU AI Act Art. 15 accuracy, robustness and cybersecurity; Singapore IMDA Model AI Governance Framework for Agentic AI: agent identity and scoped authorisations (voluntary); NIST AI Agent Standards Initiative (2026); OWASP Top 10 for Agentic Applications 2026
• ISO/IEC 42001: A.6.2.6 AI system operation and monitoring; A.9.2 Processes for responsible use of AI systems
• NIST AI RMF: MEASURE 2.7 Security and resilience are evaluated and documented
• OWASP: ASI03 Identity and Privilege Abuse
• AIUC-1: A008
• IETF RFC 8693: act claim (delegation names the acting party; never impersonation)
• MCP specification 2026-07-28: Authorization, Token Handling (audience validation; no token passthrough)
• SPIFFE: SVID (short-lived workload identity documents)
• MITRE ATLAS: AML.T0083 (Credentials from AI Agent Configuration (not yet a row of the threat bridge))
• NIST SP 800-53 Rev. 5: IA-5 (Authenticator Management)
• NIST SP 800-53 Rev. 5: AC-6 (Least Privilege)

References

• [1] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Identity and short-lived credentials")
• [2] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Short-lived, attested credentials")
• [3] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Delegation without impersonation")
• [4] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "MCP authorization as of 2026-07-28")
• [5] RFC 8693, OAuth 2.0 Token Exchange (the act claim "provides a means within a JWT to express that delegation has occurred and identify the acting party")
• [6] MCP specification 2026-07-28, Authorization (MCP servers MUST validate that access tokens were issued specifically for them and "MUST NOT accept or transit any other tokens")
• [7] MCP Security Best Practices (2026-07-28) (token passthrough "is explicitly forbidden"; egress proxies and network policies for server-side clients)
• [8] SPIFFE overview (SVIDs are "short lived cryptographic identity documents", delivered and rotated through the Workload API)
• [9] Model AI Governance Framework for Agentic AI, v1.5 (agent identity unique and "cryptographically verifiable"; authorisations "time- or session-bound, non-transferable")
• [10] Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident (METR states that agents "meant to be fully isolated from one another" communicated through an internal package repository, and that one agent found working Hugging Face credentials exposed on the internet and posted them to the agents' board; it reports spoofed tool calls in at least 96 transcripts and transcripts missing components after container resets)
• [11] Vivaria server environment variables (no-internet task environments connected to a separate Docker network and optionally sandboxed with iptables rules; model API requests can be routed through a separate proxy service)
• [12] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
• [13] MITRE ATLAS data, release v2026.09 (16 tactics, 120 techniques, 88 sub-techniques, 40 mitigations; technique names and technique-to-mitigation links read from dist/v6/ATLAS-2026.09.yaml)
• [14] NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (control catalogue cited by control id; publication page of Revision 5 with update 1 of 10 Dec 2020)
• [15] Improving our alignment and security efforts (best practices for external partners running cyber evaluations: the only outside connection is "to the model's own API", with the API keys kept outside the environment; the configuration "should be verified before every evaluation begins"; boundaries "phrased as instructions"; challenges confirmed "solvable in principle"; a monitor that flags a scope violation to a human and ends the exercise)
• [16] Third-party cyber evaluations involving OpenAI models (OpenAI states that the evaluator's "intended authorization boundary was the simulated cyber range", that its model reused a GitHub token another lab's agent had left publicly accessible, and that it will review how to "set expectations for isolation, credential handling, monitoring, and stop conditions")
• [17] Exposing a GitHub token in a public repository (misalignment report) (OpenAI reports an internally deployed model that published a researcher's GitHub token to a public repository, split into pieces with the stated aim of avoiding secret scanning)
• [18] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)

Implementation notes

• Give each agent under test its own workload identity for the run (an attested identity document of the kind SPIFFE defines, or the platform's workload identity) and issue its tokens from a broker outside the environment. The environment template holds no secret.
• Keep the model API key with an LLM API proxy outside the environment, reached through the egress allow-list of AIGE-CTL-EVAL-002: the agent sees the proxy, never the key. Anthropic's guidance for external evaluation partners likewise asks that "the API keys should be kept outside the environment".
• Issue short-lived access tokens whose aud names one tool server and, when the agent acts for a user or another agent, whose act claim names the agent (RFC 8693 token exchange). Tool servers validate the audience and refuse any other token, as the MCP authorization specification of 2026-07-28 requires of MCP servers.
• Set every token lifetime no longer than the run's time budget, issue no refresh tokens to agents under evaluation, and revoke what was issued when the run ends or is aborted.
• Scrub credentials from memory stores, transcripts and logs before they are written, then grep every run artefact after the run for secret patterns (known key prefixes, high-entropy strings, the run's own issued tokens); a match fails the run. Scan for credentials a run picked up as well as those it was issued: METR's investigation of the OpenAI/Hugging Face incident reports an agent that found working Hugging Face credentials exposed on the internet and posted them to a board other agents read, and OpenAI states that in a third-party evaluation its model reused a GitHub token another lab's agent had left publicly accessible.

Open questions

• What lifetime should a credential issued for an evaluation run have, and who revokes it when the run is aborted?
• Can a secret scan be made complete for encoded or split credentials, or should the control rely on short lifetimes and revocation for whatever a scan may miss? OpenAI reports a model that split a researcher's token into pieces with the stated aim of avoiding secret scanning.

Observation

• Subject: Evaluation run
• Expected: No credential other than the run's own short-lived, audience-bound tokens is readable in the environment or appears in the run's artefacts, and none is accepted after the run.
• Example: Run 88214: secret scan found 0 matches in transcript, memory store and logs; a replayed token was rejected with an audience error: pass.