AI agent security risks are outpacing legacy IAM controls

At a glance

What this is: Salt argues that AI agents create a distinct identity and governance problem because they can take actions, call APIs, and execute workflows rather than only generate outputs.

Why it matters: IAM and PAM teams need to treat AI agents as governed identities, because delegated access, tool reach, and shadow deployments can expand risk far beyond traditional application controls.

By the numbers:

• Gartner projects that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% just a few years earlier.
• A Dark Reading survey found that nearly half of cybersecurity professionals view agentic AI as the leading attack vector heading into 2026.

Context

AI agent security risks are emerging because agentic systems can act, not just respond. They call APIs, access applications, retrieve data, and execute workflows, which means identity controls must govern machine actions as well as model outputs.

That shift breaks the assumption that a static application identity is enough. In NHI terms, the governance problem is no longer just access to a service account or token, but the lifecycle, scope, and oversight of a system that can decide when and how to use that access.

Salt's article frames the issue as a control gap between legacy IAM design and autonomous execution across SaaS platforms, cloud environments, and internal workflows. The practical question is whether current identity programmes can actually constrain agent behaviour at runtime.

Key questions

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: Why do over-privileged AI agents create higher business risk than ordinary users?

A: Over-privileged agents can execute many more actions than the task actually requires, so one bad decision can cascade into wrong approvals, refunds, data movement, or API calls. The risk is not just misuse. It is that the agent can act quickly, repeatedly, and without the human timing constraints that limit user mistakes.

Q: What are the signs that AI governance is failing in the enterprise?

A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.

Q: How should security teams handle AI agents that need to log into SaaS applications?

A: Use delegated authorization rather than cloned human sessions. Give the agent a separate identity grant with explicit scopes, short-lived tokens, and revocation. That preserves auditability and lets IAM and PAM teams control what the agent can do without inheriting the user’s full browser session or password material.

Technical breakdown

Why agentic behaviour breaks legacy IAM assumptions

Traditional IAM was designed around predictable request-response systems, where the subject of access is known at provisioning time and the system does not change its own execution path. AI agents are different because they can reason through objectives, choose actions, and call tools across multiple systems. That creates a moving authorisation problem: the same identity may need different access at different moments in the task. Legacy controls struggle here because they govern accounts, not runtime intent. For identity teams, the core issue is not simply whether an agent has access, but whether its access can be bounded tightly enough while its behaviour is still emergent.

Practical implication: treat agent access as runtime governable identity, not a one-time provisioning decision.

How delegated permissions and over-privilege expand agent risk

AI agents often inherit permissions from service accounts, OAuth grants, integrations, or delegated user access. Once those permissions accumulate, an agent can move from a narrow task helper to a broad privileged pathway across data, applications, and cloud actions. The risk is magnified because ownership can become unclear, permissions can outlive the use case, and review cycles often lag deployment speed. This is a classic NHI pattern with a new operating model: the identity is non-human, but the escalation path is human convenience, not malice. Least privilege still applies, but only if scope is explicit and continuously enforced.

Practical implication: inventory inherited permissions and remove any agent access that is broader than the current task scope.

Why tool integrations and prompt injection turn identity into an attack surface

Agent integrations are not just features. They are trust relationships that let the agent consume content, reach tools, and act on external instructions. Prompt injection exploits that trust by embedding malicious instructions in content the agent processes during normal work, while insecure plugins or MCP-style connectors can widen the blast radius if they are compromised or poorly governed. Firewalls and DLP are not enough because the attack targets decision-making, not only transport or file boundaries. Security teams have to evaluate which tools the agent may use, which inputs it may trust, and which outputs can trigger downstream action.

Practical implication: govern every tool and content source as part of the agent's trust boundary.

Threat narrative

Attacker objective: The objective is to turn the agent's legitimate access and tool reach into unauthorised actions that expose data, modify systems, or extend access further into the enterprise.

1. Entry begins when an attacker or malicious content reaches the agent through direct prompt injection, email, a document, a web page, or another retrieved source the system trusts.
2. Credential and tool exposure follow when the agent uses delegated permissions, inherited service-account access, or connected integrations to satisfy the manipulated instruction.
3. Escalation occurs as the agent carries out cross-system actions, exposing data, modifying records, or invoking workflows that were never intended for the original request.
4. Impact is realised when the agent's trusted autonomy produces unauthorised access, data exposure, or downstream business-process abuse at machine speed.

Breaches seen in the wild

• 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.
• 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.

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

AI agent governance is now an identity problem, not just a model-safety problem. The central change is that the system can act through delegated access, tool use, and workflow execution. That places agent behaviour in the same governance family as other non-human identities, but with far less predictable runtime intent. Practitioners should stop treating agent security as an add-on to application security and start governing it as a distinct identity class.

Legacy IAM assumes that access can be bounded at provisioning time, and that assumption breaks under agentic execution. The system does not merely hold credentials; it can select when to use them, which tool to invoke, and how to chain actions across applications. That makes static entitlement review an incomplete control model. The implication is that authorisation needs to follow runtime behaviour, not just assigned roles.

Ephemeral trust debt is the right concept for many agent deployments. Each new integration, OAuth grant, or delegated permission creates a short-lived assumption that someone still knows why the agent has access. When deployment speed outpaces review speed, that trust debt accumulates across SaaS, cloud, and internal workflows. Practitioners should think in terms of how quickly access becomes unjustified, not only how quickly it can be granted.

Shadow AI exposes the offboarding gap already familiar in NHI programmes. If teams cannot discover every AI-connected identity, they cannot certify, recertify, or retire it with confidence. That means the governance failure is not just hidden deployment, but abandoned access that remains active after the original use case has changed. The practitioner conclusion is simple: undiscovered agents are unmanaged identities.

Prompt injection resilience: Agentic systems trust content in ways ordinary applications do not. That creates a governance seam where untrusted text can become an instruction channel, and the security model must assume the agent may act on it unless the boundary is explicit. The implication is that content provenance and tool trust must be treated as first-class identity controls.

From our research library:

• 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, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Ephemeral trust debt: Every delegated grant, connector, and integration adds another assumption that the agent still needs the access it was given. When review cycles lag deployment cycles, that assumption becomes stale before governance can catch up. Security teams should therefore measure how fast access becomes unjustified, not just how fast it was approved.

Agentic AI now forces identity programmes to treat tool use as an authorisation event, not only an application function. That shifts emphasis from broad policy statements to visible ownership, constrained scope, and auditable execution paths across the full delegation chain.

The control gap is most obvious where teams expect static roles to contain dynamic behaviour. Access reviews assume a privilege lasts long enough to be certified; agents can create, use, and discard access inside a single task, so governance has to start at issuance and continue through every integration touchpoint.

For practitioners

• Define agent identities explicitly Classify every AI agent, connector, and delegated integration as a governed non-human identity with a named owner and business purpose.
• Scope agent permissions to one task Remove broad inherited access and bind each agent to the smallest feasible tool set, data set, and workflow path.
• Inventory every AI-connected integration Build a complete register of AI-enabled SaaS features, plugins, API links, and MCP-style connectors before authorising production use.
• Review prompt and content trust boundaries Treat retrieved documents, web pages, tickets, and chat content as untrusted inputs unless the agent is explicitly constrained from acting on embedded instructions.
• Add continuous observability for agent actions Log authentication events, tool calls, workflow triggers, and data access paths so incident response can reconstruct what the agent actually did.

Key takeaways

• AI agents create an identity governance problem because they can act through delegated permissions, tool use, and cross-system workflows, not just generate text.
• The main exposure is not abstract model risk. It is the combination of inherited privilege, shadow deployments, and untrusted content that can steer agent actions.
• Practitioners need discovery, ownership, least privilege, observability, and integration review to keep agent behaviour inside governable boundaries.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Delegated permissions: Delegated permissions are access rights granted through another identity, application, or administrative relationship rather than directly to the end user. They matter because revoking the visible account does not always remove the underlying authority, which can preserve access after offboarding.
• 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.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

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.