Capability Overview
The security industry has crossed a threshold in AI agent deployment maturity: organisations can now discover AI agents operating across their SaaS platforms, developer tooling, cloud workflows, customer support systems, and productivity applications. But the practitioner consensus documented in this analysis is blunt — discovery is a necessary first step, not a sufficient control. The real problem is enforcement: constraining what agents can actually do, in real time, based on verified intent and appropriate privilege.
AI agents are not passive assets. They reason, plan, invoke APIs, call tools, and access data autonomously, without a human in the loop. That fundamentally breaks the assumptions that Identity and Access Management was designed around. Human IAM works because a person has a job function. Service accounts work because they support a defined workload. AI agents are neither — their behaviour is emergent, their tool use is dynamic, and their permission footprint can expand without triggering conventional access review tripwires.
Attack Surface Analysis
The enforcement gap creates several distinct attack vectors that defenders must account for:
Shadow agent proliferation. Agents are appearing in sanctioned tools without security team awareness. An agent embedded in a productivity suite may inherit broad API credentials from the authorising user, creating an invisible, persistent access vector that survives employee offboarding.
Identity and attribution failure. Without consistent identity for each agent, security teams cannot determine which agent performed which action, making incident response and forensic attribution effectively impossible. Attackers who compromise or manipulate an agent gain a deniable pivot point.
Privilege escalation through emergent behaviour. Because agents reason and plan, they may legitimately acquire permissions beyond their original design intent — or be manipulated via prompt injection to do so deliberately. Static entitlement models have no mechanism to detect or prevent this drift.
Supply chain exposure. Agents are increasingly shared, templated, and distributed through third-party platforms. A compromised agent template introduced into an organisation’s workflow can carry malicious tool configurations or data exfiltration logic that bypasses traditional software supply chain controls.
Accountability vacuum enabling insider threats. Agents that operate without audit trails or owner accountability create an attractive vector for insider actors to initiate actions with plausible deniability — the agent did it, not the person.
Framework Mapping
OWASP LLM08 (Excessive Agency) is the primary mapping: agents operating beyond their intended scope without enforcement controls is the textbook definition. LLM07 (Insecure Plugin Design) applies where agents invoke APIs or tools without validated permission boundaries. LLM06 (Sensitive Information Disclosure) is relevant wherever agents access data stores without need-to-know enforcement. LLM05 (Supply Chain Vulnerabilities) covers shared or third-party agent templates.
On the MITRE ATLAS side, AML.T0012 (Valid Accounts) maps to agents operating under legitimate but over-privileged credentials. AML.T0051 (LLM Prompt Injection) is the primary manipulation vector to redirect agent actions. AML.T0010 (ML Supply Chain Compromise) covers poisoned or backdoored shared agent configurations.
Threat Scenarios
Scenario 1 — Credential harvester. An attacker compromises a shared productivity agent template and injects instructions to exfiltrate OAuth tokens to an external endpoint each time the agent authenticates to a corporate SaaS platform. No static access control triggers because the agent is using valid credentials.
Scenario 2 — Insider pivot. An employee with limited direct access deploys an AI agent in a cloud workflow tool, authorising it with their own credentials. The agent autonomously discovers and reads adjacent data stores the employee could not directly access, creating an effective privilege boundary bypass.
Scenario 3 — Orphaned agent persistence. An agent provisioned for a completed project retains its access credentials after the owning employee departs. A threat actor who identifies the orphaned agent can invoke it as a persistent, low-visibility foothold.
Defender Checklist
- Enumerate all AI agents across SaaS, cloud, and developer environments; tag each with an accountable human owner
- Assess every agent’s actual permission scope against its documented purpose — flag and revoke excess entitlements immediately
- Implement agent-specific identity (distinct credentials per agent, not inherited from users) to enable attribution and revocation
- Deploy behavioural monitoring for agent API calls and tool invocations; baseline normal patterns and alert on deviation
- Establish a mandatory access review cadence for agent permissions, triggered by project completion, employee departure, or tool changes
- Evaluate third-party and shared agent templates through a supply chain lens before deployment — treat them as untrusted code
- Define and enforce a prompt injection hardening standard for agents with access to sensitive data or privileged APIs