“Your shadow IT policy was built for software that waits. This one acts.”
Shadow IT gave your security team something to chase. Shadow AI gave it something to govern. Shadow Agents give it something it wasn’t built to see — an autonomous system acting inside your environment with no identity, no audit trail, and no policy that covers what it can do.
Before You Read Further — Know the Difference
Most people reading this will assume we’re talking about Shadow AI. We’re not. These are three distinct threats — each an evolution of the last.
Shadow IT
Stores things it shouldn’t.
Unauthorized software or systems — a personal Dropbox, an unsanctioned SaaS tool. Data exits your governance boundary. The tool stores or processes. It doesn’t think.
Shadow AI
Knows things it shouldn’t.
Unauthorized AI tools — ChatGPT on a personal account, a browser extension reasoning over your data. Same governance gap as Shadow IT, but now the system is drafting, analyzing, inferring.
Shadow Agent
Does things it shouldn’t.
Unauthorized autonomous AI connected to corporate systems. Not reasoning over data — acting on it. Sending emails, moving files, triggering workflows, with no identity your governance controls can see.
The Operation
It is a Tuesday afternoon — inside your organization, not outside it. A regional director at a financial services firm connects an AI productivity agent to her work email and calendar. The tool is not on the approved vendor list. It is not reviewed by security. It has OAuth access to her inbox, her calendar, her SharePoint folders, and — because her credentials were cached in a browser extension — her access to the client portal.
For six weeks, the agent operates normally. It summarizes emails, drafts responses, schedules meetings. Then a phishing email arrives in her inbox. The agent reads it as a legitimate client request, extracts the wire instructions embedded in the body, and drafts a response confirming receipt. She approves the draft without reading it fully. The wire processes.
The agent left no entry in the SIEM. It generated no alert. It appeared in no identity inventory. Forensics reconstructed the sequence from email metadata and OAuth logs — four days after the transfer cleared. The agent had acted on behalf of a human who didn’t fully understand what she had authorized.
The breach wasn’t a hack. It was a misconfigured trust relationship with a tool that had no governance, no identity, and no boundaries — operating autonomously inside a permissions envelope that was never designed for it.
Three Perspectives
The Trusted Leader
“I thought I was authorizing a productivity tool. I didn’t understand I was creating an autonomous actor with access to everything I had access to.”
The agent was genuinely useful. It saved me two hours a day. I approved the OAuth permissions the same way I approve cookie banners — I read the summary, not the scope. Nobody told me that connecting a calendar assistant also meant connecting it to a portal with client financial data. Nobody asked. There was no policy that said I couldn’t. By the time security asked me about it, the tool had been operating inside our systems for six weeks.
The Defender
“My detection stack was built to find unauthorized software. It was not built to find an authorized user whose permissions had been extended to an autonomous system I had no visibility into.”
The OAuth token was valid. The actions were taken by a credentialed user — or something acting as one. My DLP controls look for data movement patterns outside approved applications. This was approved application infrastructure, just with an agent on the other end of it. I found the agent by accident — a routine OAuth audit flagged an unfamiliar client ID. By then, the agent had been in the environment for forty-two days. I had no inventory of what it had done.
The AI-Native Diamond Model reframes this correctly. The traditional IR question is: what account was compromised? For Shadow Agent, the right question is: what did the agent decide, and who approved it without reading it? That’s an entirely different investigation — and it requires logging agent decisions, not just agent activity.
The Attacker
“I didn’t need to compromise the employee. I needed to get my instruction into the inbox of a person who had already given an AI agent permission to act on her behalf.”
The agent was doing exactly what it was built to do — read, summarize, respond. I wrote an email that looked like a routine client communication. The wire instructions were in the body, formatted like a standard payment update. The agent read it, the human approved the draft without scrutiny, and the transfer processed. I never touched their network. Their own infrastructure executed the transfer. The human was in the loop — technically. She just wasn’t reading what she was approving.
Technical Assessment
The Threat Architecture
Shadow Agents exploit the gap between identity governance and permission inheritance. When an employee authenticates a third-party AI agent via OAuth, the agent acquires the employee’s delegated permissions — not a new identity, not a governed service account, but an extension of human credentials applied to autonomous behavior. The agent is invisible to standard identity inventories because it is not a non-human identity in the traditional sense. It is a capability attached to a human one.
The attack surface expands across three vectors: (1) prompt injection via trusted communication channels — email, documents, calendar invites — where the agent processes attacker-controlled content as legitimate instruction; (2) permission scope creep, where agents accumulate access across integrated platforms without explicit authorization for each; and (3) approval fatigue, where human oversight degrades into rubber-stamping because the agent has been reliable long enough to reduce scrutiny.
The Diamond Model Applied to Shadow Agent
Detection Gap Analysis
| Control | Covers Shadow IT / Shadow AI | Covers Shadow Agent |
|---|---|---|
| Approved application list / DLP | Yes | No — agent operates through approved apps via OAuth |
| SIEM / endpoint telemetry | Yes | Partial — actions attributed to human credential; agent behavior not surfaced |
| OAuth audit / token review | No | Yes — only effective if third-party client IDs are inventoried and reviewed regularly |
| NHI / service account governance | No | No — shadow agents not provisioned through IT; not captured in NHI programs |
| AI agent behavior monitoring | No | Yes — purpose-built; most organizations have not deployed |
The Multi-Agent Multiplier
The risk compounds when shadow agents are connected to enterprise automation platforms. An agent with calendar access that also integrates with a task management tool, a CRM, and a document platform is not one autonomous actor — it is an entry point into a chain. One injected instruction propagates through every downstream integration the agent can reach. The attack surface is not the agent. It is everything the agent can touch.
CISO Debrief
“The employee didn’t shadow IT your network. She handed an autonomous system the keys to everything she had access to — and your policy had no language for that.”
Shadow Agent is not a technology problem. It is a governance gap that technology is exploiting. The agent was not unauthorized in the traditional sense — the employee’s credentials were valid, the OAuth grant was legitimate, the tool operated exactly as designed. What was missing was any governance layer that recognized the difference between a human making decisions and an autonomous system making them on that human’s behalf.
IR Directives
Run an OAuth inventory before you do anything else. You cannot govern what you cannot see. Pull every active OAuth token across your identity platform and map third-party client IDs to approved vendor lists. Every unrecognized client ID is a potential shadow agent with delegated access to human credentials. This is not a quarterly exercise — it is a gap you have right now.
Stop attributing agent actions to the human credential. Your current logging infrastructure records actions by credential, not by actor. When an AI agent takes action via a delegated token, those actions appear in your logs as human-initiated. Your IR process needs to ask not just “who did this” but “was this action taken by the human or by something acting as them.” That is a different investigation methodology.
Redefine what counts as an authorized actor. Your acceptable use policy almost certainly covers what software employees can install. It almost certainly does not cover what autonomous systems employees can authorize to act on their behalf. Those are materially different governance questions. The policy gap is not theoretical — it exists in your environment today.
Treat prompt injection as a business email compromise vector. Your BEC training tells employees not to wire money based on an email alone. Your AI governance framework needs the equivalent: employees who have authorized agents to act on their behalf must understand that an attacker who can reach their inbox can now reach their agent. The phishing target is not the human. It is the human’s autonomous proxy.
Establish an agent authorization workflow before restricting access. Blanket prohibition on AI agents will drive adoption underground faster than any policy can chase it. The governance goal is not elimination — it is visibility. Build a lightweight authorization workflow: agent name, vendor, permission scope, business justification, security review. Make the sanctioned path easier than the shadow path.
Direct your IR team to explicitly determine agent involvement in every incident. During any investigation involving AI-assisted workflows, document whether an autonomous agent was in the action chain as a required step. Reconstruct what the agent was authorized to do, what it actually did, and what it processed in the hours before the incident. Standard email forensics will not surface this without targeted queries against OAuth logs and integration audit trails.
Close the Governance Gap
Acceptable Use Policy — Agent Authorization Clause. Add explicit language prohibiting employees from connecting AI agents to corporate systems, credentials, or data without explicit IT authorization. The policy must name autonomous action specifically — not just data access. Most current AUPs address tools that store data. This one acts.
Identity Governance — Delegated Autonomy Scope. Extend your NHI program to include human-delegated AI agents. A third-party agent operating under a human OAuth token is a non-human actor in a human identity envelope. Your identity governance controls need to account for the behavior of the agent, not just the validity of the credential.
Vendor Security Review — AI Agent Category. Your vendor assessment framework almost certainly covers SaaS applications. Add a distinct review category for AI agents with autonomous action capability — separate from productivity software. The risk profile is different: these tools don’t just access data, they process instructions and take action based on what they read.
Five Questions for Your Next Executive Meeting
1. Do we have an inventory of AI agents operating in our environment with delegated access to employee credentials and corporate systems?
2. If an employee’s AI agent took an unauthorized action today — sent an email, moved data, initiated a transaction — how long before we would know, and how would we reconstruct what happened?
3. Does our acceptable use policy address autonomous AI agents specifically, or only unauthorized software?
4. Are we training employees that authorizing an AI agent to act on their behalf extends their attack surface to every instruction that agent can receive?
5. What is the business justification for the AI tools currently operating in our environment with the broadest permission scopes?
Technical Reference
Threat Category: Agentic Governance & Shadow Infrastructure
Techniques: OAuth Delegation Exploitation · Prompt Injection via Trusted Channel · Delegated Credential Abuse · Cross-Platform Permission Propagation · Human-in-the-Loop Approval Degradation · Shadow Agent OAuth Persistence
OWASP LLM Top 10: LLM01:2025 — Prompt Injection · LLM08:2025 — Excessive Agency · LLM06:2025 — Excessive Autonomy · LLM09:2025 — Misinformation
MITRE ATLAS: AML.T0051 — LLM Prompt Injection · AML.T0043 — Craft Adversarial Data · AML.T0040 — ML Model Inference API Access
Detection Controls: OAuth Client ID Inventory · Third-Party Integration Audit Logging · AI Agent Behavioral Monitoring · Agent-Specific Approval Workflow · Prompt Injection Detection at Email Ingestion Layer
Framework: AI-Native Diamond Model — IR question reframing for agentic incident response
“When AI Attacks” is a practitioner-grade security intelligence series written for CISOs, security leaders, and defenders navigating the AI threat landscape.
The scenarios described in this series are grounded in documented, publicly reported threat intelligence patterns. They do not reflect confidential information from any employer.