AI agents inherit the impersonation problem IAM never solved

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Trusona's blog post: AI agents inherit the same impersonation weakness that human identity controls were built to resist, but at machine speed and through non-human credentials.

Why it matters: IAM, IGA, PAM, and NHI programmes need to account for agent identity verification at the moment of action, not only inventory, ownership, and rotation of credentials.

By the numbers:

• The ratio of non-human to human identities is roughly 45 to 1 in a typical enterprise.
• The ratio of non-human to human identities is closer to 144 to 1 in cloud and DevOps environments.
• A 2026 Gravitee survey found that 88% of organisations confirmed or suspected an AI agent security incident in the prior year.
• Only about 22% of organisations treat AI agents as distinct identity-bearing entities.

Context

AI agent impersonation is an identity control problem, not just a secrets problem. Agents can authenticate to APIs, databases, email systems, and cloud services through credentials that behave like non-human identities, but most governance programmes still focus on owning, scoping, and rotating those credentials rather than proving the actor at the moment of access.

That gap matters because the same trust assumptions built for human authentication do not hold when software makes requests continuously and at machine speed. Once shared or unattended credentials are in play, impersonation can look like normal traffic unless the system can verify which agent is actually acting.

The article frames this as the same control failure identity teams spent years addressing for humans, now reappearing in agentic workflows. The issue is typical of current AI agent deployments, not an edge case.

Key questions

Q: What breaks when AI agents are connected through personal accounts or shared credentials?

A: Shared or personal credentials break accountability, lifecycle control, and revocation. If an agent inherits a human account, security teams lose clean ownership and cannot reliably attest what the identity can do or when it should be disabled. That creates an unmanaged backdoor into systems that may persist after the original setup is forgotten.

Q: Why do agent credentials create more risk than traditional IAM models expect?

A: Traditional IAM models assume the identity behind an action is stable enough to inspect, review, or challenge. AI agents can act continuously, reuse the same secrets across workflows, and complete work faster than human review cycles can respond. That makes credential possession an insufficient control unless the system also verifies the actor at the moment of action.

Q: What are the signs that identity governance is failing across SaaS and AI agent environments?

A: Identity governance is failing when local accounts, service accounts, API keys, and OAuth grants exist outside the directory, especially if they have no owner, no expiry, or survive offboarding. Other warning signs include admins without MFA, dormant tokens, over-scoped grants, and application roles that the IdP never sees. Those gaps usually mean the estate is larger than the inventory.

Q: How should security teams respond when agent impersonation is a real concern?

A: They should move beyond discovery and rotation to runtime actor verification for sensitive actions. That means each agent needs a distinct identity, and the system should check the agent against an authoritative source before approval completes. Without that step, shared credentials can make legitimate automation and impersonation look the same.

Technical breakdown

Why credential possession is not identity verification

An AI agent needs credentials to be useful, but possession of a token, key, or password only proves that something holds a secret, not that the intended agent is acting. In human identity, teams eventually learned that asking for a credential is not the same as verifying the caller against an authoritative source. Agentic workflows inherit that same weakness, except the action often happens immediately after authentication and without a human pause. When credentials are shared across multiple agents or services, attribution collapses and the system cannot separate legitimate automation from impersonation.

Practical implication: Treat credential possession as an input to verification, not the verification itself.

Why shared non-human identities make impersonation harder to spot

When multiple agents authenticate as the same identity, the environment loses the ability to distinguish one actor from another. That turns compromise into camouflage because malicious use looks identical to authorised use in logs, telemetry, and downstream workflows. The article notes that many organisations still lean on shared credentials, which means a stolen or spoofed agent can move through ordinary business processes without triggering obvious anomalies. In practice, the security boundary has shifted from access control to actor assurance, and that is a different problem class.

Practical implication: Separate agent identities so that every sensitive action can be attributed to a specific runtime actor.

Why governance alone does not answer the moment-of-action question

Discovery, ownership, scoping, and rotation are governance controls, but they operate before or after the request, not at the moment the agent performs the action. That leaves a verification gap where the system trusts the credential lifecycle but never confirms the current actor. The article’s core point is that this is where identity impersonation detection now has to extend to software agents. The technical challenge is not inventorying more credentials, but binding action approval to an authoritative identity check that cannot be replayed or borrowed.

Practical implication: Add authoritative verification at action time for sensitive agent workflows.

Threat narrative

Attacker objective: The attacker wants to execute sensitive actions through a trusted AI agent identity without being distinguishable from legitimate automation.

1. Entry occurs when an attacker obtains or imitates an agent credential from a log, config file, or shared vault.
2. Credential use follows because the agent identity is reused across services, so the forged actor authenticates as ordinary traffic.
3. Impact appears when the attacker performs account servicing or other sensitive actions through the trusted agent identity, leaving attribution unresolved.

Breaches seen in the wild

• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent impersonation is the control gap that NHI governance alone does not close: ownership, rotation, and scoping are necessary, but they do not prove which runtime actor is actually taking a sensitive action. The article is right to separate hygiene from verification because agentic workflows can present valid credentials while being the wrong actor. The implication is that identity programmes must treat actor assurance as a separate control domain, not a stronger version of credential management.

Shared non-human identities erase attribution before the incident starts: once several agents authenticate as the same thing, logs describe activity but not the specific actor. That is not just a visibility problem, it is a governance failure because accountability becomes impossible to assign cleanly after the fact. For practitioners, the key conclusion is that distinct agent identity is a prerequisite for any credible review, investigation, or approval model.

Identity does not stop at access provisioning when the actor is autonomous: the assumption that a granted credential belongs to a stable, reviewable actor was built for environments where the caller is known and bounded. That assumption fails when an agent acts at machine speed, can request and release access within a workflow, and may complete the action before a human can intervene. The implication is that verification has to move from periodic governance into runtime assurance.

Authoritative verification is becoming the new line between legitimate automation and impersonation: the article effectively describes a new baseline for agent identity assurance, one that sits closer to NHI governance than to traditional human login security. This aligns with OWASP-NHI concerns around insecure authentication and overprivileged non-human access, while also exposing a gap in how enterprises think about actor trust. Practitioners should expect agent assurance to become a separate control layer in identity architecture.

Attribution failure will define the next class of agent incidents: if an organisation cannot say which agent acted, then it cannot prove whether the action was authorised, spoofed, or borrowed. That breaks incident response as much as prevention because the investigation starts after the evidence has already been flattened by shared identity. The field needs to treat agent attribution as a first-order governance outcome, not a forensic afterthought.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Agent attribution is the missing control layer: discovery and rotation are necessary, but they do not solve the runtime question of which agent is actually acting. Programmes that stop at secret hygiene will continue to confuse legitimate automation with impersonation, especially where shared credentials flatten identity into one log trail.

Identity teams need an actor-assurance model, not just a credential model: the core shift is from managing what an agent knows to verifying who is behind the action. That is where runtime assurance, distinct agent identities, and authoritative verification become more important than periodic reviews alone. According to the 2026 Infrastructure Identity Survey, systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident.

For practitioners

• Separate agent identities by runtime actor Stop allowing multiple AI agents to authenticate as a single shared identity when the workflow can move money, reset accounts, or touch privileged systems. Give each agent a distinct identity so attribution survives investigation and approval.
• Bind sensitive actions to authoritative verification Require the system to confirm the actor against an authoritative source before the request completes, especially for high-impact actions that previously relied only on credential possession.
• Review where governance stops before action time Map every place your programme discovers, scopes, and rotates secrets, then identify where those controls do not verify the current agent at the moment of use.
• Eliminate shared credentials from agentic workflows Replace vault-wide or team-wide credentials with agent-specific authentication paths so one compromised secret cannot make every agent look legitimate.
• Instrument attribution for post-incident analysis Log the verified agent identity, the authoritative source used, and the exact sensitive action so investigators can separate legitimate automation from impersonation after the event.

Key takeaways

• AI agents inherit an old impersonation problem, but shared or unattended credentials make it harder to separate authorised automation from a spoofed actor.
• Governance controls such as discovery, ownership, and rotation remain necessary, yet they do not prove which agent is acting at the moment of access.
• Programmes that cannot attribute agent actions to a distinct runtime identity will struggle with both prevention and incident response.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Impersonation Detection: Impersonation detection is the practice of identifying when an authenticated session is being used in ways that do not match the legitimate user’s normal behavior. It relies on usage patterns such as resource sequence, timing, and access scope. The goal is to spot abuse after authentication, where sign-in controls no longer help.
• Managed Non-Human Identity: A managed non-human identity is a machine or application credential whose lifecycle is controlled by a platform or intermediary rather than by the consuming application alone. It can simplify implementation, but the organisation still owns scope, ownership, review, and revocation decisions.
• Runtime Actor Assurance: The ability to verify the acting entity at the moment a request is made, rather than relying on prior registration, ownership, or secret management alone. For autonomous or agentic systems, this is the control that closes the gap between credential possession and true identity assurance.

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.