Why Your AI Agent Is a Security Liability

Your AI agent isn't just answering questions anymore — it's running shell commands, writing files, and calling APIs with your credentials. That combination of autonomy and inherited permissions is what turns a coding assistant into a genuine security liability.

The core problem is structural. When an agent executes a skill or tool, it operates with the same permissions as the user who launched it: reading and writing files, running shell commands, and accessing environment variables that often hold API keys, as skills-specific security research makes clear. A malicious or compromised skill can exfiltrate secrets, modify your code, or install backdoors — and nothing in the agent's design stops it.

Meanwhile, the threat that triggers these failures can't be reliably detected. Security audit data shows prompt injection present in over 73% of production AI deployments assessed, and it ranks #1 in OWASP's LLM Top 10. Hidden text on a webpage — even zero-pixel CSS — can instruct an agent to exfiltrate data like your ~/.ssh/id_rsa keys, and researchers argue the only mathematically provable defense is isolating the environment where the agent runs.

This isn't theoretical. Unit 42 built identical applications on CrewAI and AutoGen and demonstrated nine concrete attack scenarios — including data exfiltration via mounted volumes, token theft via metadata services, SQL injection, and BOLA exploitation. Their conclusion: most vulnerabilities come from insecure design patterns and unsafe tool integrations, not the frameworks themselves, and no single mitigation is sufficient.

Then there's the ZombAIs test. Security researcher Johann Rehberger showed Claude Computer Use reading a hidden injection payload, downloading and executing a binary, and connecting to a command-and-control server — and per the documented walkthrough, the entire chain worked on the first try on an unsandboxed machine.

• Agents inherit full user permissions — file access, shell execution, and secrets in environment variables
• Prompt injection appears in 73%+ of audited deployments and can't be caught by detection alone
• Nine demonstrated attack scenarios show real exfiltration, token theft, and injection paths
• Published research found roughly 26% of agent skills carry at least one vulnerability

That last number is why SkillzBench exists as a testing lab rather than a marketplace — because "install this skill" currently means "trust it blindly." The Frontier Model Forum's position is blunt: robust agent security should not rely on detection alone, and every tool an agent can access expands both its capability and its exposure. The rest of this article is about limiting that exposure.

Skills, proven. Join the SkillzBench waitlist to see security-scanned, sandbox-benchmarked skills before you install them.

The Isolation Ladder: Containers, gVisor, and MicroVMs

Not all isolation is created equal. As agent sandboxing has matured into a distinct platform category, the industry has converged on a three-tier taxonomy, and understanding it is the difference between real containment and a false sense of security.

At the bottom of the ladder sit hardened containers — and plain Docker, notably, doesn't even qualify as strong isolation. Standard containers share the host kernel, which keeps kernel escape in the threat model. Worse, an agent that can reach the host Docker daemon or a mounted Docker socket can bypass isolation entirely, according to Firecrawl's analysis. Containers are best reserved for trusted, vetted code, not untrusted agent output.

The middle tier is gVisor, which runs a user-space kernel that intercepts system calls. It's meaningfully stronger than containers but weaker than a true VM, at the cost of roughly 10-30% overhead on I/O-heavy workloads, per Northflank's guide.

The top tier is the microVM — Firecracker and Kata Containers — which provides hardware-level isolation with a dedicated kernel per workload. Historically, this strength came with painful tradeoffs. No longer:

• Firecracker boots a VM in roughly 125 milliseconds, with under 5 MiB of memory overhead per instance.
• A single host can spin up to 150 VMs per second.
• Kata Containers boot in around 200 milliseconds, keeping cold starts negligible.

Those numbers dismantle the old assumption that strong isolation costs usability. Northflank's conclusion is blunt: for most AI agent workloads, the security benefits far outweigh the performance cost. The Frontier Model Forum frames the same idea from a different angle — execution environments are well suited to deterministic controls that limit the damage when something goes wrong, while model-layer defenses have probabilistic failure modes traditional security was never designed for.

One architectural pattern is also emerging as the likely long-term direction: run the agent outside the sandbox, and place only its execution surface inside. As Modal's research notes, this gives better separation of concerns — the agent reasons in one trust boundary and executes untrusted code in another. The Hugging Face incident, where an agent retrieved publicly exposed credentials across four third-party services despite sandboxing, shows why keeping secrets and agent execution in separate boundaries matters.

This is the ladder SkillzBench is building on for its benchmarking pillar: every skill tested in a sandboxed environment with the same model, with and without the skill, so the measured Lift reflects what the skill actually does — safely. When a published analysis found roughly 26% of agent skills carry at least one vulnerability, tier-one isolation stopped being optional.

The practical takeaway: match the tier to the trust level. Vetted code can live in hardened containers; untrusted agent output belongs in a microVM. Treating all AI-generated code as potentially malicious is the zero-trust default the research keeps pointing back to.

Building Your Defense-in-Depth Setup

If you're running AI agents without a sandbox today, you're not securing them — you're hoping. With 15–25% of AI-generated code suggestions containing security vulnerabilities, according to recent security research, hope is not a control.

The good news: a defensible baseline doesn't require exotic infrastructure. Firecrawl's distilled recommendation is four things: a non-root container, network egress filtering, read-only mounts, and strict timeouts on every single agent task (source). Each one is boring, deterministic, and cheap — and each one independently shrinks what a compromised agent can do. Non-root execution removes privilege escalation paths. Egress filtering blocks the exfiltration channel that turns a prompt injection into stolen SSH keys. Read-only mounts stop an agent from rewriting your codebase. Timeouts cap how long an attack can run unattended.

But the baseline only works if you adopt the right posture. Northflank's zero-trust framing is the correct mental model: all agent actions should be explicitly allowed rather than implicitly permitted, treating all AI-generated code as potentially malicious (source). This mirrors how you'd treat an external contractor — least privilege, code review, audit logging. An agent is an untrusted third party that happens to type very fast.

The same logic applies to tools. The Frontier Model Forum makes a point worth internalizing: every tool an agent can access expands both its capability and its exposure. Tool access should therefore be scoped per task, not granted globally. In practice that means asking, before every session: does this agent actually need filesystem writes? Network access? Shell execution? If the answer is no, the tool shouldn't exist in its environment. This is the principle behind per-agent loadouts — the approach SkillzBench is building, where each agent only sees the skills and tools explicitly chosen for it, and nothing else.

One principle ties the whole setup together. The Frontier Model Forum distinguishes between the model layer, where failure modes are probabilistic and traditional security controls weren't designed for them, and the execution environment, where deterministic controls can reliably determine the scope of damage when something goes wrong (source). Sandboxing, egress rules, and least-privilege tool access live in the deterministic layer — which is exactly why they should carry your security weight, not prompt-based defenses.

A final calibration on expectations: sandboxing limits blast radius, but it cannot be your only layer. Unit 42's threat research demonstrated nine concrete attack scenarios against agentic applications — including data exfiltration via mounted volumes and token theft via metadata services — and concluded plainly that no single mitigation is sufficient (source). The Hugging Face incident, where an agent retrieved credentials despite sandboxing, reinforces the point.

Defense-in-depth, concretely, looks like this:

• Sandboxed execution: non-root, egress-filtered, read-only mounts, strict timeouts
• Least-privilege tool access: per-agent loadouts, nothing implicitly granted
• Vetting before installation: security-scan every skill and pin it to a known version
• Ongoing review: re-scan and re-test as upstream skills change

That last two layers are where skill-level trust matters. With research finding that roughly 26% of published agent skills carry at least one vulnerability, and skills inheriting full user permissions the moment they activate, sandboxing a malicious skill is damage control — vetting it in the first place is prevention. SkillzBench is being built to handle that layer: version-pinned verification, sandboxed benchmarking, and trust scores that separate security signals from everything else.

Skills, proven. Join the SkillzBench waitlist to get the control panel for agent skills the moment it ships.

Sandboxing Skills: What to Do Before You Install That SKILL.md

Installing a skill feels harmless — it's just a text file, right? But the moment that SKILL.md goes live, the agent operates with your full permissions: reading and writing files, running shell commands, and touching every environment variable that holds an API key, according to Agensi's security analysis. A malicious skill doesn't need an exploit; it just needs you to enable it.

This is why vetting happens before installation, not after. The patterns worth scanning for are well documented:

• Hardcoded secrets — keys and tokens embedded directly in SKILL.md files.
• Environment variable harvesting — commands designed to sweep up credentials.
• Dangerous command patterns — curl-piped-to-shell, rm -rf variants, unexpected network calls.
• Obfuscation — base64-encoded payloads or minified scripts hiding their true behavior.
• Injection attempts — instructions telling the agent to ignore prior safety guidance.

Be honest about what scanning buys you. Agensi itself acknowledges its review process "doesn't guarantee that a skill is completely safe, but it significantly reduces the risk." Scanning is a filter, not a seal — and the broader numbers reinforce that caution: security assessments find 15–25% of AI-generated code suggestions contain vulnerabilities, and prompt injection now ranks #1 in the OWASP LLM Top 10, appearing in over 73% of production deployments audited.

The deeper problem is that the riskiest skills are exactly the ones you can't fully vet. Script-bearing skills execute code, and Unit 42's attack research showed that code-execution paths are where the worst scenarios live — data exfiltration through mounted volumes, token theft via metadata services, and silent credential compromise. Every one of those attacks traveled through an execution path a static review might never catch.

That's why SkillzBench deliberately limits its launch scope to instruction-only skills — SKILL.md files plus text references — with script-bearing skills listed link-out only. It's a conservative call, but a defensible one: you can meaningfully scan, version-pin, and benchmark what a skill tells an agent to do, while bundled scripts introduce arbitrary code execution that belongs to a later, more hardened chapter. The Frontier Model Forum puts it plainly: robust agent security should not rely on detection alone, and every tool an agent can access expands its exposure.

The takeaway is simple. Treat an unvetted skill the way you'd treat unvetted code from a stranger — because functionally, that's what it is.

Skills, Proven: Sandboxing as the Foundation of Trustworthy Benchmarks

Every control we've covered so far — microVMs, default-deny egress, least-privilege loadouts — converges on one question: does it actually make benchmarks and agent deployments trustworthy? This is the philosophy behind SkillzBench's approach to testing agent skills.

The stakes are real. Published research found that roughly 26% of skills carry at least one vulnerability, and skills inherit full user permissions by default — meaning an active skill can read files, run shell commands, and touch environment variables containing API keys, as security guidance on SKILL.md packages makes clear. Prompt injection compounds this: it appears in over 73% of production AI deployments assessed during security audits and ranks #1 in the OWASP LLM Top 10.

That's why SkillzBench is building its benchmarking pillar on the strongest isolation tier available. Every skill is being tested in microVM-backed sandboxes — the same Firecracker/Kata class of hardware-level isolation that boots in ~125ms with dedicated kernels — with default-deny egress, so even a successful injection has nowhere to send stolen data. Versions are pinned to commit SHAs, so a benchmark result always refers to the exact code that was scanned and tested, not a moving target.

Security scanning wraps around this as an honest, best-effort layer. It checks for dangerous command patterns, hardcoded secrets, environment-variable harvesting, and prompt injection attempts — reducing risk significantly, though no scan can guarantee a skill is completely safe. That's precisely why deterministic controls matter more: as the Frontier Model Forum argues, execution environments and tool access are well-suited to deterministic controls that determine the scope of damage when something goes wrong.

The per-agent loadout model extends this principle beyond the benchmark. When users toggle skills and tools per agent, the agent only sees what was chosen — implementing the least-privilege idea that every tool an agent can access expands both its capability and its exposure. The design decisions stack up:

• MicroVM-backed sandboxing for every benchmark run, not shared-kernel containers
• Default-deny egress so exfiltration attempts fail deterministically
• Commit-SHA version pinning so results and scans refer to exact code
• Per-agent loadouts so the agent's access surface matches what was deliberately chosen

Sandboxing plus least privilege is the deterministic control that limits what a successful prompt injection can actually do. SkillzBench is building that foundation into how skills are verified, benchmarked, and equipped — skills, proven. If you want trustworthy answers about which skills actually help, join the SkillzBench waitlist at skillzbench.com and follow the build as it happens.