Sandboxing and authorisation solve different problems
A sandbox limits what compromised execution can reach. Authorisation decides what an authenticated actor may do. Secure agents need both, tested independently and together.
A code agent can be authorised to edit one repository and still escape an overly privileged runtime. It can be strongly sandboxed and still use a valid API credential to delete every repository in an organisation. These are different failures because sandboxing and authorisation answer different questions.
The sandbox asks: if execution is malicious or defective, what can the process reach and affect? Authorisation asks: given an authenticated actor and request, is this action on this resource allowed? Treating either as a substitute leaves an entire class of paths open.
Define the two boundaries precisely
Containment limits process capabilities: filesystem, processes, devices, system calls, compute, time and network. It assumes code inside the boundary may be hostile. Authorisation limits business and system actions: which records, tenants, repositories, tools or transactions a principal may access under which conditions.
Isolation mechanisms can include virtual machines, containers, namespaces, mandatory access controls, syscall filtering and application sandboxes. NIST’s container security guide explains both the portability benefits and security concerns of operating-system virtualization. The specific technology matters less than the proven boundary: shared kernels, privileged containers and writable host mounts create different escape and impact conditions.
Authorisation may be enforced by an API gateway, policy engine and target service. NIST’s zero-trust architecture provides a useful principle: make per-request access decisions around subjects and resources instead of assuming a network location is trusted.
Use a matrix to find the missing control
Review each capability across both axes.
| Agent capability | Containment question | Authorisation question |
|---|---|---|
| Edit source code | Which paths, commands and processes are reachable? | Which repository, branch and file operations are allowed? |
| Query customer data | Can the process read local secrets or raw database sockets? | Which tenant, fields and purposes may this identity query? |
| Browse the web | Which protocols, domains, downloads and response sizes are allowed? | Is this task permitted to disclose any data to that destination? |
| Send email | Can execution reach the mail service except through the adapter? | Which sender, recipients, attachments and approval state are allowed? |
| Call another agent | Which endpoint and message size can be reached? | Which authority may be delegated, and for what task? |
If the answer appears only in a system prompt, neither boundary is dependable. The model is a decision component inside the threat model, not the enforcement point for its own compromise.
Design containment for hostile execution
Begin with a clean, ephemeral workspace. Mount only the inputs required for the task, with read-only access where possible. Run as a non-privileged identity; remove unnecessary Linux capabilities; restrict system calls, child processes and devices; limit CPU, memory, file size and wall time; and deny network by default. Expose necessary operations through narrow adapters rather than mounting host sockets or broad cloud credentials.
Separate tenants and high-impact tasks at an isolation level that matches consequence. A process boundary may be enough for low-sensitivity formatting; untrusted code against confidential repositories may justify a dedicated microVM or stronger isolation. Do not describe a particular technology as “secure” without its configuration and escape testing.
The sandbox should be disposable. Persist only reviewed outputs, scan them before promotion and avoid carrying caches, shell history or memory into the next user’s run.
Containment also needs an administrative boundary. The service that creates sandboxes should not expose its host-control socket to the workload it launches, and an agent-facing API should not accept runtime options such as privileged mode, arbitrary mounts or host networking. Separate the control-plane identity from the in-sandbox identity. If the agent can reconfigure its own cage, isolation is a convention rather than a security control.
Design authorisation for hostile intent
Authenticate both initiator and workload. Translate the user’s request into a structured, narrow mandate: action, resource, scope, time and limits. The target service—not the model—must enforce tenant ownership, field constraints and approval conditions.
Avoid placing general service credentials in the sandbox. A broker can attach a short-lived, audience-bound token only after a tool call passes policy. This preserves authorisation even if generated code reads every local environment variable. Keep high-impact commitment services outside the execution boundary so that escape from the coding environment does not imply transaction authority.
The NCSC secure-design guidance advises restricting actions AI components can trigger and using external fail-safes where necessary. This is the practical split: the sandbox restricts reachable mechanisms; the service policy restricts legitimate-looking actions.
Test each boundary independently
Containment tests should attempt host filesystem access, privilege escalation, forbidden syscalls, process spawning, resource exhaustion, device access, metadata-service access, DNS and network bypass, and persistence between runs. Include malicious dependencies and archive extraction cases. Verify from outside the sandbox which effects occurred.
Authorisation tests should use valid authentication to request the wrong tenant, resource, field, amount, destination and action. Replay expired credentials, change audience, remove approval and delegate beyond scope. Verify the target system state.
Independent tests identify which control actually stopped the path. A network denial must not conceal that an API would have accepted an overbroad token; a 403 must not conceal that the process could read a host secret.
Use canaries to make silent boundary crossing observable: unique files outside the workspace, credentials valid only against a test endpoint, and records in a neighbouring test tenant. An attempt to touch them should create a high-fidelity alert. Canaries do not replace prevention, but they reveal unexpected reach and make escape exercises measurable without placing real data at risk.
Retest both layers after any runtime or policy change; evidence from one configuration does not transfer automatically to the next image, kernel, gateway or tool version.
Test the composition under realistic failure
The most important scenarios cross the controls:
- Place an injected instruction in a repository issue asking the agent to read a secret and post it externally.
- Compromise the tool adapter and attempt to swap a repository identifier after policy approval.
- Revoke authorisation while generated code is still running and queued writes exist.
- Degrade the policy service and observe whether the execution layer retries, bypasses or fails closed.
- escape the intended workspace in a test environment and attempt a downstream API call with whatever identity is available.
Record containment, authorisation and resulting state separately. OWASP’s agentic threat guidance is useful for selecting prompt, tool, memory and multi-agent attacks, but test them against the deployed control composition.
Establish ownership without gaps
Platform teams may own runtime isolation while application teams own resource authorisation. That division is reasonable only if someone owns the path between them: credential injection, tool adapter, network proxy, policy availability, logging and emergency shutdown.
Create one control record for each consequential tool. It should name its sandbox restrictions, resource-level policy, evidence from both test suites, residual paths and owners. Re-run the relevant tests when runtime, base image, kernel, dependency, identity provider, policy or tool schema changes.
The release rule is simple to state and demanding to prove: assume code in the agent environment can be hostile, and assume an authenticated request can be malicious. Containment limits the first; authorisation limits the second. A secure design requires both to remain effective when the other disappoints.