Agent sandboxing and isolation

What it does

It limits the reach of anything that goes wrong inside the agent's execution environment. Generated code, a hostile skill or a compromised tool can affect only what the environment exposes. Security architecture owns the isolation standard and the platform team applies it to every environment in which an agent executes code or loads third-party components, from the first test run onwards.

How to implement it

• Run agent-generated code in a container or virtual machine created for the task and destroyed after it.
• Deny network access by default and allow named destinations only.
• Mount only the files the task needs, read-only where possible.
• Keep credentials outside the environment and broker access through an authenticated interface.
• Separate skills and tools from each other as well as from the host.
• Set limits on time, memory and processes.

Evidence it operates

Design: an architecture record showing the isolation boundary and what crosses it. Operation: configuration of running environments matches the standard; tests that attempt to reach the internal network, read host files and persist beyond the task all fail; alerts are raised for blocked attempts.

Where it fits

Built at design and enforced at deployment. It complements least-privilege agent identity: identity limits what the agent may ask for, isolation limits what its environment can touch.

Limits

Isolation does not protect what is deliberately placed inside the boundary: data mounted into the environment can still be misused or sent to an allowed destination. Escapes from container isolation are possible, and higher-risk workloads may need stronger separation.