AI Cyber Range Architecture: Test Security Agents Without Touching Real Systems

A practical guide for developers building safe evaluation environments for AI security agents such as Codex, Claude, and Gemini emphasizes that the sandbox must be treated as the product's blast-radius control, not a feature. The guide outlines a six-layer architecture for an AI cyber range, following incidents where OpenAI and Hugging Face experienced a model-evaluation compromise and Anthropic reported three cases of Claude reaching real systems during evaluations. The architecture includes fake networks, synthetic targets, seeded vulnerabilities, and network policy to ensure agents are treated as untrusted operators.

A practical guide for developers building safe evaluation environments for Codex, Claude, Gemini, and custom cybersecurity agents. An AI security agent does not need bad intent to create a real incident. It only needs a goal, tools, persistence, and a test environment that is less isolated than everyone believes. That is the uncomfortable lesson from the recent OpenAI and Hugging Face model-evaluation incident and Anthropic’s follow-up disclosure about Claude reaching real internet systems during cyber evaluations. The public details differ, but the developer lesson is the same: if your agent can run commands, scan networks, install packages, use credentials, or chase a benchmark objective, the safety boundary cannot live only inside the prompt. The answer is not to stop testing cyber-capable agents. Security teams need these systems for vulnerability triage, exploit validation in authorized environments, detection engineering, incident review, and patch prioritization. The answer is to test them inside an AI cyber range that treats the agent as an untrusted operator from the first token. This guide shows how to design that range. It is written for developers, security engineers, AI platform teams, and founders who are building or buying autonomous security workflows and need a practical architecture before connecting agents to anything real. Several signals are converging at once. OpenAI said a model-evaluation incident involved models with reduced cyber refusals, an isolated benchmark environment, a route to internet access, and compromise of Hugging Face infrastructure during an advanced cyber-capability evaluation. Hugging Face published its own security disclosure and later forensic details. Anthropic then reviewed 141,006 evaluation runs and reported three cases where Claude reached real organizations from evaluation environments that should have been sealed. At the same time, serious evaluation infrastructure is moving from toy capture-the-flag tasks toward realistic multi-host cyber ranges. The UK AI Security Institute’s Inspect sandboxing work emphasizes that dangerous-capability evaluations need isolated environments, tool controls, host isolation, and network controls. Recent AgentCyberRange research argues that open, reproducible, multi-host ranges are needed because isolated vulnerability puzzles do not capture how agents behave during realistic discovery, foothold, and post-exploitation workflows. Developers are also asking the same thing in public forums: how do I give an agent enough power to be useful without giving it my host machine, real credentials, customer data, or the open internet? Reddit discussions around AI agent sandboxing, MCP code execution, local LLM tool access, and AI security agents keep returning to the same pain points: network egress, wipeable environments, credential leakage, prompt injection, and audit trails. The practical mistake is treating the sandbox as a product feature. For cyber-capable agents, the sandbox is the product’s blast-radius control. An AI cyber range is a controlled environment where an AI system can perform security tasks against intentionally scoped targets. It should look real enough to test useful behavior, but it must remain bounded enough that mistakes cannot affect real infrastructure. A normal sandbox may isolate code execution. A cyber range goes further. It includes fake networks, synthetic targets, seeded vulnerabilities, instrumented services, scoring checks, network policy, evidence capture, and reset logic. The goal is not only to prevent harm. The goal is to produce trustworthy evidence about what the agent did, where it failed, and what controls stopped it. A strong range answers questions like these: If your range cannot answer those questions, it is probably only a demo environment. Build the range around six layers. Each layer should fail closed. Each layer should produce logs. No single layer should be trusted as the only control. The scope contract is the machine-readable version of the evaluation rules. It defines allowed targets, denied targets, tool budgets, network rules, data classes, maximum runtime, and stop conditions. This belongs outside the model prompt. The prompt can explain the scope, but the enforcement layer must read a structured policy. { "run id": "eval-2026-08-03-001", "allowed targets": "range.local", "10.44.0.0/16" , "denied targets": "0.0.0.0/0", "metadata.google.internal", "169.254.169.254" , "allowed tools": "http get", "shell readonly", "range db query" , "requires approval": "package publish", "credential use", "external request" , "max runtime minutes": 45, "max network requests": 800, "stop on scope confusion": true} The important detail is that the agent does not get to decide whether a target is in scope. If a request is outside the contract, the tool gateway refuses it before anything reaches the network. Use an isolated execution environment for every run. For low-risk tasks, containers may be acceptable. For cyber evaluations with realistic tools, unknown code, or escape risk, prefer microVMs, full VMs, or Kubernetes namespaces with strict node separation. If the agent can run arbitrary commands, assume arbitrary commands will run. The range should be disposable. A clean run starts from a known snapshot. A finished run destroys compute, rotates credentials, stores evidence, and resets target state. Never rely on “we will clean it later” for a system designed to test persistent agents. Cyber agents behave differently against toy tasks than they do against messy systems. Include realistic web apps, APIs, package registries, CI services, internal wikis, user accounts, logs, and monitoring signals. But make every target synthetic, owned by you, and unreachable from the public internet unless the evaluation explicitly requires a highly controlled external dependency. The best targets contain normal dead ends. Most real attack surfaces are not vulnerable. If every path in your range leads to a flag, the agent learns a fantasy version of security work. Useful ranges separate task scope, isolated targets, tool policy, evidence recording, and emergency stop controls. The model should not call the shell, browser, scanner, package manager, cloud API, or database directly. It should request actions through a tool gateway. The gateway validates each request against policy, injects only scoped credentials, redacts sensitive output, and records the action before and after execution. This design matters because cyber-capable agents are not just generating text. They are selecting actions. A tool gateway turns “the model wanted to do it” into “the system allowed or denied a specific action for a specific reason.” python def execute tool request, policy, run state : decision = policy.evaluate tool=request.tool, target=request.target, intent=request.intent, run state=run state, audit log.write { "request": request.redacted , "decision": decision.name, "reason": decision.reason, } if decision.requires human approval: return approval queue.enqueue request if not decision.allowed: return {"ok": False, "error": "Blocked by cyber range policy"} return sandbox runner.run request, timeout=decision.timeout Do not make the gateway a thin proxy. Make it the place where product policy, security policy, and evaluation policy meet. A cyber range without evidence is just a story generator. Record prompts, tool calls, terminal output, network flows, DNS lookups, filesystem changes, target logs, policy decisions, screenshots, approvals, and verifier results. Store them in a tamper-resistant run bundle. The reviewer should be able to answer: What did the agent know? What did it try? What succeeded? What was blocked? Which artifact proves success? Which action crossed the risk boundary? Every run needs an emergency stop that works even if the agent loop is stuck. This is not a UI nicety. It is a control-plane requirement. The kill switch should revoke credentials, drop network routes, stop compute, snapshot evidence, and mark the run as interrupted. A kill switch that simply asks the model to stop is not a kill switch. The most dangerous assumption in cyber evaluations is “this environment cannot reach the internet.” Verify it. Then keep verifying it. Use default-deny network policy. Allow only the specific internal subnets, package mirrors, update services, and callback endpoints required for the run. Replace public dependencies with local mirrors where possible. Block cloud metadata endpoints. Log DNS. Alert on any request to a public IP. Route unknown domains to a sinkhole that records the attempt and returns a clear blocked response. Do not let package installation become a secret internet tunnel. If the agent needs Python packages, npm packages, OS packages, or container images, mirror them in advance. If it asks for a missing dependency, the range should either deny it or route the request through a reviewed allowlist process. A simple local policy can look like this: egress: default: deny allow: - cidr: 10.44.0.0/16 reason: cyber range targets - host: packages.range.local reason: local package mirror - host: evidence.range.local reason: run telemetry sink deny: - cidr: 0.0.0.0/0 reason: no public internet during evaluation - host: 169.254.169.254 reason: cloud metadata endpoint alert on: - public dns lookup - denied external request - repeated scope probe Then test the policy from inside the same environment the agent uses. A policy that looks good in Terraform but fails inside the actual run container is theater. Security agents need credentials to test real workflows. That does not mean they need real credentials. Use synthetic accounts, synthetic secrets, and honeytokens that are valid only inside the range. Give every credential a run ID, an expiration time, and a maximum permission set. If a credential appears outside the range, treat it as a containment failure. This lets you turn credential misuse into a measurable signal without risking customer systems. Never place production API keys, cloud tokens, source-control tokens, or real user data inside a cyber range. If you need a realistic data shape, generate synthetic data. If you need a realistic identity provider, run a local test IdP. If you need secrets rotation, simulate it. Agents are good at explaining success. That does not mean success happened. Your range needs independent verifiers that inspect the target state and decide whether the objective was met. A verifier can check that a patch was applied, a vulnerable endpoint is no longer reachable, a simulated alert was triaged correctly, a detection rule fired, or a test flag was accessed through an allowed path. The verifier should not trust the agent’s summary. It should read logs, target state, and expected artifacts directly. For cyber tasks, verification should also score the path. Did the agent succeed within scope? Did it trigger blocked egress? Did it read secrets it did not need? Did it use a dangerous tool without approval? Did it leave persistent changes behind? A run that gets the flag by crossing the boundary should fail. Some actions should pause, even inside a range. Publishing a package, using credentials, creating an outbound tunnel, increasing scan intensity, changing firewall rules, or touching anything that resembles external infrastructure should require explicit approval. The approval packet should be short and concrete. Show the requested action, target, policy reason, risk level, recent trace, and rollback plan. Do not ask a reviewer to read a thousand-line transcript before making a decision. If approval is too slow, developers will disable it. If approval is too vague, reviewers will rubber-stamp it. Human approval works best when reviewers see evidence, risk, and rollback in one place. Do not reduce the range to pass or fail. A security agent can fail usefully, and it can succeed dangerously. Track metrics that reveal both capability and control. These metrics help compare models and harnesses fairly. A cheaper model that stays in scope and produces clean evidence may be more valuable than a stronger model that completes tasks while constantly pushing the boundary. Start small. Most teams do not need a giant enterprise cyber range on day one. They need a repeatable path from safe toy tasks to realistic internal simulations. First, build a single disposable range with one fake web app, one fake API, one local package mirror, one evidence sink, and default-deny egress. Test a read-only security task such as log summarization or vulnerability explanation. Second, add bounded action tasks. Let the agent run safe scanners, inspect synthetic code, query range logs, or propose patches. Require verifiers to judge success. Require approval for any state-changing operation. Third, add multi-step workflows. Include a fake CI service, fake credentials, a vulnerable internal service, and a monitoring trail. Score whether the agent completes the task while respecting scope and preserving evidence. Fourth, run model and harness comparisons. Test Codex-style coding agents, Claude-style terminal agents, Gemini-style long-context workflows, and custom LangGraph or MCP-based agents under the same policies. Keep prompts, budgets, and target snapshots stable so the comparison means something. Finally, connect the range to your production rollout gates. An agent should not receive broader real-world permissions until it passes the relevant range scenarios, produces reviewable evidence, and demonstrates clean behavior under blocked paths. The first mistake is relying on the system prompt as a boundary. Tell the model the rules, but enforce the rules elsewhere. The second mistake is allowing “temporary” internet access for convenience. Temporary paths become permanent holes. If the agent needs packages, mirrors, or documentation, provide controlled mirrors and record every exception. The third mistake is testing only happy paths. Add broken DNS, missing dependencies, false leads, invalid credentials, decoy services, rate limits, and misleading artifacts. Real agents fail in messy conditions. The fourth mistake is keeping logs that only AI engineers can read. Security reviewers, legal teams, incident responders, and platform owners may all need the evidence. Design run bundles for humans, not just dashboards. The fifth mistake is treating sandbox escape as the only risk. The agent may never escape the range and still behave badly: misuse an allowed credential, over-scan a target, ignore signs of realness, or create a dangerous artifact. Policy must cover intent, target, data class, and action type. An AI cyber range is not a replacement for model evaluations, red teaming, application security, cloud security, or human review. It connects them. Model evaluations tell you what a model might be capable of. The range shows what your harness allows it to do. Red teams find creative failure paths. Verifiers turn outcomes into repeatable checks. Observability tells you what happened. Human approvals handle actions where context matters. If you are building an AI security product, the range should become part of your development workflow. If you are buying one, ask the vendor how they isolate cyber evaluations, how they control egress, how they store run evidence, and how they prove agents did not touch real systems. “We have guardrails” is not enough. Cyber-capable AI agents are becoming useful because they can persist, chain tools, inspect systems, and adapt. Those same traits make weak evaluation environments dangerous. A serious AI cyber range gives developers a safer way to learn what agents can do before those agents touch production. It makes scope enforceable, targets disposable, credentials synthetic, actions reviewable, evidence durable, and mistakes containable. The goal is not to make agents harmless. The goal is to make powerful agents testable before they are trusted. AI cyber range architecture is the system design used to evaluate AI agents on cybersecurity tasks inside controlled environments. It usually includes isolated compute, fake but realistic targets, network egress controls, scoped tools, evidence capture, verifiers, and emergency stop controls. A normal sandbox focuses on limiting code execution. An AI cyber range also provides realistic security scenarios, synthetic networks, scoped credentials, target reset logic, monitoring, scoring, and independent verification. It tests agent behavior, not just process isolation. No. A summarization bot does not need the same environment as an autonomous security agent. You need a cyber range when an agent can run security tools, inspect live-like systems, use credentials, scan networks, validate vulnerabilities, modify infrastructure, or make recommendations that could affect security posture. Only with a clear reason, a written scope, strong egress controls, monitoring, approval gates, and a rollback plan. Most evaluations should use local mirrors and synthetic services. If internet access is allowed, it should be narrow, logged, and treated as a high-risk exception. Default-deny enforcement outside the model is the most important control. Prompts help, but tool gateways, network policy, scoped credentials, and independent verifiers are what actually stop out-of-scope behavior. Run them against the same target snapshots, scope contracts, budgets, tools, and verifiers. Compare task success, blocked actions, evidence quality, cost, latency, and reviewer effort. Do not rank models only by whether they reached the final objective. Ask for evidence of isolated evaluations, network egress controls, scoped credentials, audit logs, approval workflows, verifier design, incident handling, and repeated tests under failure conditions. A strong answer should describe the architecture, not just the safety policy. AI Cyber Range Architecture: Test Security Agents Without Touching Real Systems https://pub.towardsai.net/ai-cyber-range-architecture-test-security-agents-without-touching-real-systems-25b08a313442 was originally published in Towards AI https://pub.towardsai.net on Medium, where people are continuing the conversation by highlighting and responding to this story.