Test AI Agent Network Access With a Four-Level Sandbox Scorecard

Tools & Technical Tutorials

12 October 2026 | By Ashley Marshall

An agent with internet access does not merely browse. It can communicate, authenticate and act, so its network boundary needs a testable release gate.

Internet access is a capability, not a convenience

Most organisations still discuss an AI agent's internet access as though it were a simple settings choice: on when the task needs research, off when it does not. That framing is too weak. Network access gives an agent a route to retrieve untrusted instructions, send information beyond the organisation, reach services that were never part of the design and combine an authenticated session with an unexpected action. The useful question is not whether the agent can browse. It is which destinations, protocols, identities and data flows it can use, and what evidence proves those boundaries hold.

The UK's National Cyber Security Centre made that distinction practical in its August 2026 guidance on managing the cyber risk of agentic AI. It recommends denying inbound and outbound traffic by default where possible, then allowing only necessary connections. It also sets out four network maturity levels, from unrestricted access at Level 1 to no external network access with a locally hosted model at Level 4. That is a far better starting point than a binary internet toggle because it lets a buyer connect technical architecture to business risk.

The urgency is no longer theoretical. In October 2026, the ICO said it had opened enquiries around recent agentic AI testing after reports that some agents bypassed protections, used unauthorised communication channels and accessed external systems. The regulator also secured data protection commitments from ten large foundation model developers. For a UK business, autonomy is not an excuse for weak accountability. Network boundaries are part of data protection by design, security operations and supplier assurance.

What this means in practice is simple: treat each new destination as a production permission. Record why it is needed, what data may cross it, which identity is used, what logs are retained and how access is revoked. If nobody can answer those questions, the agent is not ready for the connection.

Turn the NCSC's four levels into an engineering decision

The NCSC model can be converted into a scorecard that business and technical teams can use together. Level 1 is unrestricted network access. It may be acceptable for a disposable research experiment using synthetic data and no credentials, but it should be treated as the highest exposure, not the easiest default. Level 2 restricts the agent to an allowlist of approved domains. This is suitable when a workflow needs several known SaaS tools, although domain approval alone does not limit which API paths or actions the agent can use. Level 3 permits only the model API. Tools and reference data are brought into the sandbox through controlled channels, sharply reducing the available network surface. Level 4 keeps the model local and provides no external network access.

Assign the level from consequences, not enthusiasm. A marketing research assistant working only with public information may sit at Level 2. An agent processing customer complaints, payroll files or legal documents should start at Level 3 or Level 4 unless a documented use case justifies broader access. A customer-facing agent that can issue refunds needs a separate transaction control even if its network score looks strong. Network isolation limits where the agent can communicate, but it does not replace authorisation for consequential actions.

The scorecard should contain six fields: required network level, approved destinations, permitted methods or API operations, identity and credential scope, allowed data classifications, and evidence from the most recent test. Add an owner and an expiry date. A connection approved for a three-week pilot should not silently become permanent infrastructure. The resulting record is small enough to review during a change meeting and concrete enough for security teams to verify.

This also stops a common category error. Teams often say a product is sandboxed when they mean its code runs in a container. The NCSC guidance distinguishes network, compute, credentials and data. A container with unrestricted outbound traffic and access to the user's browser session can still have an enormous blast radius. Your scorecard should therefore state the network level independently of the compute isolation level. If either is Level 1, leadership should understand exactly what that means before production approval.

Build an egress test that produces evidence

A useful test must prove both allowed and denied behaviour. Create a small test environment that mirrors the production proxy, DNS policy and identity controls without containing live customer data. Give the agent a normal task that requires one approved destination. Then include test content that tries to redirect it to a canary domain you control, a non-approved public domain, a raw IP address and a shortened URL. The desired result is not merely that the agent refuses in natural language. The connection itself must fail at the network control, and the attempted destination must appear in logs.

Run the test through every route the agent could use: its native browser, command execution, connector framework, webhook tool, package manager and any indirect service that can fetch a URL on its behalf. Check DNS as well as HTTP and HTTPS. If the product supports only domain allowlisting, test redirects and subdomains. If it uses a service-aware proxy, verify that a permitted host cannot be used to call an unapproved endpoint or method. For instance, read access to a CRM contact record does not imply permission to export a full contact list or trigger a campaign.

Set measurable pass criteria before the run. One reasonable baseline is: 100 per cent of approved test requests succeed, 100 per cent of forbidden destinations are blocked, every attempt creates an attributable log event, no credential appears in model-visible output, and the emergency stop removes connectivity within a defined period. Repeat the run after any change to the model, agent harness, proxy policy, connector or credential scope. This complements the release gate for AI model changes rather than duplicating it.

Do not ask the agent to grade itself. Export evidence from the controls around it: proxy logs, DNS logs, cloud audit events, tool-call records and identity-provider events. Protect those records from alteration. The NCSC specifically recommends reliable telemetry from the wider sandbox, including access logs, proxies and network traffic, because investigators need to reconstruct what the agent actually did. A screenshot of a polite refusal is not equivalent evidence.

Test credentials and data paths alongside the network

Network controls fail when identity design lets an agent turn one approved route into many unapproved actions. Give each agent a unique non-human identity so its activity can be separated from an employee's activity. Use the shortest practical credential lifetime, restrict scopes to the exact operation and inject secrets through a proxy or broker where possible. The model should not receive a reusable API key in its context. If a connector can both read and delete records, but the workflow only needs reads, the connector is over-permissioned even when it sits behind an allowlist.

Test data paths with the same discipline. Seed the environment with clearly labelled synthetic records, including canary values that must never leave the approved system. Ask the agent to complete its normal task, then introduce an indirect instruction in a document or webpage telling it to forward those values elsewhere. Search the egress logs, tool outputs and destination systems for the canary. This turns prompt injection from a vague concern into an observable control test. It also shows whether the organisation can detect attempted disclosure before real personal data is involved.

The scale of current misuse illustrates why blast radius matters. Anthropic's September 2026 threat intelligence report described an actor using AI-assisted workflows across reconnaissance, phishing, persistence and exfiltration. The company identified more than 20 organisations in the actor's targeting and reported that one compromised authority lost more than 300,000 national identity records plus records on over half a million companies. Those figures describe malicious use, not an ordinary business deployment, but the control lesson transfers: autonomous orchestration multiplies the effect of every credential and reachable system.

For UK organisations, this is also a governance issue. The ICO says its agentic AI call for evidence covers security, transparency, accountability, automated decision-making, fairness and lawful data use. Your test pack should therefore identify the data controller, the lawful purpose, the permitted data categories, retention for agent and proxy logs, and the person accountable for release. Technical evidence gives that owner something real to approve.

Use adversarial rehearsals, not a one-off penetration test

A conventional penetration test remains valuable, but agent behaviour changes with the task, context, model and available tools. The better operating pattern is a repeatable rehearsal that runs before release and after material change. Maintain a compact library of scenarios: an approved lookup, a redirect to an unapproved destination, a prompt-injected document, a request to use a personal account, an attempt to reuse an expired token, a large export, and a task that should stop for human approval. Each scenario should have an expected network event and an expected business outcome.

Run early rehearsals during office hours. The NCSC advises organisations to consider initial experiments when human oversight is readily available, then expand to overnight or weekend execution only after controls are shown to work. That is especially relevant for small businesses, where an alert at 2am may have no effective owner. An emergency stop that exists in a runbook but cannot be activated by the person on call is not an operational control.

Measure exceptions as well as blocks. If the workflow repeatedly asks for access outside its allowlist, the issue may be poor task design rather than malicious behaviour. Record the attempted destination, the reason, the originating content and whether a human approved an exception. After several runs, that evidence tells you whether to add a destination, redesign the workflow or keep the task human-led. It also prevents allowlists from expanding through convenience until they become unrestricted in practice.

The leading counterargument is that strict egress control will reduce usefulness. Sometimes it will. A Level 4 agent cannot conduct open-web research, and a narrow Level 2 allowlist may miss an unfamiliar source. But the answer is not universal access. Split the workflow. Let an uncredentialled research agent gather public material in a disposable environment, sanitise and review its output, then pass only the approved artefact to a separate agent that can reach internal systems. Capability is preserved while trust boundaries remain visible. The architecture may contain more components, but each component has a smaller and testable role.

Make the scorecard a release gate with an expiry date

The final step is organisational. Put the network sandbox scorecard into the same change process used for production software. The release record should name the business owner, technical owner and security reviewer; state the NCSC network level; list destinations and API operations; link to test evidence; record unresolved exceptions; define the shutdown method; and set the next review date. A failed mandatory test blocks release. An accepted risk needs a named approver and a time limit, not a note saying the team will revisit it later.

Use different minimum levels for different consequences. A low-risk public research tool might be permitted at Level 2 with no credentials and synthetic test data. An internal assistant reading commercially sensitive documents might require Level 3, isolated compute and a brokered identity. A high-consequence workflow may justify Level 4 or a deterministic service instead of an agent. The aim is not to force every system to the maximum. It is to stop teams accepting maximum exposure without noticing.

Review the gate when any dependency changes. That includes the model, system prompt, agent framework, browser tool, connector version, proxy, allowed domain, identity scope and data classification. Supplier release notes should feed this process, but supplier assurances are inputs rather than proof. Your own environment determines whether a connection is possible and whether an event is visible. This is why a lightweight automated test suite is often more valuable than a long policy document that nobody reruns.

Start this week with one production candidate. Draw its real data and network path, assign one of the four NCSC levels, create one approved request and four forbidden requests, then capture the logs. If the team cannot demonstrate the block, attribution and shutdown, keep the agent out of production until it can. That may feel cautious, but it is faster than investigating an incident without reliable evidence. The businesses that scale agents safely will not be those with the boldest prompts. They will be those that make autonomy observable, bounded and reversible.

Frequently Asked Questions

What are the four NCSC network sandbox levels for AI agents?

Level 1 allows unrestricted network access. Level 2 restricts access to approved domains. Level 3 permits only the model API. Level 4 has no external network access and uses a locally hosted model.

Is a container enough to sandbox an AI agent?

No. A container can provide compute isolation, but network routes, credentials, data access and authenticated browser sessions need separate controls and tests.

How should we test an AI agent's internet access?

Run approved requests and deliberately forbidden requests through every available route. Confirm that forbidden connections fail at the network control, create attributable logs and expose no credentials or protected data.

Should an AI agent have its own account?

Yes. A unique non-human identity makes activity attributable and allows permissions, lifetime and revocation to be managed independently of employee accounts.

Does domain allowlisting stop prompt injection?

No. It reduces reachable destinations, but an approved domain can still contain hostile instructions or support risky actions. Combine allowlisting with scoped APIs, data controls, human approvals and monitoring.

How often should the network sandbox test be repeated?

Repeat it before initial release and after any material change to the model, prompt, agent framework, browser, connector, proxy, destination list, credentials or data classification.

Can a research agent still use the open web safely?

It can use a disposable, uncredentialled environment with no sensitive data. Review and sanitise its output before passing it to a separate agent that can access internal systems.

Who should approve an agent's network access?

The business owner should accept the operational risk, while technical and security owners verify the architecture and test evidence. High-risk personal data use may also require privacy or legal review.