AI sandbox: a safe environment for agent and generated-code execution

What is an AI sandbox?

A sandbox is a constrained environment separate from the main system, with defined access, time and resource limits for an agent or code run.

Its purpose is to contain impact and make execution reviewable.

Core sandbox controls

Isolation alone is not enough. Network, files, secrets, CPU, memory, execution time and output each need their own policy.

• Minimal network access
• No secrets or short-lived secrets
• Time and resource limits
• Ephemeral file system
• Traces and output logging

Sandboxing and prompt injection

Prompt injection can steer an agent toward unwanted work. A sandbox reduces potential impact, but input handling and tool restrictions still matter.

What is prompt injection? (Read more)

For more on this topic, read When a document gives instructions to an AI assistant in the Liyan knowledge base.

Production requirements

Test, staging and production environments should be separate. Real access should follow evaluation, review and a defined rollback path.

What is AI governance? (Read more)

What a good sandbox isolates

A sandbox needs independent network, file, identity and time boundaries. If a task requires one read-only API, broad internet access or host-file access conflicts with the purpose of isolation.

Output is part of the boundary too. Logs and temporary files should be reviewable and short-lived so test execution does not become an unintended store of sensitive information.

A safe path from test to production

Start with a test scenario, minimum privileges and stop criteria. Only after stable behavior and trace review should the same pattern move to the next environment under a clear policy.

Rollback must be practical: know which connector, secret or tool can be disabled immediately and who has authority. A sandbox reduces blast radius; it does not remove accountability.

Scenario: analyzing a file in a temporary environment

For uploaded-file analysis, an agent receives the file in temporary storage and can reach only the libraries and outputs needed for that task. Host files and production secrets stay unavailable.

If the file triggers an unapproved network request or exceeds the execution limit, the environment stops and records the event. The result can be reviewed without crossing into the primary system.

After completion, temporary files and short-lived tokens are removed while the necessary trace remains for review. This separation needs periodic testing, not only initial configuration.