Who is accountable when an AI agent leaks a developer token?

Why This Matters for Security Teams

When an AI agent leaks a developer token, the incident is not just a coding mistake. It is a governance failure over a non-human workload that was allowed to handle secrets without the same controls expected for any privileged identity. Current guidance suggests treating the agent, the broker, and the token lifecycle as one control boundary, because once a token is exposed it can be replayed outside the original trust context.

This is especially important because secrets exposure is still common and slow to resolve. NHIMG research on The State of Secrets in AppSec reports an average 27-day time to remediate a leaked secret, even though 75% of organisations express strong confidence in their secrets management. That gap matters more with agents, because autonomous tool use can move a leaked token from one system to many before anyone notices. The operational lesson is reinforced by the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework, both of which stress runtime control, accountability, and documented oversight.

In practice, many security teams encounter this only after a token has already been used from an unexpected system or automated workflow, rather than through intentional design review.

How It Works in Practice

Accountability sits with the organisation, but operational responsibility should be split across the people and systems that approved access, issued the token, and supervised the agent. The question is less “who caused the leak” and more “which control failed to prevent a delegated identity from handling a developer credential at all.” For autonomous systems, static role-based access is usually too blunt, because the agent’s actions are driven by prompts, tool outputs, and runtime context rather than a fixed human job function.

A better pattern is to issue short-lived, task-scoped credentials and to bind them to workload identity. That means the agent authenticates as a distinct non-human workload, not as a reused developer account. In practice, teams use just-in-time issuance, automatic revocation on task completion, and policy checks at request time. Workload identity systems such as SPIFFE or OIDC-backed service identities are important because they prove what the agent is, while policy engines evaluate what it is trying to do right now. NHIMG’s OWASP Agentic Applications Top 10 and the NHIMG analysis Analysis of Claude Code Security both point to the same operational problem: agents can surface secrets through code generation, tool chaining, or environment access unless guardrails are attached to the action itself.

• Tag the token as a managed secret, not a convenience credential, and require ownership in the broker or control plane.
• Use JIT secrets with narrow scope, low TTL, and automatic revocation after task completion.
• Log agent tool calls, secret access, and downstream API use in a way that supports forensic attribution.
• Block reuse of human developer tokens inside autonomous workflows.

These controls tend to break down in loosely governed CI/CD pipelines because runners, bots, and agents often share execution paths and secret stores.

Common Variations and Edge Cases

Tighter credential controls often increase friction for developers and platform teams, requiring organisations to balance fast autonomous execution against reduced blast radius. That tradeoff is real, especially where agents are used for code review, ticket triage, or incident response and need rapid access to multiple systems.

There is no universal standard for this yet, but current guidance suggests a few patterns. If the leaked token was a personal developer secret, the organisation still owns the exposure because it permitted a non-human actor to handle human credentials. If the token was issued by a broker, accountability extends to the broker design, TTL policy, and revocation workflow. If the agent was acting through a shared service account, the weak point is usually identity segregation, not just storage. The best practice is evolving toward context-aware authorisation, where the decision to release a token is evaluated at runtime based on task, destination, and risk signals, rather than a static allowlist.

For high-risk environments, the issue is compounded by prompt injection, tool chaining, and lateral movement. The agent may not “steal” the token in a human sense; it may simply be allowed to read, copy, or transmit a secret as part of an overbroad workflow. The most relevant lesson from NHIMG’s Moltbook AI agent keys breach and the external CSA MAESTRO agentic AI threat modeling framework is that ownership only works when the agent’s authority is explicitly bounded and revocable.

Related resources from NHI Mgmt Group

• Who is accountable when an AI assistant exfiltrates a repository token from developer tooling?
• Who is accountable when an exposed AI agent gateway leaks secrets and chat history?
• Who is accountable when an AI agent in a pipeline leaks credentials and enables code push access?
• Who is accountable when an AI agent leaks restricted information through paraphrase?