Who should be accountable for agent identities in IAM programmes?

Why This Matters for Security Teams

Agent identities are not just another service account. Once an AI agent can decide, chain tools, and trigger actions, accountability must cover the people who approve its purpose, the team that operates it, and the owner who benefits from the outcome. That is where traditional IAM thinking often falls short: it assigns access, but not clear operational ownership for autonomous behaviour. Current guidance suggests treating agent identity as a governed workload with explicit lifecycle control, not an anonymous technical artifact.

This distinction matters because agent-driven actions can create real blast radius quickly, especially when credentials are long-lived or permissions are broader than the task requires. NHI Management Group has shown how weak governance shows up at scale, with only 20% of organisations having formal offboarding and revocation processes for API keys in the Ultimate Guide to NHIs — 2025 Outlook and Predictions. For agentic systems, that gap is more dangerous because the identity itself may initiate lateral movement, secret retrieval, or tool chaining without a human in the loop.

Practitioners should map accountability before deployment, not after an incident. In practice, many security teams discover that agent ownership was unclear only after an autonomous workflow had already changed data, rotated nothing, and left no one clearly responsible for rollback.

How It Works in Practice

Accountability for agent identities should be split across operational and business ownership, with security enforcing the controls that make that accountability real. The business owner defines the intent, approves the use case, and accepts the risk. The technical owner runs the workload, maintains the identity, and is responsible for access review, logging, and retirement. Security or IAM teams set the policy model and verify that the agent only receives the minimum rights needed at runtime.

For autonomous systems, that model is stronger when it is paired with workload identity and runtime authorisation. Instead of assuming a fixed role will remain safe, the platform should prove what the agent is, what task it is trying to perform, and whether the context still justifies access. That is why current guidance increasingly points to short-lived credentials, intent-aware policy decisions, and explicit task scoping, as discussed in the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework.

• Assign a named business owner, technical owner, and security approver before the agent goes live.
• Use ephemeral credentials and rotate or revoke them automatically when the task completes.
• Log every tool call, permission elevation, and data access decision against the owning service ticket or workflow.
• Define retirement criteria so the identity is removed when the use case, model, or pipeline is decommissioned.

The operational anchor is simple: the agent should be able to act only within a policy boundary that is evaluated at request time, not inherited from a broad standing role. That aligns with the NIST AI Risk Management Framework and the runtime control philosophy reflected in the OWASP NHI Top 10. These controls tend to break down in multi-agent pipelines where one agent can inherit another agent’s output and expand privileges faster than the approval chain can react.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance control quality against delivery speed. That tradeoff becomes visible in environments with shared orchestration platforms, multiple model providers, or agents embedded inside CI/CD, where one business owner may not cleanly map to one runtime identity. Best practice is evolving, but there is no universal standard for this yet; many programmes still have to define their own ownership model and escalation path.

A common edge case is the “platform-owned agent,” where a central team runs the infrastructure but a product team depends on the outcome. In that case, accountability should be shared, but not blurred. The platform team owns identity mechanics, while the product team owns purpose and acceptable use. Another variation appears when agents are ephemeral and created per task. Here, accountability should follow the orchestration pipeline, with each temporary identity tied back to a parent service, change record, or workflow run. Emerging guidance from the NIST AI Risk Management Framework supports this kind of traceable governance, while real-world breach reporting such as the Moltbook AI agent keys breach shows what happens when agent credentials exist without clear lifecycle control.

The edge case that matters most is when teams treat an agent like a static service account even though its behaviour is dynamic. That approach usually fails in highly automated environments because the permissions may be technically correct at creation time but become unsafe as soon as the agent starts chaining tools, adapting to prompts, or moving across systems.

Related resources from NHI Mgmt Group

• How can organisations reduce the blast radius of compromised agent identities?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Where does cross-environment agent discovery fit in an IAM programme?
• How should security teams govern Microsoft Agent ID objects as non-human identities?