Research → Security

AI Sandboxes: The New Risk Surface Your Security Team Hasn't Modeled

Brandon Sneider · March 2026

Your developers gave an AI agent access to your codebase, your CI/CD pipeline, your cloud console, and your internal APIs. They did this by installing a VS Code extension. IT didn't approve it. Security didn't review it. Nobody modeled the blast radius.

This is not a hypothetical. 88% of organizations report confirmed or suspected AI security incidents in the past year. Only 14% of AI agents went live with full security and IT approval. The gap between deployment velocity and governance is the widest it has ever been in enterprise technology.

Gravitee 2026, n=919 enterprise IT and security professionals; CyberArk 2026; Saviynt/Cybersecurity Insiders, n=235

The Problem: AI Agents Are Not SaaS Applications

Traditional SaaS security assumes deterministic software with well-defined inputs and outputs. You can baseline "normal" behavior, write SIEM rules, and detect deviations. AI agents break every one of those assumptions.

Property Traditional SaaS AI Agent
Behavior Deterministic — same input, same output Non-deterministic — different outputs for identical inputs
Access Defined API scopes, OAuth tokens Filesystem, shell, network, APIs — often with user-level or higher privileges
Attack surface Network boundary, authentication Prompt injection, tool poisoning, context manipulation, model behavior drift
Monitoring Log every request, match patterns No baseline for "normal" — the agent decides what to do at runtime
Blast radius Limited to the app's permissions Potentially everything the developer can access

Non-human AI identities now outnumber human users 82-to-1 in enterprise networks. 92% of CISOs report they lack confidence that their existing identity and access management tools can govern them.

CyberArk 2026; Saviynt/Cybersecurity Insiders, n=235, 2026

The Three Attack Classes That Didn't Exist Two Years Ago

1. Prompt Injection

Ranked #1 on the OWASP Top 10 for LLM Applications. An attacker embeds instructions in data the AI processes — a comment in a code review, a hidden directive in a document, a crafted email. The AI follows the injected instruction because it cannot distinguish data from commands.

OpenAI's own researchers have stated that AI systems "may always be vulnerable" to prompt injection. The Microsoft Copilot "EchoLeak" vulnerability (CVE-2025-32711, CVSS 9.3) demonstrated zero-click data exfiltration through email — no user interaction required.

2. Tool Poisoning and Hallucinated Dependencies

AI coding tools recommend software packages that do not exist approximately 20% of the time. Attackers register packages under those hallucinated names. When a developer (or an AI agent) installs the recommended package, they install the attacker's code. This is called "slopsquatting" — a supply chain attack vector that did not exist 18 months ago.

43% of MCP (Model Context Protocol) servers have OAuth authentication flaws. 5% of open-source MCP servers already contain tool poisoning attacks.

Vulcan Cyber, 756,000 code samples, March 2025; OWASP MCP Top 10, beta, 2026

3. Agent Autonomy Failures

AI agents experience sudden coherence breakdowns rather than gradual degradation. Unlike traditional software that fails predictably, an AI agent can function correctly for hours and then take an action that makes no sense — deleting files, escalating privileges, or generating a $2,400 API bill in a single overnight loop.

In one documented case, a multi-agent system was manipulated into approving a $3.2 million procurement transaction through cascading prompt injection across agent boundaries. The agents followed their individual rules. The system-level outcome was a fraud.

What an AI Sandbox Actually Is

An AI sandbox is a controlled execution environment that limits what an AI agent can access, modify, and communicate. It applies the security principle of least privilege — not to a user, but to an autonomous system that makes its own decisions about what to do next.

The architecture has four layers:

Layer 1: Isolation. The AI agent runs in a containerized environment with no access to production systems, no persistent filesystem, and no network access beyond explicitly whitelisted endpoints. This is the equivalent of a bank running cash-handling in a vault, not on the open floor.

Layer 2: Scoped permissions. The agent receives the minimum credentials needed for its specific task — read-only access to a single repository, not the entire GitHub organization. Time-limited tokens that expire after the task completes, not persistent API keys.

Layer 3: Output review. Every action the agent takes — every file modification, every API call, every shell command — is logged and reviewable. High-risk actions (modifying production configuration, accessing sensitive data, creating new credentials) require human approval before execution.

Layer 4: Circuit breakers. Automated monitoring that detects anomalous behavior and terminates the agent before damage compounds. Token spend exceeding a threshold. Actions outside the expected scope. Repeated failed authentication attempts. The system assumes the agent will eventually do something unexpected and is built to contain it.

Who Needs This

Every organization where AI agents have access to systems that matter. In practice:

What This Means for Your Organization

The question is not whether to use AI agents — that decision has already been made by your employees, whether you sanctioned it or not. The question is whether the agents running inside your environment today have the containment architecture they require.

Start with an inventory. How many AI tools have access to your codebase, your cloud console, your internal data? In most organizations, the answer is higher than IT believes. A shadow AI audit — checking DNS logs, SaaS spend, browser extensions — typically reveals 3-5x the expected footprint.

Then apply the four-layer model: isolate the environment, scope the permissions, review the output, and build the circuit breakers. None of this requires novel technology. It requires applying the same Assume Breach principles your security team already uses for traditional infrastructure — extended to systems that make their own decisions.

If this raised questions about your organization's AI security posture, I would welcome the conversation — brandon@brandonsneider.com.

Sources

I publish research on AI strategy and security for executives. Data, not hype.