AI agent identity risk is outpacing enterprise IAM controls

At a glance

What this is: This is a 2025 cybersecurity predictions post arguing that AI agents will become a new identity risk category because current IAM models do not fit their behaviour.

Why it matters: It matters because practitioners need governance models that handle AI agents alongside human and machine identities without assuming static, reviewable, human-paced access patterns.

By the numbers:

• 82% of executives surveyed by Capgemini plan to implement AI agents within the next three years.
• 99% of the 600 million identity attacks Microsoft logged were password-based.
• Only 44% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Teleport's 2025 cybersecurity predictions on AI agents and identity risk

Context

AI agent identity risk is emerging because the old split between human users and software no longer fits systems that can decide, act, and be manipulated at runtime. In identity governance terms, that breaks the assumption that access can be assigned and reviewed using static categories.

The article frames this as a coming operational problem for security teams, not a distant AI theory. If agents can be phished, tricked, or induced into unsafe actions, then IAM, PAM, and lifecycle controls need to account for a subject that behaves like software in deployment but like a decision-making identity in operation.

For practitioners, the important point is not whether AI agents are novel. It is that they inherit the identity governance burden of both humans and machines while adding new failure modes around prompt injection, social engineering, and consolidated access policy.

Key questions

Q: How should security teams govern AI agents that can change actions at runtime?

A: Security teams should govern runtime AI by correlating identity, data, and intent before trusting an action path. If the system can select tools or alter its sequence mid-session, a static access policy is not enough. The control objective becomes contextual verification of what the agent is doing, why it is doing it, and whether the data touched matches the approved purpose.

Q: What is the difference between least privilege and access review?

A: Least privilege is the design principle that limits access to what is required, while access review is the governance activity that checks whether current access still matches that principle. You need both. One sets the target state, the other detects entitlement drift and exception creep.

Q: What do teams get wrong when they treat AI agents like normal software?

A: The common mistake is assuming agent behaviour is deterministic and fully bounded like a conventional application. In practice, agents can choose actions, follow context, and interact with tools in ways that resemble decision-making identities. That means the control problem is not only application hardening, but access governance for an autonomous runtime actor.

Q: Who is accountable when an AI agent uses delegated access incorrectly?

A: Accountability should follow the delegated authority chain, not stop at the agent label. The relevant owners are the teams responsible for the human identity, the service identity, the workflow, and the policy that allowed the action path. If those responsibilities are not explicit, incident review will be incomplete and remediation will focus on the wrong layer.

Technical breakdown

Why AI agents are vulnerable to identity attacks

AI agents can be manipulated because they interpret instructions, ingest context, and act on inputs that may be adversarial. That makes prompt injection and persona manipulation more than content issues. They become access issues when the agent follows a malicious instruction path into tools, data, or approvals. The technical distinction matters: this is not traditional malware alone, but a control-plane problem where the actor can be steered into harmful execution even without code compromise.

Practical implication: treat agent prompts, tool calls, and retrieved context as identity attack surfaces, not just application logic.

Why identity and access models break for agentic AI

Traditional IAM assumes a subject is either a human user or a machine workload, with access assigned in a relatively stable way. AI agents blur that line because they can hold delegated access, choose actions dynamically, and shift behaviour mid-session. That means authorization is no longer only about who authenticated, but about what the identity can decide to do after authentication. This creates a governance gap around runtime intent, not just credential possession.

Practical implication: map AI agent access around delegated authority and runtime action paths, not around static user or service-account templates.

Why passwords and standing access amplify agent risk

Passwords remain a weak point because they create reusable credentials that can be stolen, replayed, or abused across systems. Standing privilege adds persistence, giving attackers or manipulated agents a broad blast radius once a credential is accepted. In an agentic environment, that problem is worse because the actor may operate continuously and combine access in ways the original provisioning model never anticipated. Identity sprawl plus persistent privilege becomes an execution risk, not just an authentication weakness.

Practical implication: reduce reusable credentials and persistent privilege before scaling agent deployments.

Threat narrative

Attacker objective: The attacker aims to turn a trusted AI agent into a compliant execution path for data theft, unsafe actions, or broader access abuse.

1. Entry occurs when an attacker uses phishing, prompt injection, or manipulated content to influence an AI agent into accepting malicious instructions or following a bad link path.
2. Escalation follows when the agent uses delegated access or reused credentials to reach tools, data, or systems beyond what the operator intended.
3. Impact is the disclosure of sensitive data, unsafe action execution, or lateral movement through connected systems using the agent's legitimate privileges.

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 not a software patching problem, it is a governance model mismatch. Teleport is right to highlight that agents sit between human-like decisioning and machine-like execution. That combination means conventional IAM categories do not capture the actual risk surface. The implication is that identity programmes need a distinct control model for runtime decision-makers, not a rebranded service-account policy.

Identity and access management built on static subject classes will misclassify agent behaviour. Human identity controls assume a person, while workload controls assume deterministic execution. AI agents can hold delegated access and still make context-sensitive choices at runtime, which collapses that distinction. The practical conclusion is that classification, entitlement design, and review processes must be rebuilt around behaviour, not labels.

Passwords and standing privilege create an identity blast radius that agentic systems can magnify. The article's warning about password-based attacks and lateral movement is the right one because reusable credentials turn one compromise into many. When the actor is an agent, the same weakness can propagate at machine speed across tool chains. Security leaders should treat blast-radius reduction as a first-order control objective.

Agentic phishing exposure shows that social engineering is expanding from humans to decisioning systems. That is a material shift for the field because the defender now has to secure the chooser, not only the user. This aligns with OWASP-style agentic risk thinking and with NHI governance principles around delegated access. Practitioners should expect identity security to absorb more of the AI security workload over time.

From our research:

• 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, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
• OWASP Agentic AI Top 10 helps teams map those behaviours to concrete agentic attack patterns and control priorities.

What this signals

Agent identity governance will move from experimentation to operating model work. The organisations that scale AI agents fastest will also inherit the hardest visibility problem, because delegated action is only useful if it can be observed, bounded, and revoked. That is why the governance conversation now belongs in IAM, PAM, and security architecture rather than only in AI labs.

Runtime behaviour is becoming the decisive control surface for agentic systems. The security question is no longer whether an agent is authorised in general, but whether it can safely act within a specific context, against a specific tool, at a specific moment. That is where NHI governance and agentic AI governance begin to converge.

With 80% of organisations already reporting agent actions beyond intended scope, per AI Agents: The New Attack Surface report, the gap is no longer hypothetical. The practical response is to separate broad deployment ambition from narrow privilege design, then build auditability before scale creates irreversible blind spots.

For practitioners

• Define an agent identity class Create a separate identity class for AI agents in inventory, policy, and access review processes so they are not forced into human or workload templates.
• Remove reusable credentials from agent paths Use short-lived, cryptographic authentication and eliminate static passwords or long-lived API keys from agent workflows wherever possible.
• Scope delegated access to task boundaries Bind each agent to narrow, task-specific privileges and explicitly document which tools, data sets, and actions it may reach during execution.
• Review agent prompts and tool links as security inputs Treat prompt content, retrieval sources, and tool integrations as part of the attack surface and monitor them for malicious instruction paths.
• Build rollback and containment steps for agent misuse Predefine how to disable agent credentials, revoke delegated access, and isolate connected systems when an agent acts outside policy.

Key takeaways

• AI agents create an identity governance problem because they can be manipulated into acting outside intended scope while still appearing legitimate.
• The evidence points to a visibility gap in agent access, with many organisations unable to track what their AI agents touch or do.
• Security teams should redesign IAM, PAM, and lifecycle controls around delegated runtime behaviour rather than static identity categories.

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.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

What's in the full article

Teleport's full blog post covers the operational detail this post intentionally leaves for the source:

• Teleport's commentary on why agentic AI is likely to accelerate consolidation across identity and access tooling.
• The full discussion of how treating AI like human identity changes governance assumptions for both machines and employees.
• Teleport's explanation of why password elimination matters alongside standing privilege reduction in agentic environments.
• The source article's forward-looking view on how AI agents may reshape phishing, malware, and social engineering patterns.

👉 Teleport's full post expands on AI agent phishing risk, password removal, and identity consolidation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.