Who should be accountable for governing credentials used by developers, pipelines, and AI agents?

Why This Matters for Security Teams

Accountability for credentials is not a paperwork issue; it is what determines whether a leaked token is detected, rotated, and traced before it is abused. When developers, CI/CD pipelines, and AI agents all use different secrets lifecycles, the real risk is ownership drift: no one knows who can approve, revoke, or attest to the credential state. NHI Management Group’s The State of Secrets in AppSec shows how common this gap is, with only 44% of developers following secrets best practices.

That gap widens in autonomous environments because agents and pipelines do not behave like stable human users. A credential can be used by code, a build job, or an AI agent chaining tools within minutes, so governance has to follow the workload owner, not just the infrastructure team. Standards-based guidance from the NIST Cybersecurity Framework 2.0 still points to clear ownership, but many organisations stop at policy language and never assign operational accountability. In practice, many security teams discover secret misuse only after a pipeline compromise or agent abuse has already expanded access.

How It Works in Practice

The cleanest operating model is shared responsibility with explicit ownership boundaries. Application teams should own the credentials used by their code paths, platform teams should own pipeline and runtime secret delivery mechanisms, and security should define the control baseline, review exceptions, and verify enforcement. That means every secret, token, and certificate needs a named business or engineering owner, an approved purpose, a rotation rule, and a revocation path that works without waiting for a central ticket queue.

For autonomous systems, the model changes further. Current guidance suggests treating AI agents as workload identities with tightly scoped, short-lived access rather than as “users” in a human IAM directory. The practical pattern is: issue just-in-time credentials for a single task, bind them to the agent’s workload identity, evaluate authorization at request time, and revoke automatically when the task completes. This is the direction reflected in the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework.

• Assign one accountable owner per credential set, even when multiple teams can use it.
• Prefer workload identity and ephemeral tokens over shared static secrets.
• Record where each secret is injected, used, rotated, and revoked.
• Use policy-as-code to enforce expiry, scope, and environment restrictions.

This governance model aligns well with the patterns described in NHI research such as Ultimate Guide to NHIs — Static vs Dynamic Secrets and the NIST AI Risk Management Framework, which both emphasize context, traceability, and measurable control. These controls tend to break down in legacy monoliths and ad hoc script sprawl because secret ownership is embedded in code paths no one can inventory quickly.

Common Variations and Edge Cases

Tighter credential governance often increases operational overhead, requiring organisations to balance speed against traceability. That tradeoff is most visible in CI/CD, ephemeral labs, and agentic workflows where developers want fast access but security needs clear approval and revocation authority.

There is no universal standard for this yet, especially for AI agents that act across tools and environments. In some shops, the application owner is accountable for all secrets used by that service, while platform engineering owns shared pipeline secrets and security owns policy exceptions. In others, FinOps, infrastructure, or SRE teams absorb part of the operational burden. The important point is not the title of the team; it is that ownership is explicit, auditable, and tied to the workload that consumes the credential.

Edge cases need special handling. Break-glass credentials may be centrally owned but delegated temporarily. Third-party integrations may require vendor-managed rotation, but the consuming team still owns the risk. For AI agents, static long-lived API keys are increasingly hard to justify because one compromised agent can chain tool calls faster than a human can intervene. NHIMG’s research on the LLMjacking attack pattern and the CI/CD pipeline exploitation case study shows why shared credentials fail first in automated environments.

Related resources from NHI Mgmt Group

• Who should be accountable for NHI governance when applications, pipelines, and AI agents all use credentials?
• How should organizations approach the governance of AI agents?
• How should security teams govern API keys used for generative AI access?
• Who is accountable when AI agents use shared credentials across workflows?