AI agent identity governance is breaking the user-account model

At a glance

What this is: This is Aembit's analysis of how enterprises are handling AI agent identity and access, with survey findings showing that current IAM models blur agent and human activity.

Why it matters: It matters because IAM, IGA, and PAM teams now need to govern an actor that can reuse human or workload identity without clean accountability or least-privilege boundaries.

By the numbers:

• Based on a survey of more than 200 organizations, the findings point to a clear gap between how access is granted and how it is actually used once agents are introduced.

👉 Read Aembit's analysis of AI agent identity and access governance

Context

AI agents are becoming production actors before most identity programmes have a clean way to distinguish them from humans or service accounts. In this article, Aembit argues that the real security gap is not whether access exists, but whether the organisation can tie that access to the right actor and explain what it did.

That problem cuts across IAM, IGA, PAM, and audit because inherited permissions and shared identities weaken accountability at the point of action. The first control question is no longer whether access was technically authorised, but whether the identity model is specific enough to govern the actor that actually executed the work.

Key questions

Q: How should security teams govern AI agents that reuse human or service account identities?

A: Security teams should give AI agents distinct identities and task-scoped access instead of reusing human credentials or shared service accounts. When the same identity can represent multiple actors, attribution, approvals, and investigations all become unreliable. Governance should start with a clear actor model, then tie permissions and audit evidence to that actor specifically.

Q: Why do AI agents complicate least privilege in IAM programmes?

A: AI agents complicate least privilege because they often inherit permissions from the identities they use, rather than receiving access designed for their own task boundary. That makes the effective permission set broader than the runtime need. Teams should assess privilege at the agent level, not assume inherited access is sufficiently narrow.

Q: What breaks when AI agents and humans share the same access model?

A: When AI agents and humans share the same access model, organisations lose clean attribution, stronger approval boundaries, and reliable review evidence. The access may be technically valid, but the governance model cannot say who initiated the action with enough confidence. That weakens incident response, recertification, and accountability.

Q: Should organisations revoke agent access after detection or redesign it up front?

A: Redesigning access up front is the better control point. Revocation and token disablement can stop ongoing activity, but they do not correct the underlying problem that access was defined too broadly or for the wrong actor. The strongest programmes place identity separation and request-scoped access before execution begins.

Technical breakdown

Shared identities obscure AI agent accountability

When AI agents run under shared service accounts, workload identities, or human credentials, the system can often confirm that an action was authorised without revealing who or what initiated it. That breaks the basic chain between identity, session, and action. The problem is not only logging fidelity. It is that the identity itself is no longer a stable proxy for the actor, so investigations, approvals, and recertification all lose precision. If the same credential can represent a person in one moment and an agent in the next, attribution becomes an inference exercise rather than a control outcome.

Practical implication: assign distinct identities to AI agents so attribution, approval, and investigation are tied to the correct actor.

Inherited permissions create agentic overreach

The article shows that agents often inherit permissions from the identities they use, rather than receiving access designed for their own task boundary. That means least privilege is being inferred from a parent identity instead of expressed for the agent's actual runtime behaviour. In IAM terms, this is a scope mismatch. The access is valid in the directory or cloud control plane, but it is not tailored to the action sequence the agent will perform. As agents take on more responsibility, inherited access scales badly because every new use case expands the blast radius of the underlying identity.

Practical implication: define access at request time for the agent, not by reusing broader permissions from another identity.

Post-access controls do not fix pre-granted risk

Teams commonly respond by monitoring behaviour, adding manual approval steps, revoking tokens, disabling identities, or terminating the environment after something looks wrong. Those actions can stop activity, but they do not solve the governance problem that access was granted before the system understood the actor. This is a control-placement issue. Detection and containment sit after authorisation, so they cannot prevent overbroad access from existing in the first place. As agent responsibility grows, post-access intervention becomes harder to scale because it relies on human interpretation of machine-paced behaviour.

Practical implication: move governance upstream so access decisions are specific before the agent starts acting.

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 cannot remain a sidecar to human IAM. The survey findings show that enterprises are still grafting agents onto identity models built for people and static service accounts. That produces blurred attribution, inherited privilege, and weak accountability because the actor is changing faster than the governance model. Security teams should treat agent identity as a first-class governance problem, not an extension of user administration.

Inherited permissioning is creating an identity blast radius that most organisations are not measuring. When an agent borrows access from a parent identity, the effective permission set is larger than the task requires and harder to reason about after the fact. That is not simply excess access, it is access whose scope is hidden inside another identity boundary. The practitioner implication is that blast radius must be assessed at the actor level, not only at the credential level.

Distinct agent identities are becoming a prerequisite for trustworthy investigation and certification. If 68% of organisations cannot clearly separate agent actions from human actions, then recertification and audit evidence are already operating with ambiguous inputs. The governance assumption that a credential maps cleanly to a single accountable subject is no longer reliable once agents share execution paths with humans. Teams need to rethink how identity evidence is produced before they can trust review outcomes.

Access decisions built for request-response workflows do not fit runtime-selecting actors. Even when authorisation is technically enforced, the article shows that control is often applied after access has already been granted and used. That means identity governance is being asked to supervise behaviour it did not shape. The field is moving toward request-scoped access, clearer agent separation, and better visibility, but the core lesson is structural: AI agents expose the limits of human-paced identity governance.

From our research:

• 96% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• The next step is to align agent governance to identity evidence, not just behaviour monitoring, through OWASP NHI Top 10.

What this signals

Identity blast radius: when agents inherit access from broader identities, the control problem shifts from privilege assignment to privilege inheritance, and that is harder to see in standard IAM reviews. With only 52% of companies able to track and audit the data their AI agents access, the governance gap is already operational, not theoretical.

Programmes that still rely on user-centric recertification will miss the actor ambiguity introduced by agents. The more practical path is to align agent identity separation, request-scoped access, and auditability before usage scales further, especially where policy teams need a clean chain of custody for action traces.

For practitioners

• Separate agent identities from human identities Create dedicated identities for AI agents so their actions, sessions, and audit trails are not blended with user activity or shared workload accounts.
• Scope access to the agent's actual request Replace inherited permission patterns with access defined at the point of request, using the narrowest entitlements needed for the specific action sequence.
• Review shared service accounts for agent use Find where agents are operating under human credentials, shared service accounts, or workload identities, then map each case to a distinct owner and purpose.
• Move approval before execution starts Reduce reliance on after-the-fact token revocation and environment termination by placing policy checks before the agent begins a task that can affect systems or data.

Key takeaways

• AI agents are exposing a structural mismatch between human-era identity models and machine-paced execution, which weakens attribution and accountability.
• The article reports that 68% of organisations cannot clearly distinguish agent actions from human actions, while nearly three-quarters say agents receive more access than they need.
• The control priority is distinct agent identities and task-scoped authorisation before execution, not after-the-fact revocation alone.

Key terms

• Agent Identity: An agent identity is the distinct identity assigned to an AI agent so its actions can be attributed separately from a person or shared workload account. In practice, it is the governance anchor for permissions, logging, approvals, and investigation when autonomous or semi-autonomous software is taking actions in production.
• Inherited Permissions: Inherited permissions are access rights an actor receives indirectly from the identity it uses rather than from access defined for that actor's own task. In AI agent environments, this often creates hidden overreach because the effective privilege set belongs to the parent identity, not the agent's actual job boundary.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and actions exposed when a single identity is overprivileged or reused across actors. For AI agents, the blast radius grows when shared accounts or broad workload identities mask which actor actually exercised the access.
• Task-Scoped Access: Task-scoped access is permission granted only for the specific action sequence a subject needs to complete a defined job. For agents, it means access should be tied to request context and runtime purpose, not to a broad reusable identity that can be repurposed across sessions.

Deepen your knowledge

AI agent identity separation and task-scoped access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for shared credentials and workload identities, it is worth exploring.

This post draws on content published by Aembit: AI agent identity and access in enterprise environments. Read the original.