Who is accountable when developer tools expose secrets through AI or extension workflows?

Why This Matters for Security Teams

When developer tools, extensions, and AI assistants can read source code, environment variables, or build-time context, secrets exposure stops being a narrow engineering issue and becomes an identity governance problem. The real risk is not only that a token is visible, but that a non-human workflow has been granted enough reach to copy, reuse, or exfiltrate it without a clear accountable owner. NHI Management Group research on the Guide to the Secret Sprawl Challenge shows how fragmented secret handling quickly outpaces manual oversight.

That matters because accountability is what determines whether exposure is detected, scoped, rotated, and revoked. If an AI coding assistant, browser extension, or IDE plugin can touch secrets, then the organisation must know which team owns the tool identity, which team owns the underlying secret, and which team can stop access when behaviour changes. NIST’s control structure in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that access and accountability must be explicit, not implied. In practice, many security teams only discover this gap after an extension has already indexed a secret store or an AI assistant has echoed a credential into a chat log.

How It Works in Practice

Practical accountability starts by treating the developer stack as a collection of non-human identities, not just tools. Each AI assistant, extension, CI plugin, and automation bridge should have an owner, a purpose, and a bounded set of permissions. The key question is not whether the tool is “trusted,” but whether its access is narrow enough that a secret cannot be read unless the current task truly requires it. That is where OWASP Non-Human Identity Top 10 becomes useful, because it forces teams to map secret exposure to identity lifecycle, privilege scope, and revocation paths.

In mature environments, accountability is shared but not blurred. Security owns policy and detection. Platform engineering owns the developer toolchain and extension allowlists. Identity or secrets governance owns issuance, rotation, and revocation. That division works only if there is a named control owner for each secret class and each tool identity. NHIMG analysis of the 52 NHI Breaches Analysis repeatedly shows that exposure becomes material when privileged non-human access is left without a revocation path.

• Limit AI and extension scopes to the minimum repositories, files, and environments required.
• Issue short-lived credentials where possible, rather than embedding reusable tokens in developer workflows.
• Log secret reads, prompts, and extension actions so ownership can be traced after exposure.
• Rotate and revoke immediately when a tool, model, or plugin behaviour changes.

This guidance breaks down when legacy developer environments depend on broad shared credentials, because the tool cannot be constrained without disrupting build, test, or release workflows.

Common Variations and Edge Cases

Tighter secret controls often increase friction for developers, so organisations have to balance speed against the cost of uncontrolled exposure. That tradeoff becomes especially visible in AI-assisted coding, where tools may need temporary access to repositories, package registries, or internal documentation to be useful. Current guidance suggests that the safest model is to expose only ephemeral, task-specific secrets and to block direct access to long-lived production credentials, but there is no universal standard for this yet.

Edge cases include local extensions that cache secrets, copilots that summarise private code into chat history, and multi-step agent workflows that chain multiple tools in ways the original approver did not anticipate. Those cases require policy enforcement at the identity layer, not just in the application UI. The emerging pattern is to combine least privilege, JIT access, and explicit owner assignment so the organisation can answer three questions quickly: who approved the access, which identity used it, and who can revoke it now. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is a useful reference for the operational difference between reusable credentials and short-lived access.

In practice, the hardest failures happen in hybrid environments where AI tools, extensions, and CI runners all touch the same secrets store but no single team owns the full path from issuance to exposure.

Related resources from NHI Mgmt Group

• Why do collaboration tools create such a large secrets risk?
• How should security teams reduce risk from AI agents and developer tools that use secrets locally?
• Why do local extension ecosystems increase NHI risk for AI developer tools?
• Who is accountable when sensitive data leaks through consumer AI tools?