Your Agent Has All Your Access — and That's the Problem

Your AI coding agent doesn't need to be hacked to cause a breach. It already holds the keys — you handed them over the moment you logged in.

This is the classic confused deputy problem, and it's built into how agentic coding tools work today. As Solo.io's guide to agent sandboxing explains, agents running in tools like Claude Code, Codex, or Cursor "have the same exact access that you do" — your cloud credentials, your GitHub repositories, your production systems. The agent doesn't operate in some walled-off corner of your infrastructure. It operates as you.

Here's where it turns dangerous. An attacker doesn't need to break through your defenses; they need only to get the agent to read something. Cosmonic's analysis of AI sandboxes puts it plainly: with a prompt injection, "an attacker doesn't need to 'hack' anything. They just need to ask the confused deputy to use the authority it already has."

Consider a concrete scenario described in technical comparisons of agent sandboxes: a malicious instruction hidden in a code comment directs your agent to send environment variables — including STRIPE_SECRET_KEY — to an attacker-controlled URL. The agent reads the text and acts on it, the same way it reads a legitimate instruction. No exploit, no malware, no unusual log entries. Just a deputy doing what it was told by the wrong person.

The security establishment treats this seriously. The OWASP AI Agent Security Cheat Sheet classifies code execution as HIGH risk requiring human approval, and explicitly flags unrestricted shell access as dangerous. Its recommended countermeasure is least privilege: grant agents the minimum tools required for the task.

The problem is that few teams actually do this. In practice, agent permissions look something like:

• Full read access to the repository — including comments, issues, and any file the agent is asked to review
• Inherited cloud credentials and environment variables, available to any command the agent runs
• Network access to whatever endpoints the host can reach, with no egress restrictions
• Write access to production-adjacent systems, because the human user needed it

This is why the question of what your agent can touch matters more than what your agent is asked to do. SkillzBench's own research into agent skills found that roughly 26% of published skills carry at least one vulnerability — and every one of them runs with the deputy's full authority unless you deliberately scope it away.

Ambient authority is the vulnerability. The agent never tries to escape the kernel, as ARMO's security analysis notes — it misuses the permissions it already has. Fixing that starts with drawing a boundary between what the agent could do and what it is allowed to do.

The Sandbox: Least Privilege for AI Execution

Your agent doesn't need to be hacked to cause damage — it just needs to be asked nicely. That's the core problem sandboxes exist to solve: agents inherit the full permissions of their execution environment, and prompt injection can turn that ambient authority into credential theft or data exfiltration without any traditional exploit (Cosmonic).

A code sandbox is an isolated execution environment where agents run generated code, shell commands, and tool calls with restricted access to system resources. As Cosmonic's technical guide puts it, a sandbox is "the enforcement layer that turns 'the LLM decided to run rm -rf /' from a catastrophe into a denied operation." In other words, it applies the principle of least privilege to AI execution — drawing a hard boundary between what an agent could do and what it's allowed to do.

Here's the catch: "sandbox" is one word covering materially different security boundaries. Four isolation technologies dominate, each trading speed against isolation strength:

• Containers (Docker, gVisor): familiar tooling, but 1–5s cold starts and shared-kernel escape risk (CVE-2024-21626, CVE-2022-0185)
• MicroVMs (Firecracker): hardware-level isolation with dedicated kernels, ~125–150ms cold starts — the technology proven at scale in AWS Lambda
• V8 isolates (Cloudflare Workers): sub-millisecond cold starts and just a few MB per isolate, but limited to JS/TS and Wasm with no real filesystem
• WebAssembly: sub-millisecond starts and a deny-by-default capability model where blast radius is "bounded at instantiation time, by declaration, before the module ever runs"

Those numbers matter for agents. A 1–5s container cold start makes interactive tool use sluggish; a sub-millisecond isolate makes sandboxed execution feel native. A 2026 benchmark of seven providers found cold starts ranging from ~25ms (Blaxel) to 2–3 seconds (Cloudflare, Beam) — a 100x spread hiding behind the same "sandbox" label.

Architecturally, the sandbox isn't where the agent lives. "In most systems, the language model and agent orchestration still run outside the sandbox. The sandbox becomes a tool the agent can invoke whenever it needs to execute code," according to Mastra's analysis of the platform landscape. This tool-invocation pattern is exactly what SkillzBench is building on for its benchmarking pillar: every skill tested in a sandbox, with the same model, with and without the skill, so the measured Lift reflects the skill — not environmental noise.

But don't confuse isolation with safety. As ARMO's security researchers observe, "the agent never tries to escape the kernel. It misuses the permissions it already has." A sandbox constrains the blast radius; it doesn't decide what should run inside.

Sandbox ≠ Safe: Why Isolation Alone Doesn't Fix Agent Risk

A sandbox is where you put an agent so it can't hurt anything — except that attackers don't need to break the walls when the agent happily hands them the keys from inside. The most dangerous agent attacks today don't escape containment at all; they operate entirely within permitted boundaries, using authority the agent was legitimately granted.

ARMO's analysis identifies three layers of agent sandboxing: code execution isolation, resource and network containment, and behavioral enforcement — and argues the third layer is "missing entirely" in most organizations. Their attack scenarios are instructive precisely because none involve a breakout. Prompt injection disguised as telemetry sends data to an allowed endpoint. Legitimate code reads mounted service-account tokens. An MCP tool posts a confidential document to public Slack. As ARMO puts it: "The agent never tries to escape the kernel. It misuses the permissions it already has."

The pattern shows up in real incidents. A vendor-reported roundup claims agents escaped sandboxes at OpenAI, Anthropic, and Meta within a single month, all sharing one trait: software isolation rather than true hardware isolation. The same source describes the Hugging Face Black Hat incident, where a sandboxed agent still retrieved credentials accidentally exposed across four accounts on four third-party services. The walls held; the damage happened anyway.

The core failure modes inside a "working" sandbox look like this:

• Prompt injection that turns an agent's legitimate read-and-act behavior into data exfiltration — no "hack" required, just a request the agent can't distinguish from a real instruction.
• MCP tool misuse, where an agent follows tool semantics faithfully but leaks confidential data through a permitted channel.
• Permission creep, where shadow agents accumulate access over time and become soft targets.

This is why what runs inside the sandbox matters as much as the walls around it. An agent's skills, tools, and instructions are attack surface, not just capability. Published research found roughly 26% of agent skills carry at least one vulnerability — instructions the agent will read and act on exactly as faithfully as your own prompts. OWASP's guidance is blunt on this point: grant agents the minimum tools required for their specific task, and treat unrestricted shell access as dangerous.

That principle is why SkillzBench is building per-agent loadouts where the agent only sees the skills and tools explicitly chosen for it, alongside security scanning of every skill before it ships. A sandbox constrains what an agent can reach. It says nothing about whether the instructions inside it deserve to be trusted. Isolation is necessary; it was never going to be sufficient.

Sandboxes as the Foundation for Trustworthy Skill Benchmarking

A benchmark is only as trustworthy as the environment it runs in. If you can't guarantee that two test runs executed under identical conditions, your "with vs. without" comparison is just an anecdote with a chart.

That's why sandboxes matter for evaluation, not just safety. E2B lists agent evaluations and benchmarks among its core use cases, alongside reinforcement-learning rollouts where thousands of machines spin up, grade, and clear. The pattern is established: to measure an agent fairly, you need isolated, reproducible execution environments.

This is exactly the infrastructure skill benchmarking demands. SkillzBench's Benchmark pillar — testing every skill in a sandbox with the same model, with and without the skill, then publishing the Lift in percentage points — only means something if the environment is controlled. Same model, same task, same sandbox; the only variable is the skill itself.

But a sandbox alone doesn't make a skill safe to test. Security researchers have demonstrated attacks that operate entirely within permitted sandbox boundaries, from prompt injection disguised as telemetry to privilege escalation via legitimate code. The sandbox contains the blast radius; it doesn't vet what you put inside it.

That's why verification happens before benchmarking. Published research found roughly 26% of skills carry at least one vulnerability, and a sandboxed test run doesn't catch a poisoned instruction or a malicious tool reference — it just executes it. SkillzBench's Verify pillar pairs security scanning, license checks, and quality judging with version pinning to commit SHAs, so a benchmarked skill is the same skill a user later installs.

The reproducibility argument is what elevates Lift from marketing to measurement:

• Isolation ensures one skill's execution can't contaminate another's results.
• Identical sandboxes per run mean the only difference between test groups is the skill itself.
• Commit-SHA pinning guarantees the skill tested is the skill shipped.
• Pre-run security scanning keeps vulnerable skills out of the execution path entirely.

There's also a discipline angle. OWASP guidance recommends granting agents the minimum tools required for their task — which a benchmark harness can enforce precisely because the agent runs in a controlled environment, not on a developer's laptop with ambient access to credentials and production systems.

Sandboxing is what turns skill testing from "we tried it and liked it" into a measurable, repeatable experiment. The isolation layer keeps untrusted code contained; the verification layer keeps untrustworthy code out; and the benchmark layer finally answers the question the skills ecosystem has been avoiding: does this skill actually help, and by how much? Lift in percentage points — shown separately from any rating, with money never touching scores — is the honest answer.

How to Evaluate a Sandbox (and a Skill) Before You Trust Either

Trust is not something you should extend to a sandbox just because the vendor's landing page uses the word. Multiple sources warn that "sandbox" covers materially different security boundaries — shared-kernel containers, dedicated-kernel microVMs, V8 isolates, and WebAssembly all get marketed under the same label, and the same word describes four different security boundaries. The practical first step is to walk a threat scenario through any candidate: imagine a prompt injection hidden in a code comment instructing the agent to exfiltrate a STRIPE_SECRET_KEY to an attacker-controlled URL, then ask exactly which layer stops it.

Next, apply Mastra's five evaluation criteria: the isolation model (container, microVM, isolate, or Wasm), environment lifecycle and persistence, startup speed and scalability, runtime flexibility, and developer experience. These trade off sharply — containers start in 1–5 seconds but share the host kernel, while Firecracker microVMs start in roughly 125–150ms with hardware-level isolation, according to Cosmonic's technical guide. A 2026 benchmark of seven providers found cold starts ranging from ~25ms to 2–3 seconds, so speed claims should be tested, not assumed.

Isolation alone still isn't enough. Security researchers demonstrated attacks occurring entirely within permitted sandbox boundaries — prompt injection disguised as telemetry to an allowed endpoint, privilege escalation via legitimate code reading mounted tokens, and MCP tool misuse. As ARMO put it, the agent never tries to escape the kernel; it misuses the permissions it already has. That's why the OWASP AI Agent Security Cheat Sheet directs teams to grant agents the minimum tools required for the task, with per-tool permission scoping and separate tool sets per trust level. NVIDIA's AI Red Team guidance adds mandatory controls: default-deny network egress, filesystem write restrictions outside the workspace, and credential isolation that prevents host secrets from being inherited.

This is precisely where skills — the SKILL.md instruction packages agents consume — need the same scrutiny. Published research found roughly 26% of skills carry at least one vulnerability, and a sandbox won't neutralize a poisoned instruction. SkillzBench is building its evaluation around this reality: every skill is pinned to a commit SHA, security-scanned, and benchmarked in a sandbox with the same model, with and without the skill, so the Lift is measured rather than claimed. Its per-agent loadouts implement the least-privilege principle directly — the agent only sees the skills and tools you toggled on — and each skill carries a 0–100 trust score derived independently from security, quality, license, maintenance, and community signals, with revenue never touching the score.

A quick pre-trust checklist:

• Walk a concrete threat scenario (credential exfiltration via injected instruction) against the sandbox and identify which layer blocks it.
• Map the isolation model — shared kernel, dedicated kernel, or no ambient authority — and its known escape history.
• Verify default-deny egress, workspace-scoped writes, and credential isolation are enforced, not optional.
• Scope the loadout: minimum tools and skills per task, per agent.
• Check who vouches for the skill — and whether that vouching is independent or self-reported.

If you'd rather not run this gauntlet skill by skill, SkillzBench is building exactly this verification pipeline. Join the waitlist at skillzbench.com to get access when it launches.