AI Agent Sandboxes Need Egress Evidence Before SaaS Access

Tools & Technical Tutorials

15 September 2026 | By Ashley Marshall

The question is no longer whether your AI agent has a sandbox. The question is whether you can prove where it tried to go.

The real control is where the agent is allowed to reach

Most AI agent risk discussions still start with the prompt. That is useful, but it is not where the hard boundary lives. The hard boundary is the execution environment around the agent: which networks it can reach, which SaaS tenants it can touch, which credentials it can use, and which files it can read or write. The NCSC's August 2026 guidance on agentic AI is unusually practical on this point. It says organisations should run AI agents within a sandboxed environment that controls what resources can and cannot be communicated with, both locally and over a network. For UK business leaders, that makes egress evidence a release gate, not an infrastructure detail.

The practical shift is simple. Before an assistant is allowed near live systems such as Microsoft 365, Google Workspace, Xero, HubSpot, Shopify, ServiceNow or a production database, the team should be able to show a tested list of approved destinations and a tested list of denied destinations. A generic statement that the agent is sandboxed is not enough. The evidence should show what happened when the agent attempted to browse the public internet, call an unapproved API, reach a personal email account, query an internal admin route, or exfiltrate a file through a permitted channel.

This is not about slowing useful automation. It is about giving the business a reliable way to say yes. A sandbox without egress logs is like a door policy without a record of who entered. It may still help, but it cannot support confident approval, incident response or supplier scrutiny. If the agent is going to act on behalf of the company, network reach needs the same discipline as human user permissions.

The UK evidence bar is moving from policy to proof

The direction of travel in UK guidance is clear: AI systems are being treated as operational systems with lifecycle controls, not experimental widgets. The UK government's AI Cyber Security Code of Practice, published in January 2025, sets baseline requirements across secure design, secure development, secure deployment, secure maintenance and secure end of life. It also highlights risks that are specific to AI, including data poisoning, model obfuscation and indirect prompt injection. That matters because agent egress is where several of those risks turn into business impact.

The same document says the government intervention was endorsed by 80% of respondents to DSIT's Call for Views, with support for each principle ranging from 83% to 90%. That is a useful signal for procurement teams. This is not just a security team preference. There is broad support for baseline AI security expectations, and those expectations are likely to show up in supplier questionnaires, internal audit reviews and board risk conversations.

What this means in practice is that a release pack for an AI agent should include more than a DPIA, a model card or a vendor assurance note. It should include a short egress test summary: approved destinations, blocked destinations, credential scope, logging coverage, alert thresholds and emergency shutdown behaviour. The document does not need to be huge. It needs to be specific enough that a risk owner can understand what the agent can do on a bad day, not only what it is meant to do on a good one.

Prompt injection becomes worse when egress is too generous

Indirect prompt injection is often described as a model problem, but it becomes a systems problem when the agent can reach valuable tools. An assistant that reads a web page and summarises it is one risk. An assistant that reads a web page, follows hidden instructions, opens a CRM, exports customer records and sends a message is a different risk entirely. The model may be the visible part of the workflow, but the blast radius is determined by tool access, network access and credential design.

The NCSC's Guidelines for secure AI system development frame security across design, development, deployment and operation. They recommend that providers build AI systems that function as intended, are available when needed, and work without revealing sensitive data to unauthorised parties. That last phrase is the egress problem in plain English. If an agent can communicate with destinations the business has not approved, sensitive data can leave through channels the monitoring stack does not understand.

A sensible egress test is deliberately boring. Give the agent benign goals that create temptation: collect supplier pricing, reconcile account notes, prepare customer follow-ups, review support tickets, or compare contract clauses. Seed the environment with instructions in documents, emails and web pages that try to redirect the agent to unapproved destinations. Then check whether the network layer, tool gateway and audit trail did their jobs. The counterargument is that this feels artificial. Good. Artificial tests are how you find a predictable failure before a customer, regulator or attacker finds a real one.

Shadow AI shows why blocked paths need user friendly alternatives

There is a human side to egress control. If the approved agent cannot do useful work, staff will route around it. The NCSC's September 2026 blog on the hidden risks of shadow AI cites research finding that 71% of employees reported using AI tools not approved by their employer. That figure should make leaders pause before treating control as a simple ban. People adopt unapproved AI when official routes are too slow, too limited or too vague.

This is why egress evidence should be paired with service design. If a sales operations agent is blocked from sending customer data to an unapproved tool, it should still have a safe route to complete the job: approved CRM access, a redacted export pattern, a review queue, or a human handover. If a finance assistant cannot reach personal email or consumer file-sharing services, it still needs approved access to the accounting system, document store and ticketing queue. Controls that only say no create pressure. Controls that say no here, but yes there, make secure behaviour easier.

What this means in practice is that every blocked egress event should be reviewed as both a security signal and a workflow signal. Was the agent trying to do something malicious, confused or genuinely useful through the wrong channel? That distinction matters. The goal is not to celebrate blocks. The goal is to refine the approved routes until staff and agents can complete legitimate work without improvising around governance.

Make egress evidence small enough to run every release

The best control is the one the team actually repeats. Egress evidence should not become a quarterly PDF exercise that drifts away from the real system. It should be a small test pack that runs whenever an agent gains a new tool, receives a new credential, changes model provider, changes retrieval sources, or moves from pilot to production. In most businesses, the first version can be a spreadsheet or YAML file listing allowed hosts, blocked hosts, allowed tools, blocked tools, expected log fields and expected alerts.

The UK compute context reinforces the point. The UK Compute Roadmap commits up to GBP2 billion between now and 2030 to build a modern public compute ecosystem, including a 20x expansion of the AI Research Resource by 2030. As more AI capability becomes available, the scarce management skill will not be access to models. It will be the ability to place workloads responsibly, prove controls and change systems without losing sight of data movement.

The misconception to address is that egress control is only for highly regulated firms. It is especially important there, but the pattern applies to any business connecting agents to live work. A 20-person company can still leak client files, send the wrong quote, trigger an unwanted refund or expose a supplier contract. Start with three tests: the agent cannot reach personal email, cannot post to an unapproved external API, and cannot read data beyond the role it has been assigned. Then add tests as the workflow becomes more valuable.

Frequently Asked Questions

What is egress evidence for an AI agent?

It is recorded proof of where the agent is allowed to communicate, where it is blocked, which credentials it can use, what logs are created and what happens when it tries to step outside those limits.

Is a sandbox enough on its own?

No. A sandbox is the control environment, but the business still needs evidence that the boundary works, logs are usable and denied actions are visible to the right people.

Which SaaS systems need this first?

Start with systems holding customer data, financial data, staff data, contracts or live communication channels. Common examples include Microsoft 365, Google Workspace, CRM systems, accounting platforms and ticketing tools.

How often should egress tests run?

Run them before first production access and whenever the agent gains a tool, receives a new credential, changes model provider, changes retrieval data or moves into a higher risk workflow.

Does this only apply to regulated businesses?

No. Regulated firms have the clearest audit pressure, but any organisation can suffer harm if an agent sends data to the wrong place or takes action through the wrong system.

Who should own agent egress controls?

Ownership should sit with the service owner or risk owner for the workflow, supported by security and IT. It should not be left only to the person who wrote the prompt.

What is the quickest first test?

Check that the agent cannot reach personal email, cannot call an unapproved external API and cannot read data outside its assigned role. Those three tests expose many weak deployments quickly.