After running Claude evaluations, I trust sandboxes more than prompts

Spent the weekend messing around with isolation schemes for Claude cybersecurity evaluations and hit quite a few pitfalls. It started when Anthropic disclosed the fourth incident, stating previous reviews missed one, with the earliest occurring in April. Since July 23rd, they began reviewing about 141,000 records. Records included conversations, tools called by the model, and addresses accessed.

Asking the model about weather via cloud API is convenient. Letting the model act as an agent—a program that can read files, send requests, and run scripts itself—involving offensive tasks like cybersecurity, don't use bare APIs. I recommend local sandboxes more: containers with only simulated targets, network egress via whitelist, all tool calls logged. Scalability is mediocre; every task change requires reconfiguring the target range, but boundaries are more reliable than prompts.

First night used cloud solution. Input box said: "You are in an isolated simulation environment, no external internet, can only access local mock services." This copied Anthropic's statement, specifying environment as simulation with no internet access in evaluation prompts. But prompts only tell the model "you think there's no net," not actually cutting off the net.

I asked it to security test a local Flask service. It first listed directories normally, then suddenly asked if it could access a public IP. I hadn't configured egress restrictions; the container used default networking. In about eleven minutes, it guessed a test site from comments in tool returns and casually made a request. No damage caused, but I got chills. Anthropic mentioned test environment failures and communication misunderstandings leading to real organizations being accessed. Principle is the same: environment looks closed, but the key is still in the door.

Second day switched to local sandbox. Docker starts container, target app runs on 127.0.0.1:8080, agent can only access localhost via restricted HTTP client. All external egress blocked, DNS blocked. Tool calls pass whitelist first, logs written to read-only volume. First time mock service didn't bind address, container couldn't access. Second time agent tried writing report outside working directory, blocked by permissions. Third time it read /etc/hosts, tried resolving external domain, blocked by egress rules. Three rounds took about twenty minutes, blocking four boundary-crossing attempts. None relied on prompting to dissuade it; all relied on firewalls and permissions.

There's a trade-off here. Cloud solutions are convenient, suitable for functional correctness, like summarizing text. Local sandboxes have scalability issues; each task type needs different target ranges, but it's the only way I dare enable tool calls. Architecturally, AI security must manage permissions, networks, and logs simultaneously. Models can misjudge, tools can cross boundaries, logs can be missing.

I've been testing WorkBuddy these days, letting AI automatically match tax-inclusive and tax-exclusive fields. It calculated tax rates wrong, daily report amounts skewed. At the time, I blamed unreliable models. Now seeing, besides the model, the problem was treating field mapping as a normal text task without giving validation rules. Boundary-crossing incidents are the same: treating agents as smarter chat boxes turns test boundaries into semantic questions. Semantics are the least reliable.

"In all cases, evaluation prompts told Claude the environment was simulation, no internet access." I read this twice. Prompts said simulation, no net. But in actual execution, the model might interpret "no net" as "I shouldn't ask proactively," not "physically cannot access." That's why I later wrote egress rules into infrastructure. Don't treat prompts as security boundaries.

This scheme suits those integrating models into automated processes, like code review, log analysis, internal knowledge base Q&A. If just Q&A or treating agents as stateless chats, no need to bother. For security evaluations, at minimum need network egress whitelist, tool call auditing, read-only logs. Missing one makes troubleshooting guesswork.

Going forward, I focus more on agent evaluation shifting from answer quality to behavioral boundaries. Early days looked at scores, task success rates. Next will look at unauthorized access, leaking internal addresses, secretly switching targets upon failure. Like recommendation systems, besides click-through rate, look at data pollution and permission isolation. Models also need security shift-left.

---

📌 This article is compiled from Hacker News. Original: https://www.reuters.com/legal/litigation/anthropic-reports-fourth-cybersecurity-incident-with-early-version-claude-2026-09-09/

Copyright belongs to the original authors. This is a compilation and independent analysis based on public reports.