We've all seen the "AI coding assistant" security reviews that boil down to "don't let it see your secrets." That's table stakes. The real problem in a corporate environment is the agent's *runtime*—the persistent, stateful, often poorly-isolated process that has your entire codebase indexed, a shell, and network access. Giving that to a third-party binary like Cursor is a non-starter for us.

So we built something ephemeral. The goal: an AI agent that can *only* live for the duration of a single task, inside a microVM, with no persistent state, and tightly scoped access. We call the pattern **NanoClaw** (because everything needs a name, apparently).

The core stack:
* **Firecracker** microVMs for isolation. Lightweight enough to spin up in <1 second.
* A minimal, read-only rootfs built from scratch.
* A **task-definition** file (JSON) that specifies the git repo, commit, task prompt, and allowed network endpoints (e.g., only internal artifact registries).
* Our own slimmed-down agent runtime that pulls the repo, runs the task, streams logs/artifacts out, then dies.

Here's the task-definition schema we enforce:

```json
{
"id": "task_abc123",
"repo_url": "git@internal.corp.com:project/foo.git",
"commit_sha": "a1b2c3d4",
"task_prompt": "Fix the null pointer exception in DataProcessor.java, write a test.",
"allowed_egress": [" https://internal-pypi.corp.com/simple" ],
"max_runtime_seconds": 300,
"output_artifacts": ["patch.diff", "test_results.xml"]
}
```

The workflow:
1. CI system or developer triggers a task, generating the definition.
2. Launcher spawns a Firecracker microVM, injects the task definition and necessary credentials (short-lived, scoped SSH key for git, API token for registry).
3. Agent inside the VM clones, analyzes, codes, runs tests.
4. Logs and artifacts are streamed back via a vsock channel *before* the VM is killed.
5. VM is terminated and all local state is purged. The microVM image is immutable and read-only.

Key wins:
* **No persistent codebase index** leaving the company's perimeter.
* **No long-lived shell access** to your network.
* The agent's capabilities are defined per-task, not per-installation.
* You can run it on a schedule, in CI, for automated refactoring or security fixes, without the fear of a dormant agent process.

The alternative is trying to sandbox a monolithic tool that wasn't designed for it. That's a losing battle. Better to build the runtime around the principle of least privilege from the ground up.