AI agent identity governance needs a hybrid model, not a user clone

At a glance

What this is: The article argues that AI agent identities require a hybrid governance model that borrows from both human identity and service account controls while addressing runtime delegation and behavioural risk.

Why it matters: IAM teams need this distinction because agent governance affects ownership, access review, secrets handling, and revocation across human, NHI, and autonomous-style workflows.

👉 Read Noma Security's analysis of AI agent identity governance and runtime delegation

Context

AI agent identity governance is emerging because agents do not fit cleanly into either human IAM or service account models. They need an owner, they need access reviews, and they need controlled delegation, but they also behave like non-human systems that authenticate, retrieve context, and operate in session.

The core governance problem is not whether an agent is human-like or machine-like. It is that current identity programmes assume access can be provisioned, reviewed, and revoked through stable patterns, while agents can change task scope at runtime and move through delegation chains that shift accountability.

Key questions

Q: How should security teams govern AI agents that inherit authority from other identities?

A: Security teams should govern AI agents by tracking identity lineage, not just credentials. That means recording the originating identity, the delegated authority path, and the runtime context for each action. If an agent can inherit permissions from humans, services, or other agents, policy has to evaluate the full chain before access is granted or continued.

Q: Why do AI agents complicate least-privilege access?

A: AI agents can change their path to a goal, so a role that looks narrow at provisioning time may still be too broad at runtime. Least privilege for agents has to be action-aware, not just role-aware. That means teams need to control not only which systems an agent can reach, but also which actions it can chain together.

Q: What do security teams get wrong about delegation in AI agent workflows?

A: They often assume a delegation chain is just a workflow detail. In practice, each hop can widen blast radius, obscure accountability, and make revocation harder. If the chain is not explicit, an agent can inherit more authority than the human intended, especially when sub-agents and tools are chained together.

Q: Who is accountable when an AI agent takes an unsafe action?

A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.

Technical breakdown

Why AI agent identities create a hybrid governance problem

AI agents combine governance traits from two identity classes. Like humans, they have accountable owners, need periodic review, and may act on behalf of someone else. Like service accounts, they should use non-interactive authentication, vault-backed secrets, and dedicated machine identities. The difference is that agents can vary their behaviour during execution, which means entitlement design cannot be fully fixed at provisioning time. That makes the identity model compositional: part human governance, part NHI governance, plus a runtime layer that neither covers fully.

Practical implication: Treat agent identity as a distinct governance pattern and map each control to either ownership, machine authentication, or runtime behaviour.

Delegation chains and the confused deputy problem in agent workflows

Delegation chains become risky when one agent calls another, which then calls a tool or downstream agent on behalf of a human. If identities are inherited too broadly, the entire chain can operate with permissions that exceed the original intent. The article also highlights the confused deputy problem, where a manipulated agent performs an action the human never explicitly requested. In practice, the threat is not just access misuse, but delegation ambiguity across nested actors and tools.

Practical implication: Track and constrain each hop in the delegation chain so authority does not silently expand across sub-agents and tools.

Why runtime policy matters more for agents than for service accounts

Traditional service accounts are usually governed through static provisioning, review, and rotation. Agents can still use those controls, but they also need enforcement during execution because behaviour can shift mid-session. That is where just-in-time access, session scoping, and behavioural policy converge. The point is not that agents are more privileged by default. The point is that their access needs can emerge while they are already operating, so governance must follow the session, not only the account lifecycle.

Practical implication: Move some access controls from provisioning time into runtime enforcement, especially for task-scoped elevation and tool use.

Threat narrative

Attacker objective: The objective is to induce the agent to take an action that appears authorised while using delegated human permissions.

1. Entry occurs when a human delegates work to an AI agent that can retrieve context and interact with tools on the user’s behalf.
2. Escalation follows when the agent inherits or acquires broader access through a delegation chain, session scoping error, or poisoned retrieval context.
3. Impact occurs when the agent carries out an unintended action with the human’s authority, expanding blast radius across connected systems and data.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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 neither a user problem nor a service account problem alone. Agents inherit the accountability expectations of human identity and the authentication patterns of NHI, but they also introduce runtime behaviour that static IAM models do not describe cleanly. That makes hybrid governance the correct baseline, not an edge case. Practitioners should stop trying to force agents into a single legacy identity category.

Delegation chains are the new identity blast radius. When planning agents, research agents, and tool agents act in sequence, the question is no longer just who owns the first identity. It is how authority expands, persists, and becomes opaque across the chain. This is where governance boundaries collapse unless delegation is explicit, bounded, and revocable at each hop. Teams should treat chained delegation as a first-class control surface.

Runtime manipulation changes the security model more than static provisioning does. A well-provisioned agent can still act unsafely if its session is poisoned or its context is altered mid-execution. That means the real governance gap is not credential issuance alone, but behavioural control during execution. The implication is that review cadences and provisioning workflows are necessary but insufficient for agent governance.

Least privilege for AI agents is a session property, not just an entitlement property. Traditional least privilege assumes access requirements can be determined before execution and remain stable long enough to review. Agents break that assumption because access can emerge from runtime context and tool selection. The practical conclusion is that entitlement design must become task-scoped, time-bounded, and measurable during execution, not only at assignment.

Named concept: runtime delegation drift. This is the point at which authority expands through chained agents, inherited identities, and context-driven tool use beyond the original human intent. It is different from simple privilege creep because it occurs inside a live task rather than across a long lifecycle. Practitioners should recognise it as a distinct governance failure mode, not a variant of standard access sprawl.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• For the broader governance pattern behind this issue, see 52 NHI Breaches Analysis and compare how delegated access failures turn into incident paths.

What this signals

Runtime delegation drift: this is the governance gap most teams are not measuring yet. Once an agent can chain actions, the access question changes from who received the credential to how far that credential can travel before the task ends. The programme implication is that access reviews must start capturing delegation paths, not just assigned entitlements.

The next maturity step for identity programmes is to treat agent sessions as measurable security objects. If teams cannot observe which tools were called, which identities were inherited, and which context sources influenced the action, they cannot defend the blast radius. That pushes IAM, IGA, and PAM teams toward shared controls rather than separate reporting lanes.

Existing NHI patterns still matter, but they are no longer sufficient on their own. Secrets management, vaulting, and least privilege remain foundational, yet agent governance now depends on runtime evidence, revocation speed, and traceability across chained identities. Teams that build those signals early will have a better path to controlling autonomous behaviour later.

For practitioners

• Define a separate agent identity model Classify each agent as a non-human identity with an explicit owner, scoped purpose, and revocation path. Do not allow teams to reuse human credentials or leave the agent’s accountability implicit in a workflow description.
• Bound every delegation chain Document which identity is used at each hop in a multi-agent workflow, including parent agent, sub-agent, and downstream tool. Require revocation logic that can stop a single chain without disabling unrelated work.
• Shift elevation to session scope Issue just-in-time access for task-scoped elevation and expire credentials when the task completes. This is especially important where the agent’s access needs are only known once runtime context is available.
• Add runtime policy to agent sessions Enforce behavioural constraints while the agent is operating, not only during provisioning and review. Control tool calls, retrieval sources, and delegation steps so a manipulated session cannot freely expand its blast radius.

Key takeaways

• AI agent governance cannot be reduced to human IAM or service account hygiene, because agents combine ownership, delegation, and runtime behaviour in one identity model.
• The biggest risk is not just credential exposure, but authority expansion across delegation chains and manipulated sessions.
• Practical control has to move beyond provisioning into task-scoped access, explicit delegation, and runtime policy enforcement.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
• Runtime Policy Enforcement: Runtime policy enforcement evaluates a request at the moment it is executed instead of relying only on preconfigured permissions. For AI agents, this allows decisions to reflect current context, target sensitivity, and behavioural signals rather than static assumptions.
• Task-Scoped Access: Task-scoped access is permission granted for one defined purpose and removed once the task is complete or the session expires. For non-human identities, it reduces standing privilege and limits how long an attacker can exploit a stolen credential.

What's in the full article

Noma Security's full post covers the operational detail this post intentionally leaves for the source:

• A more granular breakdown of how owners, approvers, and revocation responsibilities should be assigned across agent workflows.
• Specific guidance on how to structure delegation chains so sub-agents do not inherit more authority than intended.
• Examples of how just-in-time access can be scoped to task completion rather than static account permissions.
• The article's full discussion of runtime policy enforcement and how it differs from provisioning-time governance.

👉 The full Noma Security post covers delegation chains, confused deputy risk, and the hybrid control model in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.