“Shadow agents are the new SaaS sprawl — except the SaaS app can’t run rm -rf on your engineering laptop.”
Why Shadow Agents Matter Now
Two years ago, “shadow IT” meant someone in marketing signing up for a Notion account procurement didn’t know about. The blast radius was bounded. The application didn’t act on its own.
That model is gone. Today’s shadow IT is software that reasons about its environment, executes filesystem and network operations on the endpoint, and makes runtime decisions a human never explicitly authorized. From the field: in a recent Ospiri design partner deployment, our signature pipeline catalogued more than a dozen distinct AI agents running on developer endpoints — most of which procurement had no record of and no policy for.
This is not theoretical exposure. It’s an unhedged position on every box, accumulating daily.
| Headline metric | What it measures |
|---|---|
| 88% | Organizations reporting at least one AI agent security incident in the last year |
| +$670K | Average shadow-AI premium per incident, above the cyber breach baseline |
| 12–18 months | Window before this category has an entrenched control-plane vendor |
Whether you treat this as catastrophe risk, operational risk, or compliance exposure, the integral is the same: it compounds daily, and existing controls don’t price it.
Two Species, One Control-Plane Gap
Shadow agents come in two architecturally distinct varieties. Both need governing, but they reach different procurement and policy queues.
| Dimension | Species 1: Embedded SaaS Agents | Species 2: Standalone Endpoint Agents |
|---|---|---|
| Origin | Built into approved SaaS applications | Installed by individual employees |
| Examples | Slack AI, Microsoft 365 Copilot, Salesforce Einstein, Notion AI, Asana Intelligence, Zoom AI Companion | Cursor, Claude Desktop, Goose, Aider, Continue, Cline, Operator, Manus |
| Permission scope | Whatever the parent app has — typically your data plus its API tokens | Whatever the OS grants — filesystem, network, processes, devices |
| Procurement gate | Approved years ago, before AI was added | Often none — installed without security review |
| Visibility today | Surfaces in TPRM register and SaaS-posture tools | Largely invisible to the current stack |
| Primary failure mode | Data exfiltration, training on IP, compliance drift | Destructive local actions, lateral movement, credential theft |
As I argued in The Embedded AI Blind Spot, the embedded species is already an active data processor with autonomous logic — and most enterprise data-sharing agreements were signed before the AI was added. The standalone species is the more urgent operational risk: full filesystem and network reach by design, because an agent that can’t write to disk can’t help you write code.
The architectural property both share is the one that breaks the existing security stack: the dangerous behavior is not malicious code. It’s correct code, executing the wrong instruction.
Anatomy of a Wipe-Out
The wipe-out incidents that surfaced in the last twelve months — the Pebble OS codebase deletion, the Replit production database wipe during a debugging session, the reported Cursor git reset --hard incidents that nuked uncommitted work — converge on the same six-step pattern:
- Agent receives an ambiguous prompt.
- Agent reasons and decides the right next action is destructive.
- The agent’s permissions allow it.
- The application’s permissions allow it.
- The user did not technically prohibit it.
- The action executes — irreversible by the time the alert fires.
There is no malicious actor in this loop. There is no policy violation an existing tool can pattern-match on. The agent is doing its job.
What the Existing Stack Cannot Price
The current security stack was built for adversaries. Friendly software acting on your behalf with too much authority does not fit any of its control surfaces.
| Control category | Built for | Why it misses agent risk |
|---|---|---|
| API gateways and CASB | Sanctioned API traffic | Agents call OS syscalls (unlink, socket, WriteFile) — not your gateway |
| EDR and XDR | Malware behavior | Agent binaries are signed and known; behavior matches an authorized user |
| DLP | Data exfiltration | Agents destroy rather than exfiltrate; deletion is benign in most DLP rules |
| Prompt-layer guardrails (Lakera, Protect AI, etc.) | Pre-execution filtering | They live above the OS; the prompt is long gone by the time the action lands |
| SIEM and observability | Forensics | By the time the action shows up in Splunk, the files are gone |
This is the unhedged exposure. None of these tools see the layer where the agent’s intent becomes an OS-level side effect — and the OS-level side effect is the thing that costs you money.
A Risk-Scoring Framework for Agent Exposure
Borrowing the approach from the Polymer Risk Score, agent exposure can be quantified at the event level and rolled up to organizational posture. Four factors:
Agent Risk Score = (Permission Scope × Reversibility) + (Frequency × Drift Coefficient)
| Factor | What it measures | Low-score example | High-score example |
|---|---|---|---|
| Permission Scope | Reach across kernel scopes (filesystem, registry, network, IPC) | Coding agent constrained to ~/repos/ |
Agent with /etc/, ~/.aws/, broad network egress |
| Reversibility | The tail-risk weight | git commit — undoable |
rm -rf, DROP TABLE without backups — terminal |
| Frequency | Invocation rate and concurrency | Manual, 3× a week | 30-second cron, parallel WebSocket-driven action loops |
| Drift Coefficient | Behavioral deviation from baseline | Stable signature, predictable scope | New endpoints, new directories, new syscalls month-over-month |
Roll these per-endpoint, then per-team, then per-organization. You end up with the same posture lens a trading desk uses to mark-to-market a portfolio: a single dashboard quantity that captures where exposure sits, who’s compounding it, and where the tail concentrations are.
The Reversibility factor is the one that makes this framework different from existing user-risk scoring. UEBA can flag an unusual download. It cannot flag that the unusual download will be impossible to undo by the time it’s flagged. Agent risk lives in the irreversibility column.
Why the Enforcement Point Has to Be the Kernel
You cannot restrict these agents at the API layer — that’s not where they operate. You cannot restrict them at the application layer — the application is the agent. The only enforcement point that consistently sees what an agent is actually doing — file writes, registry modifications, network calls, IPC messages — is the kernel.
That’s where the agent firewall sits. Per-agent policy enforced before the action reaches the OS:
- A coding agent in
~/repos/can write inside that tree, but cannot reach/etc/,~/.aws/, or~/Library/Keychains/. - A research agent can read documents but cannot modify them.
- An agent embedded inside a SaaS desktop application gets a different policy from a standalone agent the same employee installed last week.
- Unknown agents — the ones the observability layer has not yet catalogued — get restrictive defaults until an admin reviews and approves them.
Critically, this is copy-on-write, not block-on-deny.
| Posture | What happens on violation | Effect on agent | Effect on data |
|---|---|---|---|
| Block-on-deny (legacy DLP, EDR) | Action denied, agent errors out | Workflow breaks, escalation to engineering | Original safe |
| Copy-on-write (agent firewall) | Action permitted into a sandboxed clone | Agent gets the result it expected | Original untouched, blast radius zero |
That distinction is what separates a control plane that breaks agentic productivity from one that enables it. CISOs who have lived through prior DLP and EDR rollouts know the difference: tools that block by default get ripped out within two quarters because engineering escalates. Copy-on-write doesn’t trigger that organ-rejection response.
What CISOs Should Do This Quarter
For security leaders standardizing on AI agent governance, four operational items, in order:
| Step | Action | Output | Effort |
|---|---|---|---|
| 1. Inventory | Catalog every AI agent — embedded and standalone — active on managed endpoints | Agent register with origin, scope, owner | 1–2 weeks for fleet of 1,000 endpoints |
| 2. Score | Compute Permission Scope × Reversibility + Frequency × Drift for each agent | Ranked exposure list, top-decile flagged | 2–3 days after inventory completes |
| 3. Pilot kernel isolation on top decile | Deploy copy-on-write enforcement on highest-risk agents in a controlled fleet | Validated isolation, baseline metrics, productivity impact data | 4–6 weeks pilot |
| 4. Wire into existing telemetry | Push Agent Risk Score into SIEM and UEBA as a new dimension | Agent risk visible alongside identity, asset, and data risk | 1–2 weeks integration |
Most organizations are surprised by what shows up in step 1. That’s the whole point — you cannot govern what you cannot enumerate.
The Bottom Line
Shadow agents are uncorrelated tail risk in your endpoint portfolio. They sit benign until a single ambiguous prompt collides with broad permissions, and then they take a position you never authorized. The existing control stack does not price this exposure, because none of its components sit at the layer where agent intent becomes OS-level action. Only the kernel does.
The 12-to-18 month window for a credible vendor to ship and lock in this control plane is open right now. Whether you build internally, deploy a vendor, or accept the exposure, the worst posture is the one most enterprises currently hold: knowing the risk exists, naming it in board decks, and not yet quantifying or governing it.
If your team is sizing this exposure for 2026 budget cycles, request a working session. We will walk through your environment, score the top agents we find, and scope a deployment. The inventory and first score take 90 minutes.