Who is accountable when non-human identities leak through code, chat tools, or automation pipelines?

The organisation remains accountable, even when the secret was created by developers, operations, or business teams. Security teams may not provision every credential, but they must govern the lifecycle, usage, and revocation of secrets as identities. That means ownership, policy, and monitoring cannot be left to informal team habits.

Why This Matters for Security Teams

Accountability does not move just because a secret appears in source code, a chat assistant, or an automation pipeline. Those channels often create the fastest path from routine work to credential exposure, which is why governance has to cover how secrets are issued, where they are stored, who can use them, and how quickly they are revoked. NHIMG research shows that 96% of organisations store secrets outside dedicated managers in places like code, config files, and CI/CD tools, which turns everyday delivery systems into identity risk surfaces. Guide to the Secret Sprawl Challenge

The practical issue is not whether one team typed the secret, but whether the organisation had controls strong enough to prevent, detect, and contain the leak. That is consistent with NIST SP 800-53 Rev 5 Security and Privacy Controls, which treats access control, auditability, and incident response as organisational responsibilities, not ad hoc habits. In code and chat tools, secrets are easily copied, reused, and embedded into shared workflows, so ownership gaps become exposure gaps. In practice, many security teams learn about leaked NHI credentials only after automation has already used them outside intended scope, rather than through deliberate governance.

How It Works in Practice

Accountability should be assigned at three levels: the organisation, the business or platform owner, and the team that created or introduced the secret. The organisation remains accountable for the control environment; the owning team is accountable for the specific workload or automation that uses the secret; and security is accountable for policy, monitoring, and revocation paths. This is where NHI governance differs from simple password management. Secrets are identities, not just configuration values, so they need lifecycle controls like issuance approval, scope limitation, rotation, and offboarding. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now highlights how often organisations still leave long-lived credentials in exposed systems.

Operationally, the best pattern is to remove human handling wherever possible. Use short-lived, workload-bound credentials for services, chatbots, and automation jobs. That means a pipeline or agent should obtain just enough access for one task, through policy-controlled issuance, and lose that access automatically when the task ends. Current guidance also supports central secret inventories, detection on code repositories and collaboration tools, and fast revocation workflows when a leak is detected. For teams building controls, Anthropic has also documented how AI-enabled operations can accelerate abuse when credentials are exposed, reinforcing the need for tighter runtime controls. A practical sequence looks like this:

• Assign a named business owner for every secret or service account.
• Store credentials in a central secrets manager, not in code or chat history.
• Issue time-bound credentials for pipelines, bots, and agents.
• Monitor for leaks in repositories, tickets, logs, and collaboration tools.
• Revoke and rotate immediately when a secret is exposed.

These controls tend to break down in fast-moving CI/CD environments that allow developers and automation to create new secrets without a shared approval and inventory process.

Common Variations and Edge Cases

Tighter secret governance often increases delivery overhead, so organisations have to balance velocity against the cost of stronger review, rotation, and monitoring. That tradeoff is most visible in software teams, customer-support automation, and AI-enabled workflows where secrets may be generated on demand and used briefly. In those cases, current guidance suggests that the accountable owner should still be the system owner, even when a developer, analyst, or vendor connector introduced the credential.

There is no universal standard for every edge case yet, especially where chat tools, copilots, and multi-agent automation can surface secrets across multiple interfaces. Best practice is evolving toward context-aware policies that answer two questions at runtime: should this identity have access now, and can that access be proven, logged, and revoked quickly? NHIMG’s Reviewdog GitHub Action supply chain attack shows how easily an otherwise normal automation path can become a secret exposure channel. For teams that need a second reference point, the Shai Hulud npm malware campaign is another reminder that code-adjacent tooling can leak NHI credentials at scale.

Related resources from NHI Mgmt Group

• Who should be accountable for risky non-human identity access when automation spans multiple platforms?
• Who should be accountable for third-party non-human identity risk when business tools request elevated access?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?