IAM adapts to secure AI agents through accountable identity

At a glance

What this is: Descope’s post argues that AI agents need accountable identity patterns because conventional IAM controls do not fully cover agentic runtime behaviour.

Why it matters: IAM teams, NHI owners, and identity architects need to treat AI agents as governed actors because their access, delegation, and audit requirements differ from both human users and static machine identities.

👉 Read Descope's analysis of accountable identity for AI agents

Context

AI agent governance is the problem of assigning, constraining, and auditing software entities that can act on behalf of a business process. In this context, traditional IAM breaks down when the actor can choose tools, chain actions, or operate outside a human session boundary. That creates a governance gap for identity programmes that were built around people or fixed service accounts.

For practitioners, the issue is not whether an agent can authenticate, but whether its identity can be governed across the full action path. Descope uses the language of accountable identity to frame that problem, which is useful because AI agents sit at the intersection of NHI, delegation, and runtime policy enforcement.

Key questions

Q: How should security teams govern AI agent identities in existing IAM programmes?

A: Treat AI agents as governed actors with their own ownership, scope, and audit trail rather than as ordinary service accounts. Define what each agent may do, which tools it may call, and who is accountable for its actions. If the programme cannot reconstruct behaviour after the fact, it is not governing the agent, only issuing credentials.

Q: Why do AI agents complicate traditional identity governance?

A: AI agents complicate identity governance because their actions can vary at runtime, even when the underlying identity stays the same. That makes static entitlement reviews less reliable, since the real risk sits in delegated decision-making, tool choice, and session behaviour rather than in the mere existence of an account.

Q: What breaks when an AI agent is managed like a normal service account?

A: Ownership, auditability, and revocation discipline usually break first. A normal service account model assumes a predictable workload and a stable purpose, but an agent may chain actions, change tools, or continue operating outside the original intent. That leaves security teams with a credential they can see but behaviour they cannot explain.

Q: Who should be accountable for AI agent access decisions and outcomes?

A: Accountability should sit with the business owner of the agent, the technical team that operates it, and the identity team that enforces the policy boundary. If any of those roles is missing, the organisation loses clear ownership for approvals, exceptions, and incident response when the agent acts outside expectations.

Technical breakdown

Accountable identity for AI agents

Accountable identity means the system can link an agent’s actions back to a governed identity, a purpose, and a scope of delegated authority. For AI agents, that is harder than for service accounts because the actor may choose actions at runtime, call multiple tools, and continue a task across several steps without a fresh human approval gate. In practice, this pushes identity design toward durable auditability, scoped delegation, and clear ownership for every action path. The architectural problem is not just authentication, but attribution and containment when the identity behaves like an independent actor.

Practical implication: Practitioners need identity records that preserve action provenance, not just login events.

MCP, tool access, and delegated runtime risk

When AI agents use tool frameworks such as MCP, the key security issue is not the protocol itself but the authority boundary around the tools it exposes. If an agent can discover tools dynamically, choose among them, and execute without a human checkpoint, the identity layer must control both scope and timing of access. That changes the risk model from static privilege assignment to runtime authorisation. The result is a broader attack surface, because tool access can become a path to data exposure, unintended actions, or escalation through chained requests.

Practical implication: Teams should treat tool exposure as a privileged boundary and map every agent tool to explicit policy.

Agentic identity governance versus classic machine identity

Classic machine identity governance assumes the workload is mostly deterministic. Credentials can be issued, rotated, revoked, and recertified around a known function. AI agents break that assumption because the same identity may behave differently from one session to the next based on prompts, context, or tool availability. That means the identity is not just a secret to manage. It is an actor whose behaviour must be monitored against policy. This is why agentic governance needs stronger lifecycle controls, tighter audit evidence, and explicit ownership across the delegation chain.

Practical implication: Identity teams should separate ordinary workload identity handling from agent-specific governance and review.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent identity is not just NHI with a new label. The governance problem changes when a software actor can choose actions at runtime rather than merely execute fixed jobs. That means authentication, rotation, and revocation remain necessary but no longer sufficient as the primary control model. The practitioner conclusion is that agent identity must be governed as an active decision-making subject, not a static credential holder.

Accountable identity is the right lens because auditability must follow the action path. An agent can only be governed effectively if the organisation can reconstruct what it accessed, why it accessed it, and which authority chain allowed it to do so. Without that, access reviews become post-event paperwork instead of control evidence. The practitioner conclusion is that provenance, ownership, and scope must be built into the identity record from the start.

Runtime delegation is the named concept this category now needs. AI agents inherit privileges through systems that were designed for pre-authorised machine actions, but their behaviour can change within a session. That means the real governance gap is not credential issuance alone, it is the absence of controls over delegated runtime decisions. The practitioner conclusion is that IAM programmes must model the identity path, not only the credential lifecycle.

Lifecycle governance for agents must be aligned to behaviour, not employment analogies. Human JML assumptions do not map cleanly to software actors that can be paused, reconfigured, or replaced without a person leaving the company. Treating them like human accounts or ordinary service identities leaves ownership unclear and offboarding weak. The practitioner conclusion is that agent lifecycle controls need explicit operational triggers, not inherited HR-style processes.

Descope’s framing reflects a broader market shift toward governance overlays for agentic systems. As AI agents proliferate, the control point moves upward from secret handling to policy, delegation, and evidence. That direction aligns with where identity security is heading across NHI and agentic AI. The practitioner conclusion is to expect more overlap between IAM, PAM, and agent governance, not less.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which helps explain why identity governance often lags behind operational change.
• For a broader lifecycle view, read Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs to connect provisioning, rotation, and offboarding to this control gap.

What this signals

Runtime delegation is becoming the operational fault line for identity teams. As agentic systems spread, the risk shifts from simple credential sprawl to decisions made inside a session that may never look like a traditional access request. Organisations that keep agent identity inside a human-style review model will miss the behaviour that matters.

With 80% of identity breaches involving compromised non-human identities, the boundary between static machine access and agentic control is no longer academic. The practical response is to align IAM, PAM, and audit evidence around delegated action paths, not just account inventories.

If the agent can select tools and execute without a human gate, then the governance model has to treat that session as a privileged event. That is why programmes should track provenance and ownership together, using the Ultimate Guide to NHIs , 2025 Outlook and Predictions to anticipate where current controls will age out first.

For practitioners

• Define agent ownership and purpose boundaries Assign a named business owner, a technical custodian, and a documented purpose for each agent identity so every action path has accountable oversight. Tie those records to review cadence and incident response ownership.
• Map every agent tool to explicit policy Inventory the tools an agent can reach, then classify each one by data sensitivity, privilege level, and approval requirement before enabling runtime use. Keep the policy separate from the prompt or model configuration.
• Separate agent identity from ordinary workload identity Do not fold AI agents into generic service-account handling. Give them separate lifecycle rules for provisioning, pause, offboarding, audit retention, and exception handling so their behaviour can be governed as an actor, not just a credential.
• Build provenance into every delegated action Record which identity, policy, and tool decision allowed each action so security teams can trace behaviour after the fact. That evidence should be usable for review, investigation, and access certification.

Key takeaways

• AI agent identity changes the governance problem because the actor can make runtime decisions, not just consume pre-issued access.
• The key control gap is provenance and delegation visibility, since static entitlement reviews do not explain agent behaviour well enough.
• IAM teams should separate agent-specific lifecycle and audit controls from ordinary service-account handling before scale turns the gap into default practice.

Key terms

• Accountable Identity: A governed identity model that links an actor’s actions to a named owner, a defined purpose, and a traceable scope of authority. For AI agents, the model must support post-action reconstruction, because behaviour can vary at runtime even when the identity stays the same.
• Runtime Delegation: The process by which an identity is allowed to choose actions, tools, or next steps while a task is in progress. In AI agent environments, runtime delegation is risky when it is broad, opaque, or disconnected from explicit policy, because the resulting behaviour may exceed the original intent.
• Provenance Trail: A record that shows which identity, policy, tool, and approval path led to a specific action. For autonomous or agentic systems, provenance is a control asset, not just an audit convenience, because it determines whether security teams can explain and contain behaviour after the fact.

Deepen your knowledge

AI agent identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for delegated runtime behaviour, this is a practical place to start.

This post draws on content published by Descope: How We Built Accountable Identity for Shuni, Our AI Coding Agent. Read the original.