Who should own governance for AI agent credential custody?

Why This Matters for Security Teams

AI agent credential custody is not a narrow IAM question. It sits at the intersection of identity lifecycle, privileged access, runtime security, and auditability, which is why ownership often breaks down between IAM, PAM, and platform teams. When an agent can request tools, chain actions, and replay credentials outside the intended request path, the risk is no longer just account misuse. NHIMG’s research on agentic risk shows how quickly scope creep becomes operational: in AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already performed actions beyond intended scope.

The practical implication is that custody decisions must account for where secrets are stored, how they are bound to the workload, and who can revoke them in real time. Static ownership models built for human users do not work well for autonomous systems with variable tool use and non-deterministic execution paths. Current guidance from OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework points toward shared accountability, but the control owner still has to be explicit. In practice, many security teams encounter agent credential abuse only after a tool call, data exfiltration, or lateral movement has already occurred, rather than through intentional design.

How It Works in Practice

Effective governance starts by assigning ownership to the control plane, not to a single team name on a chart. IAM typically owns identity lifecycle, issuance, rotation, and revocation policy. PAM owns privileged secret handling, approval workflows, and break-glass procedures. Platform security owns runtime enforcement, workload boundaries, and proof that the credential is only usable by the intended process. This division aligns with the custody problem because the primary question is not merely who created the token, but who can prove where it lives and whether it can be replayed.

For agentic workloads, the emerging pattern is workload identity plus just-in-time access. Instead of long-lived static credentials, agents should receive short-lived tokens tied to a specific task, runtime, and policy context. That model is consistent with the direction of the OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets, which emphasizes dynamic secrets over persistent exposure.

• Bind agent credentials to workload identity, not to a shared account.
• Issue tokens per task with narrow scope and short TTL.
• Store secrets in a controlled broker or vault, not in the agent prompt, code, or local disk.
• Evaluate access at runtime using policy-as-code, with revocation on task completion.
• Log custody, usage, and replay indicators so IAM, PAM, and platform teams can audit the same event stream.

CSA MAESTRO agentic AI threat modeling framework and the NIST Cybersecurity Framework 2.0 both support this operational split because custody must be governed as a lifecycle control, not a one-time provisioning step. These controls tend to break down when agents run across multiple clouds and unmanaged toolchains because the runtime boundary becomes ambiguous and token replay detection loses context.

Common Variations and Edge Cases

Tighter credential custody often increases operational overhead, requiring organisations to balance short-lived access against debugging friction and incident response speed. That tradeoff is especially visible when engineering teams want persistent tokens for testing, or when a high-frequency agent would otherwise need to re-authenticate too often. Current guidance suggests treating those exceptions as temporary and explicitly approved, not as a default architecture.

There is no universal standard for exactly which team must own every agent credential decision. In regulated environments, PAM may retain formal custody of privileged material, while platform security owns runtime enforcement and IAM owns issuance policy. In smaller environments, one function may cover multiple roles, but the control separation still matters. NHIMG’s Guide to the Secret Sprawl Challenge is a useful reminder that secrets multiply quickly when ownership is vague.

For autonomous agents, the main edge case is tool chaining across domains. A token that is safe in one service may become unsafe once the agent can pivot into another system, which is why the MITRE ATLAS adversarial AI threat matrix remains relevant. Best practice is evolving, but the direction is clear: custody should follow the workload, the runtime, and the revocation path, not just the org chart.

Related resources from NHI Mgmt Group

• Why is single-provider AI agent governance not enough for enterprise security?
• Who should own access decisions for AI agent secrets?
• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?