Capability Overview
Token Security has published a practitioner-level analysis identifying agentic AI as a fundamental break in how enterprise identity programs function. The piece, authored by CEO Itamar Apelblat, argues that AI agents are no longer hypothetical — they are already running in production environments, holding OAuth grants, API tokens, and cloud IAM roles that have not been inventoried, reviewed, or scoped appropriately.
The core distinction from prior machine identity challenges is autonomy. Traditional service accounts execute deterministic, predictable tasks. AI agents interpret goals, select execution paths, and operate across multiple systems in a single session. They scale like software, are created by individual developers without central oversight, and accumulate permissions through delegation by end-users rather than formal provisioning. This combination is, as the analysis frames it, a new identity risk class — not an extension of the old one.
For defenders, the relevance is immediate: the credential surface has expanded faster than most identity governance tooling can observe, let alone control.
Attack Surface Analysis
Several new or materially expanded attack vectors are now in play:
Orphaned agent credentials are among the highest-probability risks. Agents are spun up by developers, embedded in SaaS workflows, and left running after the original project concludes. Any long-lived API key or OAuth token attached to an inactive but still-credentialed agent is a persistent attack opportunity.
User-delegated over-privilege is a structural problem. When business users grant agents access to their own accounts and data, they frequently exceed the minimum necessary scope, with no security review in the loop. An attacker who compromises that agent inherits those delegated permissions across every connected system.
Prompt injection as a lateral movement enabler is particularly dangerous in this context. An agent holding valid credentials to multiple systems is a high-value target: a successful injection attack doesn’t just manipulate model output — it weaponises the agent’s legitimate identity to traverse APIs, exfiltrate data, or trigger workflows the attacker could not reach directly.
Shadow agent proliferation mirrors the shadow IT problem of the SaaS era, but with credentials attached. Developers copying or instantiating agents outside sanctioned pipelines create identity blind spots that IAM tools currently have no consistent method to discover.
Framework Mapping
- AML.T0012 (Valid Accounts): Attackers exploiting orphaned or over-privileged agent credentials are operating entirely within legitimate authentication flows — no exploit required.
- AML.T0051 (LLM Prompt Injection): The agentic context makes prompt injection uniquely dangerous; injected instructions can redirect agents to abuse their own valid credentials.
- LLM08 (Excessive Agency): The article’s core thesis maps directly here — agents are being granted far more capability than any individual task requires, with no enforcement boundary.
- LLM07 (Insecure Plugin Design): Agents connecting to databases, APIs, and cloud roles without scoped interfaces introduce the same risks as insecure plugin architectures.
- LLM06 (Sensitive Information Disclosure): Agents with broad data access and no egress controls are high-risk exfiltration vectors.
Threat Scenarios
Scenario 1 — Credential persistence post-project: A developer builds an agent to automate quarterly reporting, grants it read access to financial databases and write access to a cloud storage bucket, then abandons the project. Six months later, a threat actor discovers the still-valid API token via a public code repository commit. The token provides direct access to production financial data with no authentication friction.
Scenario 2 — Prompt injection via email ingestion: An enterprise agent is configured to read and action emails on behalf of a senior executive. An attacker sends a crafted email containing injected instructions. The agent, operating under the executive’s delegated OAuth grant, forwards sensitive documents to an attacker-controlled endpoint using credentials that pass all downstream authentication checks.
Scenario 3 — Privilege escalation via delegation chain: A low-privilege user instantiates a third-party SaaS agent and, to enable its functionality, grants it access to their Microsoft 365 account. That SaaS vendor has not scoped the OAuth grant tightly. The agent accumulates access to shared drives, calendars, and internal communication channels — exposure the user never intended and the security team never reviewed.
Defender Checklist
- Enumerate all AI agents operating in your environment, including those provisioned by individual users or embedded in SaaS tools
- Audit every credential, OAuth grant, API key, and cloud IAM role associated with agent identities; identify those without an active owner
- Enforce credential time-bounding: no agent credential should survive past its operational window without explicit renewal and re-approval
- Apply prompt injection defences at every agent-to-external-system boundary, not just at the model input layer
- Require security review before any agent is granted delegated access to user accounts or production data systems
- Integrate agent identity discovery into existing PAM and secrets management workflows — do not treat agents as a separate programme
- Define and enforce revocation procedures for agents that are decommissioned, transferred, or integrated into new workflows