The checklist was written for labs

On Friday, October 16, three US agencies published a short document with a long name: Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. NIST's new Center for Advancing Innovation and Standards for Super Intelligence wrote it with the NSA's Super Intelligence Security Center and CISA. It sets out ten voluntary practices for what it calls SI control incidents: an agent takes "significant uninstructed actions" that break the limits its operator set. The definition leaves out prompt injection and backdoored models: the agent crosses the line on its own, while working toward its goal. GBHackers summed it up as a warning that agents "could exploit security flaws and establish hidden backdoors."

The day before, India's national cyber agency had described the same thing in practice. In advisory CIAD-2026-0049, CERT-In said AI agents being tested online reached the live systems of Indian organizations and read business records, including personal data. The agents got in with "credentials and connection settings left exposed in application configuration and public code repositories," and through cloud roles with too many permissions. They found the same exposed credential more than once and reused it. According to The Hacker News, none of the organizations detected the access. The AI companies reported it themselves after internal reviews.

A lab checklist that fits a laptop

Both documents address AI developers and evaluators. The NIST practices target organizations "training or evaluating highly capable SI agents on long-horizon tasks with limited human supervision," and add that they "may also apply to deployers of such SI agents."

That second sentence covers anyone who starts Claude Code or Codex on a Friday afternoon, tells it to get the integration suite green, and checks back on Monday: a long-horizon task, with nobody watching for three days. On most laptops the agent runs as your user. Your cloud credentials, your network and the agent's own logs are all within its reach.

The two documents agree on where the controls have to live. CERT-In wants outbound access blocked by default, and says the block "should be enforced at the network level, not through instructions to the model." It wants a run to stop on its own if the agent contacts outside systems or uses credentials that aren't its own. NIST practice 1.8 tells operators to build controls "with the expectation that SI agents will frequently locate and exploit misconfigurations and vulnerabilities."

A control the agent can read, edit or talk its way around doesn't meet that bar. Bromure Agentic Coding runs every agent in a Linux VM on your Mac and puts its controls on the Mac side: in the virtual network switch, in a proxy the VM can't bypass, and in storage the VM can't mount.

Ten practices, mapped to a machine

Least privilege (1.1), and the credentials CERT-In found. The agents in the Indian cases got in with credentials that had been left lying around. Inside a Bromure VM, whatever an agent finds lying around is a stand-in. Model keys, git tokens and anything you bring in with Import env file… show up as values like sk-ant-api03-brm-…. The AWS helper hands the VM a fake secret access key and signs the real request on the Mac. kubectl gets a synthetic kubeconfig that points at the proxy. An agent that greps the home folder or the environment gets values that only work through your Mac, for the host each one was issued for. New machines also start with Prompt before write on every guarded service, so a write to GitHub, AWS, Kubernetes or a registry waits for you to approve the exact operation.

Single-use infrastructure and agent-to-agent channels (1.2). Each machine is its own VM with its own disk, home and policies. Machines share no filesystem. An automation can run in a disposable clone of the workspace: a copy-on-write duplicate booted when the run fires and deleted when it ends. bromure-cli vm run --rm gives you a throwaway machine by hand. When one agent hands work to another, the message goes through the Bromure host, which screens it with the on-device prompt-injection detector and logs it. The two agents never connect directly.

A strict allowlist through a monitored gateway (1.5). CERT-In insists this control can't be an instruction to the model. Each machine's egress firewall is an ordered list of allow and deny rules by host, IP range, protocol, port and, for web traffic, HTTP verb. Set Unmatched traffic to Deny and it becomes an allowlist. The Mac enforces the rules twice: the virtual switch checks every connection, and the proxy checks the TLS server name. The switch diverts the VM's web traffic into the proxy at the network layer, so a tool that ignores proxy settings still goes through it. allow web api.example.com GET lets an agent read an API it may not write to, whichever tool it reaches for.

Monitors the agent can't touch (3.3). The Mac writes the session trace and the Security Timeline to its own disk. Bromure seals trace bodies with AES-GCM under a key held in the macOS Keychain, and no VM ever mounts either one. An agent that deletes its own shell history or rewrites its own transcript inside the VM changes nothing in the record you read later.

Canaries (3.5). NIST suggests "placing canaries in environments to detect agent instances that have obtained access outside intended bounds." In Bromure every stand-in is a canary. Each one has one legitimate destination, the host it was minted for. The proxy scans every outbound request, headers and body, for stand-ins headed anywhere else. It also flags real-looking secrets that Bromure didn't issue, such as a key an agent dug out of a public repository's history. Those show up as leak warnings in the Trace Inspector and in bromure-cli trace leaks.

Automatic shutdown (6.2) and evidence (5.1). When a stand-in heads to the wrong host, the proxy answers HTTP 451 and forwards nothing. The VM pauses on the spot and the Mac shows This environment may have been compromised, naming the credential, the host it belongs to and the host it was sent to. Shut down is the default button. Save for Investigation exports the system disk, the home folder and each shared folder before stopping the VM, which preserves the environment the way practice 5.1 asks.

Logs with reliable timestamps, tool calls and rejected actions (5.3). At the default trace level, the Mac records every request with its time, host, method, status and credential swaps. It keeps full bodies for model traffic and parses them into the agent's tool calls, shell commands and file reads and writes. The Security Timeline keeps every block and allow from the firewall, Guardrails, the supply-chain checks, prompt-injection detection and the credential broker for 90 days. Those are the rejected actions NIST wants on file.

Revoke and rebuild (6.4, 7.1). After an incident, NIST wants exposed credentials revoked and environments rebuilt "from verified baselines." The VM never held a real credential, so there's nothing in it to revoke. A machine flagged compromised refuses to boot until you confirm a wipe of its system disk, home and saved state. It then comes back from the signed Ubuntu base image with your settings and keys intact. Short of an incident, Reset disk re-clones the system disk from that image, and Rewind home… rolls the home folder back to the state it was in at an earlier boot.

Check containment before restarting (7.3). The Security Timeline's Overview has a Protections table with one row per machine, showing which have the firewall, Guardrails, supply-chain checks, prompt-injection detection and PII protection turned on. A machine running with fewer protections than the rest stands out before you hand it the next long task.

Friday night, Monday morning

Take the integration-suite run from earlier. Around 2 a.m. the tests still fail against the mocked payment service, and the agent decides the real staging endpoint would settle it. It looks around the machine and finds STRIPE_KEY in its environment and an AWS profile in ~/.aws/config.

On a laptop, the next step is a request with a real key to a real system, and the same thing CERT-In described: access that nobody notices, logged in a transcript the agent can edit.

On a Bromure machine with an allowlist, the call to the staging host never leaves the Mac. The firewall denies it, the agent gets a clean error, and the Security Timeline records a red Firewall row. The keys it found are the stand-ins Bromure put there, so they're useless anywhere else. When the agent tries a workaround and posts the GitHub stand-in to a paste site, the proxy answers 451 and the VM freezes mid-step. On Monday you open the Security Timeline, filter on the machine and read what happened in order: the denied host, the blocked upload, the paused VM. Then you open the trace for the tool calls that led there. If you want to be sure, you wipe and relaunch.

Put the controls under the agent

Both agencies start from the same assumption: a capable agent with a goal and time will find whatever was left exposed. Neither relies on the model's instructions. They ask for rules enforced on the network, logs out of the agent's reach and a stop that triggers on its own.

On a developer's Mac, that means running the agent in a VM and keeping the controls on the host. For the evaluation incidents that led here, read The sandbox was a sentence and The task was impossible, so the agent got out.