Who should own secret exposure risk when AI coding agents are in use?

Identity and platform teams should own it together, because the control issue spans machine identity, secret scope, and execution environment. If an agent can reach credentials directly from local state, the accountability failure sits in runtime access design, not only in application code.

Why This Matters for Security Teams

Secret exposure risk is not just a code-quality issue when AI coding agents are in use. The agent can read files, inherit environment variables, call tools, and chain actions faster than a human reviewer can notice. That means the real control problem sits across identity, secret scope, and runtime boundaries, which is why Guide to the Secret Sprawl Challenge is a useful reference point for understanding how quickly credentials proliferate in modern delivery pipelines.

NHIMG’s research on LLMjacking notes that when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes. That speed matters because AI agents often operate in environments where a single leaked token can be reused immediately across repositories, CI jobs, or connected tools. Current guidance suggests this risk should be owned jointly by identity and platform teams, with clear engineering accountability for the execution environment. In practice, many security teams discover the exposure only after an agent has already copied a secret into logs, prompts, or downstream tool calls.

How It Works in Practice

For AI coding agents, ownership should follow the control plane rather than the application team alone. Identity teams are typically responsible for how credentials are issued, scoped, rotated, and revoked. Platform teams are responsible for where the agent runs, what it can mount, what it can read, and which outbound paths it can use. That split reflects the fact that an agent’s access is often mediated by workload identity, not by a person sitting at a keyboard.

Practical controls usually combine short-lived credentials, workload identity, and runtime policy. Instead of placing long-lived secrets in local state, best practice is to issue ephemeral credentials just in time, bind them to the agent workload, and revoke them when the task completes. Standards such as the NIST AI Risk Management Framework and the OWASP Non-Human Identity Top 10 both reinforce the need for governance over non-human access, while implementation patterns often lean on policy checks at request time rather than static permission grants.

• Use workload identity for the agent, not a shared human account.
• Keep secrets out of local files, shell history, and persistent environment variables.
• Prefer short TTL tokens over long-lived keys.
• Apply context-aware controls so the agent only gets what it needs for the current task.
• Log access to secrets, but avoid logging secret values themselves.

NHIMG’s Analysis of Claude Code Security is a good example of why this must be treated as an execution problem, not only a repository hygiene problem. These controls tend to break down in developer laptops and loosely governed sandbox environments because the agent can still reach cached credentials, browser sessions, or inherited cloud profiles.

Common Variations and Edge Cases

Tighter secret controls often increase friction for developers, so organisations have to balance speed against containment. That tradeoff is real, especially where agents need to move across multiple repositories, cloud accounts, or ephemeral CI environments. There is no universal standard for this yet, but current guidance suggests treating the agent’s runtime as the primary blast-radius boundary rather than assuming the repo itself is the boundary.

Edge cases matter. A solo developer using an agent locally may think the application team owns exposure risk, but if the platform layer injects broad credentials into the session, the deeper accountability sits with whoever defined that runtime pattern. In shared enterprise environments, security teams should also account for secret sprawl across package managers, code generation tools, and third-party connectors. The Shai Hulud npm malware campaign shows how quickly secrets can leak once automation touches the software supply chain, while the Moltbook AI agent keys breach illustrates the scale of exposure when agent credentials are not tightly bounded.

Where agent autonomy is high, security ownership should be written into platform policy, not left as an informal shared responsibility. The moment an agent can exfiltrate or reuse a credential without a human-in-the-loop approval step, secret exposure risk becomes a runtime governance issue.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk in non-human identity management?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why are shadow AI agents a risk for enterprises?
• Why do AI agents create more risk when they reuse existing credentials?