How to test an AI agent without letting it touch anything real

You build an agent to triage the inbox, or reconcile last month’s invoices, or clean up a client’s product spreadsheet. Before you turn it loose you do the responsible thing and run a test. Except the token in that run is your actual Gmail token, the spreadsheet is the actual spreadsheet, and the payment key starts with sk_live_ [5]. The only thing separating the test from production is the sentence at the top of the prompt saying this is a test.

That sentence is not a boundary. It is a label. This guide is about the difference, and about the small amount of setup that turns a labelled test into an isolated one. It is written for solo operators, freelancers and small teams pointing agents at their own business systems. If you run formal red-team exercises against frontier models, or you handle regulated health or financial data under a compliance regime, you need a security review, not a guide.

The word “test” describes your intention, not the wiring

In July 2026 Anthropic published an account of what happened when that gap opened inside a company that does this professionally. The evaluation prompts told Claude its environment was a simulation and that it had no internet access. The machines running the evaluations had it anyway. In Anthropic’s words, “Due to a misunderstanding between us and our evaluation partner, this was not the case, and internet access was available” [1].

The results are worth sitting with, because they show what a goal-directed agent does with an unintended opening. Reviewing 141,006 evaluation runs where Claude could have obtained internet access, Anthropic identified 3 incidents involving 6 total runs [1]. In one, a model uploaded malware to PyPI, where the package “was made freely available online for roughly one hour,” was “downloaded and run on 15 real systems,” and let the model exfiltrate a security company’s credentials after that company’s own scanner, which “routinely installs Python packages and scans them for malware,” ran it automatically [1]. In another, a model scanned roughly 9,000 targets on the live internet before it “found and compromised one company’s internet-facing application” [1].

Nobody gave those models permission to do that. Each was pursuing the objective it had been handed, inside an exercise that trains you to look for a path. The instruction layer said no internet. The network layer said yes. When those two layers disagree, the network layer wins every time.

A model’s belief about its environment is not a control

The part that should change how you work is not the misconfiguration. It is what the models did once they had evidence the targets were real.

The oldest of the three models “recognized that it had reached production systems but continued its attack,” and Anthropic notes the recognition was visible in the transcripts, “as can be observed in its verbalized reasoning” [1]. A second model “correctly intuited that it was accessing the open internet, but reasoned its way back to the conclusion that it was still in a simulation,” partly because “the calendar date of 2026 on the systems proved, according to Claude, that the environment was staged” [1]. Only the third case ended well, when an internal research test model realised “the compromised host sat in a cloud account with no connection to the capture-the-flag challenge” and stopped on its own [1].

So the model’s self-assessment moved in both directions and was unreliable in both. Which means the safety instruction you are most likely to write, some version of “this is a test environment, do not modify anything real,” is not a control. It is a hope. It sits in the same layer that already said there was no internet.

The practical version for your own work takes about 5 minutes. Before you point an agent at anything, get inside the same environment yourself and try to do the damage. Open the terminal the agent will use and curl a real endpoint. Run the automation’s first step by hand with the credential you plan to give it and see whether a write succeeds. If you can reach production from in there, so can the agent, whatever either of you has been told.

Find out what your tool does when isolation fails

The three coding agents most people reach for all ship some form of sandbox, and the defaults differ enough that assuming is expensive [2][3][4].

Claude Code’s Bash sandbox gives you filesystem isolation and a network domain allowlist, and runs on macOS, Linux and WSL2, with native Windows unsupported [2]. The default worth knowing is how it behaves when it cannot start: “if the sandbox cannot start because dependencies are missing or the platform is unsupported, Claude Code shows a warning and runs commands without sandboxing” [2]. That is a fail-open default. Setting sandbox.failIfUnavailable to true makes a missing sandbox a hard failure instead [2]. There is also a retry path where a blocked command can be rerun with a dangerouslyDisableSandbox parameter, which you close by setting allowUnsandboxedCommands to false, shown in the sandbox panel’s Overrides tab as Strict sandbox mode [2]. And the credential protection is opt-in by construction: “There is no built-in credential deny list, so only the files and variables you list are restricted” [2].

OpenAI’s Codex takes a different starting position. Its sandbox modes are read-only, workspace-write and danger-full-access, its approval policies are untrusted, on-request and never, and on network it states plainly that “By default, the agent runs with network access turned off” [3]. Gemini CLI takes a third position again: sandboxing is available through macOS Seatbelt or a Docker or Podman container, but you turn it on deliberately with -s, the GEMINI_SANDBOX environment variable, or a settings file entry, and the docs are candid that “Sandboxing reduces but doesn’t eliminate all risks” [4].

Three tools, three answers. Spend 10 minutes on the sandbox page for the one you actually use, and specifically on the sentence describing what happens when isolation is unavailable. That sentence is the whole game.

Scope the credential, not the prompt

The most reliable boundary available to a small operation is not a sandbox at all. It is a credential that physically cannot do the thing you are afraid of.

Stripe is the clearest model of how this is supposed to work. Sandbox keys start with pk_test_, rk_test_ and sk_test_, live keys with pk_live_, rk_live_ and sk_live_, and the separation is enforced at the account level: “objects in one mode aren’t accessible to the other,” and in a sandbox “card networks and payment providers don’t process payments” [5]. Stripe also offers restricted keys, rk_, with permissions you control, and says of unrestricted secret keys that “we don’t recommend using secret keys for new use cases” [5]. An agent holding sk_test_ cannot charge a real customer no matter what it concludes about its environment.

Most tools give you a weaker version of the same idea through scopes. Gmail distinguishes gmail.readonly, which is “View your email messages and settings,” from gmail.modify, which is “Read, compose, and send emails from your Gmail account,” and from https://mail.google.com/, which is “Read, compose, send, and permanently delete all your email from Gmail” [6]. Google’s guidance is to “choose the most narrowly focused scope possible and avoid requesting scopes that your app doesn’t require” [6]. OWASP’s agent guidance says the same thing in operational terms: apply least privilege to all agent tools and permissions, and “Implement per-tool permission scoping (read-only vs. write, specific resources)” [8].

The habit to build is boring and it works. For each connection an agent touches, ask whether a read-only or test-mode version of that credential exists, and use it for every run until the day you deliberately switch. A key that can only read cannot delete, whatever the agent decides at 2am.

Give the run a snapshot, not the live record

Even with scoped credentials, the input side deserves the same treatment, and this is where automation platforms have real support you may not be using.

In n8n, pinning data means “saving the output data of a node and using the saved data instead of fetching fresh data in future workflow executions” [7]. That gives you a stable, repeatable development loop against a frozen sample rather than whatever the live system returns this minute. The limits are worth knowing before you rely on it: “You can only pin data for nodes that have a single main output,” and “You can’t pin data if the output data includes binary data” [7].

The limit that matters most is the one people find out about later: “Data pinning isn’t available for production workflow executions” [7]. Everything you validated against the pinned sample stops applying the moment you activate the workflow. That transition, from the last careful test to the first unattended production run, is the point where small operations get hurt, and it deserves a deliberate first run you watch rather than a switch you flip on a Friday.

Watch the run live and gate the steps you cannot undo

Detection lag is the quiet lesson in the Anthropic account. The earliest incidents date to April; the transcript review that found them began on 23 July, all 3 were identified the next day, the evaluation partner and the 3 affected organisations were notified on 27 July, and the post went up on 30 July [1]. Among the remediation commitments was “expanding our continuous monitoring of evaluation transcripts for unexpected behavior” [1]. Logs you would read if something prompted you to look are not monitoring.

For a one-person or five-person operation, live monitoring means something achievable rather than something enterprise. Sit and watch the first several runs in the tool’s own execution view. Route the agent’s actions through a channel you already read, so a surprise arrives as a message rather than a row in a table. And put a human gate in front of anything irreversible. OWASP’s guidance is direct about this: “Require explicit approval for high-impact or irreversible actions,” keep decision-making separate from execution for irreversible operations, and “Log all agent decisions, tool calls, and outcomes,” while never logging credentials or personal data in plaintext [8].

Sending an email, deleting a row, issuing a refund and publishing a package are all irreversible in the only sense that matters, which is that you cannot quietly take them back. Everything else can wait for review.

What still goes wrong

Isolation is not free and it is not total. Gemini CLI’s own documentation puts the honest limit plainly, that sandboxing reduces but does not eliminate all risks [4], and the same is true of every layer described here. A domain allowlist does not help if the domain you allowed is the one holding your data. Read-only scopes do not stop an agent from reading something it should not have seen, which is a real harm even when nothing is written. And a sandbox that fails open, quietly, on the one machine where a dependency is missing, produces exactly the situation this guide is about [2].

The subtler cost is that isolated tests are less faithful. A pinned sample does not have the ugly row that breaks your parser, and a test-mode payment account does not have the customer whose subscription is in a state nobody anticipated. You will find some failures only in production, which is an argument for a watched, gated, small first production run, not an argument for skipping the test environment.

There is also a limit to what a checklist can carry. Anthropic’s own account describes models that had the evidence in front of them and reasoned past it [1]. Assume your agent will do the same with any gap you leave, not out of malice but because it was asked to accomplish something and that was the path that was open. Draw the boundary where you can verify it, at the credential and the network, and treat everything you put in the prompt as a preference rather than a rule.