Capability Overview
As AI agent deployments scale across enterprise environments, they are generating a class of machine identity — credentials, OAuth tokens, service accounts, and workload identities — that existing identity governance frameworks were never designed to manage. A Netwrix-sponsored analysis published in July 2026 quantifies the scope: machine identities already outnumber human users by as many as 50 to one in many organisations, and AI agents are accelerating that ratio further. Unlike human identities, agent credentials do not follow predictable lifecycle events. They can be created dynamically, inherit permissions from parent processes, and persist long after the automation that spawned them has been retired. Most organisations cannot answer basic questions about who owns these identities, why they remain active, or what systems they can reach.
This is not a theoretical concern. The UNC6395 campaign in 2025 demonstrated the concrete impact: attackers obtained a single OAuth token tied to Salesloft’s Drift integration and used it to traverse Salesforce environments across hundreds of victim organisations, then pivoted to AWS credentials and Snowflake tokens stored outside vault controls. The token was not exploited through a software flaw — it was already trusted.
Attack Surface Analysis
AI agents introduce several compounding risks that defenders must assess independently:
Identity sprawl at machine speed. Unlike a human hire, an AI agent can create subordinate identities, spawn child processes, and request API access programmatically. Each of these actions may produce a credential that never appears in a traditional identity governance review.
Inherited over-privilege. Agents frequently inherit permissions from the service accounts or OAuth scopes used to instantiate them. If that parent identity held broad access — common in development or early deployment — the agent begins life over-privileged with no human review gate.
Lateral movement via trust chaining. A compromised agent token is not bounded by the application it was issued for. As UNC6395 showed, a single trusted credential can be the first link in a chain traversing multiple cloud services, each of which extended trust based on the prior hop.
Orphaned credential persistence. Agent identities are rarely deprovisioned when projects end. These dormant credentials represent persistent footholds with no active owner to notice anomalous use.
Secrets mishandled at scale. Agents that interact with APIs frequently cache or log secrets outside approved vault infrastructure, creating harvestable credential pools.
Framework Mapping
- AML.T0012 – Valid Accounts: The primary attack pattern here is abuse of legitimate, trusted machine credentials rather than exploitation of a vulnerability.
- AML.T0047 – ML-Enabled Product or Service: AI agents as deployed products expand the trusted identity surface within enterprise environments.
- LLM08 – Excessive Agency: Agents operating with permissions beyond what their task requires is the structural precondition for blast-radius amplification after compromise.
- LLM07 – Insecure Plugin Design: OAuth integrations and tool-use connectors used by agents frequently lack scoped, revocable permission models.
- LLM05 – Supply Chain Vulnerabilities: Third-party AI agent frameworks and integrations inherit supply chain trust assumptions that may not have been validated.
Threat Scenarios
Scenario 1 — OAuth pivot: An attacker phishes a developer with access to an AI agent’s OAuth configuration. They extract the agent’s token, which holds broad Salesforce read/write scope. From there they access connected AWS roles via OIDC federation and exfiltrate data from an S3 bucket the agent was permitted to write logs to.
Scenario 2 — Orphaned agent foothold: A proof-of-concept AI agent deployed during a hackathon six months ago retains an active service account with contributor rights to an Azure subscription. A threat actor discovers it via a misconfigured CI/CD pipeline log, uses the credential to deploy a cryptominer, and pivots to production key vaults.
Scenario 3 — Agent-spawned identity abuse: An autonomous AI agent, tasked with provisioning sandbox environments, creates child service principals with owner-level rights. An insider with access to the agent’s task queue modifies instructions to redirect one of these principals to a personal-controlled tenant.
Defender Checklist
- Run a discovery sweep specifically targeting non-human identities: OAuth apps, service principals, workload identities, and API keys — not just user accounts
- Map every AI agent deployment to an accountable human owner and document its permission scope
- Enforce just-in-time and time-bound credentials for agent identities wherever the platform supports it
- Require all agent-accessed secrets to be retrieved from an approved vault; audit for hardcoded or cached credentials in agent logs and config stores
- Establish behavioural baselines for non-human identities in your SIEM/UEBA platform and alert on cross-service token use outside expected patterns
- Include AI agent identities in quarterly access reviews with the same rigour applied to privileged human accounts
- Test agent deprovisioning workflows: confirm that retiring an AI project results in full credential revocation, not just application shutdown