In March 2025, security researchers at AppOmni disclosed that ServiceNow's Now Assist AI agents could be manipulated into using a higher-privileged coworker agent's permissions to read and exfiltrate records the requesting agent was never authorized to touch — without a single stolen credential. Eighteen months earlier, in September 2023, Wiz Research found that a Microsoft AI research team had accidentally exposed 38 terabytes of internal data because a single overly broad SAS token, generated for an AI training pipeline, granted access to an entire storage account instead of one folder. Neither incident involved a hacker cracking a password. Both involved an autonomous or semi-autonomous system inheriting more privilege than the task required, and then acting on it. That pattern — an AI agent's identity carrying standing, overbroad, or delegated privileges that get abused, whether by an attacker, a bug, or the agent itself — is what security teams now call agentic identity and privilege abuse, and it is quickly becoming the dominant AI security problem for 2026.
What Is Agentic Identity Privilege Abuse?
Agentic identity privilege abuse is what happens when an AI agent's machine identity — its API keys, OAuth tokens, service accounts, or delegated credentials — grants it more access than its current task needs, and that excess access gets exploited. OWASP formalized this in its 2025 Top 10 for LLM Applications as "LLM06: Excessive Agency," defining it as the risk that arises when a system is granted functionality, permissions, or autonomy beyond what its intended operations require. Unlike classic privilege escalation, where an attacker climbs a ladder of exploits to gain admin rights, agentic abuse often needs no exploit at all: the agent already holds a valid, unrevoked credential with wide scope, and either an attacker redirects its actions through prompt injection, or the agent itself misjudges a task and uses the access it was handed. The identity isn't stolen — it's simply too powerful for the job, and something or someone points it at the wrong target.
Why Do AI Agents End Up Over-Privileged in the First Place?
AI agents end up over-privileged because teams provision them the way they provision human employees — broadly, once, and rarely revisit the grant. A developer wiring an agent to Jira, GitHub, Slack, and a cloud console typically issues one OAuth app or one service account with the union of every scope any workflow might eventually need, because scoping narrowly for each individual task is slower to build. CyberArk's 2024 Identity Security Threat Landscape Report found that machine identities already outnumber human identities by roughly 45 to 1 inside the average enterprise, and that ratio is climbing fast as agentic tools multiply — each new agent, plugin, or MCP server typically mints its own credential. Gartner's September 2024 prediction that 33% of enterprise software will embed agentic AI by 2028 means this credential sprawl is not a temporary integration phase; it's the new steady state. Standing privilege, granted once and left active indefinitely, is cheap to set up and expensive to audit — so it rarely gets revisited until something goes wrong.
What Do Real Incidents Show About This Risk?
Real incidents show that agentic privilege abuse doesn't require a sophisticated exploit — a single overscoped token or a piece of untrusted text is often enough. In August 2024, researchers at PromptArmor demonstrated that Slack's AI assistant could be manipulated through a message planted in a public channel: because the AI's query privileges spanned every channel the querying user could theoretically access, a crafted prompt caused it to surface and repeat private API keys and other secrets from channels the attacker had no direct access to. In the ServiceNow Now Assist case from August 2025, AppOmni showed that a "second-order prompt injection" hidden in a case record could hijack an agent's workflow and cause it to invoke another, more privileged agent on its behalf — a textbook confused-deputy attack executed entirely through legitimate, in-scope tool calls. And the September 2023 Microsoft SAS-token leak showed the same root cause without any AI manipulation at all: a machine credential provisioned for one narrow AI training job was scoped to the entire account, and stayed valid for over two years before Wiz flagged it. Three different vectors — prompt injection, agent-to-agent delegation, and simple misconfiguration — but the same underlying failure: identity with more reach than the task warranted.
How Is This Different From Traditional IAM and Insider-Threat Risk?
This differs from traditional IAM risk because the "insider" now acts at machine speed, in machine volume, and often without a human ever reviewing the individual action. A human employee with excessive Salesforce access might misuse it occasionally and leave a slow trail; an AI agent with the same access can be manipulated into exfiltrating, deleting, or modifying thousands of records in the time it takes a person to read one alert. Agents also chain and delegate: a coding agent can call a deployment agent, which can call a cloud-provisioning agent, and a privilege granted three hops upstream can surface in an action nobody explicitly authorized. Simon Willison's widely cited 2025 framing of the "lethal trifecta" captures the mechanics precisely — an agent becomes dangerous the moment it simultaneously has access to private data, exposure to untrusted external content, and a channel to communicate externally. Traditional IAM was built to answer "who can access what," checked at login. Agentic systems need an answer to "what can this specific task, right now, with this specific untrusted input, be allowed to do" — a much harder, continuous question that most identity stacks were never designed to evaluate.
What Does the Confused-Deputy Problem Look Like Inside Agentic Systems?
The confused-deputy problem inside agentic systems looks like a legitimate, high-trust agent being tricked into performing an action on behalf of a party that could never have requested it directly. Classic confused-deputy attacks (the term dates to a 1988 paper by Norm Hardy) required an attacker to find a program with more authority than the caller; agentic AI recreates this at scale because every tool-using agent is, by design, a program with more authority than whoever's message it happens to be processing at that moment. A support agent that can read a customer's order history and also has write access to a refund API becomes a deputy an attacker can confuse with a single crafted support ticket. The 2024 and 2025 wave of MCP (Model Context Protocol) server disclosures made this concrete: security researchers repeatedly found MCP integrations that bundled read, write, and admin scopes into one token because it was easier than issuing three, meaning a single injected instruction could pivot from "summarize this document" to "delete this repository" without crossing any technical permission boundary.
How Can Organizations Detect and Prevent Agentic Privilege Abuse?
Organizations can prevent agentic privilege abuse by treating every agent credential as a distinct, monitored identity rather than a shared utility account — the same discipline applied to service accounts a decade ago, now applied at 45-times the scale. That means issuing narrowly scoped, short-lived tokens per task rather than one standing credential per integration; logging and diffing every tool call an agent makes against its declared intent, not just against a static permission list; and requiring step-up authorization for any action that touches money, data deletion, or external communication, regardless of which agent initiates it. NIST's AI Risk Management Framework and the 2025 OWASP LLM Top 10 both now call out continuous runtime monitoring of agent actions as a control distinct from pre-deployment access review, because a permission that looked reasonable at provisioning time can become dangerous the moment an agent starts processing untrusted input. Inventorying every non-human identity — including the ones spun up automatically by MCP servers, browser-automation agents, and CI/CD pipelines — is the prerequisite step most organizations still haven't completed.
How Safeguard Helps
Safeguard was built for exactly this gap between traditional identity governance and the speed at which agentic systems now operate. Our platform continuously discovers every non-human and agentic identity across your software supply chain — API keys, OAuth grants, service accounts, and MCP server credentials — and maps each one to the actual scope it holds versus the scope its workflow requires, surfacing overprovisioned access before it becomes an incident. Safeguard's runtime monitoring watches agent tool calls in real time, flagging the moment an agent's behavior deviates from its declared task (such as a support agent suddenly invoking an admin-scoped API), so confused-deputy and prompt-injection-driven privilege abuse gets caught in-flight rather than in a post-mortem. For teams building or integrating agentic AI, Safeguard also enforces least-privilege token issuance at the CI/CD and deployment layer, automatically expiring standing credentials and replacing broad grants with task-scoped, short-lived ones. The result is an identity fabric that treats agentic AI the way it deserves to be treated: not as a trusted employee to onboard once, but as a high-volume, high-speed actor whose privileges need continuous verification. If your organization is deploying AI agents faster than your identity team can review their permissions, Safeguard closes that gap before an attacker — or the agent itself — finds it first.