Sandbox Isolation

This page describes the intended isolation boundaries of the ABS Core enforcement path.

ABS Core should be understood primarily as execution isolation for policy evaluation, not as a full host security boundary equivalent to a hardened VM or operating system kernel.

What the isolation path is for

The isolated path exists to evaluate governance policy in a constrained execution environment before a governed action is released.

Its goals are:

• deterministic policy execution;
• bounded resource usage;
• reduced attack surface for policy logic;
• and predictable failure handling.

What it is not

ABS Core should not be described as providing full host isolation by itself.

It does not, by description alone on this page, prove:

• protection against arbitrary host compromise;
• control over direct network paths that bypass the gateway;
• universal filesystem mediation outside the governed path;
• or operating-system-level containment for all workloads.

Practical security boundary

The strongest current interpretation is:

• inside the isolated policy path: constrained evaluation of policy logic;
• outside the isolated policy path: host, container, network, and external runtime controls remain the responsibility of the deployment environment.

What should be demonstrated publicly

A credible public proof of isolation should include:

1. resource exhaustion tests;
2. invalid memory access behavior;
3. timeout / instruction budget behavior;
4. denied capability tests for filesystem and networking;
5. failure behavior when policy execution traps.

Recommended evidence table

Deployment note

For stronger host-level guarantees, ABS Core should be deployed together with container, VM, seccomp, cgroup, or equivalent environment controls.

That means the sandbox should be sold as a governance isolation component, not as complete infrastructure isolation on its own.