AGENTS.md Hijack Reveals Need for Real MicroVM Isolation

01The AGENTS.md Hijack: How a Simple File Compromised an AI Agent

Researchers discovered a file named AGENTS.md sitting in a user's Downloads folder. The file contained a crafted instruction set that the AI coding agent interpreted as a legitimate build step, causing it to run npm install on a package that was controlled by the attacker.

The rogue package executed arbitrary JavaScript on the machine that hosted the agent. Because the agent ran with the same filesystem permissions as the user, the payload could read other files, inject credentials into environment variables, and even spawn additional processes. The breach was invisible to the surrounding tooling because the agent’s logs only showed a successful npm install.

• Malicious markdown file → AI agent → rogue npm package → code execution
• Attack leveraged the agent’s trust in local files, not a network exploit

02Why Traditional Sandboxes Aren’t Enough for AI Agents

Most AI‑agent deployments rely on container‑level isolation or OS‑level user namespaces. Those mechanisms share the host kernel, so a compromised agent can still escape to the host via kernel bugs, misconfigured mounts, or indirect syscalls. The OpenAI VM‑escape research published the same week shows that even hardened VMs can be coaxed into cross‑sandbox communication when the attacker controls the agent’s prompts.

When an agent can download and execute code, the attack surface expands to the entire software supply chain: npm, pip, Maven, and other registries. Prompt‑injection techniques can coax the model into generating malicious code on the fly, turning the agent itself into a weapon. In short, sandboxing at the process level does not stop a determined supply‑chain attack.

03Practical Steps to Harden Your Agent Fleet Today

Start by treating every agent as an untrusted workload. Run agents inside a sealed microVM that has its own kernel and a single read‑only workspace directory. Block all outbound network traffic by default and whitelist only the endpoints the agent truly needs, such as the model provider’s inference API.

Separate secrets from the sandbox. Keep API keys on the host and inject them only at egress through a broker, so the agent never sees a real key. Use a two‑person approval workflow for any action that writes to the file system outside the workspace, and keep a tamper‑evident audit log of every command the agent attempts.

• Run agents in sealed microVMs with read‑only workspace
• Allow‑list network destinations; deny everything else
• Store secrets on the host, inject via egress broker
• Enforce two‑person approval for risky file writes
• Log all agent actions to a hash‑chained audit trail

04How Sealed microVMs Like kosa8 Close the Gap

kosa8 provides a real microVM for each agent, isolating it from the host kernel and exposing only a single workspace folder. The network is closed by default; you add allowed hosts with a single flag. Secrets never enter the sandbox – an egress broker swaps placeholders for real credentials just before traffic leaves.

If something goes wrong, kosa8 can checkpoint the entire VM in under a second and rewind it instantly. You can also fork a running instance into multiple parallel copies to test mitigations without exposing production agents. Every operation is recorded in a hash‑chained audit log that can be verified with a built‑in command.