Current example
Permitted by the declared policy
No declared policy violations. This is not real authorization or security certification. Filesystem, secret broker and network enforcement are model inputs; isolation never grants action authority.
Initial scenario: a restricted container, scratch-only writes, no network or secrets, no external-action approval, and a local computation. This is a declared teaching policy, not inspection of a real sandbox.
Execution boundary
- Runtime privileges
- Restricted
Reach & capabilities
- Writable filesystem scope
- Ephemeral scratch only
- Network policy
- Network disabled
- Secret access
- No secret capability
- Violation bitmask
- 0
Action authority
- Requested action
- Compute locally
- External-action approval
- No exact approval
- Policy decision
- Permit under the stated policy
02 / Follow the flow
Four boundaries. One connected explanation.
Each card explains a node in the diagram. Highlights show which boundaries contribute to the current result.
Treat generated intent as an untrusted proposal
The model can propose arguments, interpret retrieved content and choose among exposed tools. None of those outputs proves identity, permission or human approval. A malicious document may influence the proposal without exploiting the operating system. Keep trusted policy outside model-authored text, attach source provenance, and make the intended action explicit enough that an independent component can validate it.
Policy
Decide authority outside the execution context
Validate the actor, target, operation and current approval record before releasing a capability. This reader rejects overbroad posture as well as missing action-specific permissions. Production approval must bind the exact rendered external action and expire or be consumed according to policy. An approval for one recipient, repository or amount cannot authorize a changed proposal, and a checkbox inside an untrusted process is not evidence of approval.
Contain the process, not just its instructions
A restricted container still shares the host kernel. A microVM introduces a guest-kernel boundary but depends on a correctly maintained host and hypervisor. Both need explicit mount, privilege, syscall, network, resource and lifetime controls. Neither protects secrets deliberately passed to the process. Test the actual runtime boundary, including host sockets, inherited file descriptors, writable mounts, side channels and cleanup, rather than inferring isolation from a runtime label.
Tools
Keep side effects narrow and recoverable
A tool should authorize its target independently, apply limits and return bounded results. Network mediation needs destination validation, redirect handling and protection against internal-address access; a domain-looking string is not enough. Use idempotency for retryable side effects and reconcile uncertain outcomes. A sandboxed process with a valid broad external credential can still perform an unauthorized business action, so containment never replaces tool authorization.
# Evaluated policy inputs, not a runnable security boundary
runtime = 1
privileged = 0
filesystem = 0
network = 0
secrets = 0
approval = 0
action = 0
violation_mask = 0
# Enforce the real boundary outside the agent before executing any action.03 / Keep the model honest
Model assumptions
Deny direct host execution or host-privileged execution.
Deny host-wide writes, unrestricted egress or broad raw secrets.
HTTPS reads and external messages require the declared allowlist.
Workspace edits require the designated workspace capability.
External messages additionally require an exact approval record.
No violation bits → permit under this teaching policy only.- The WebAssembly function evaluates declared switches. It does not launch an agent, inspect a kernel, validate a network policy or issue a real capability.
- The container or microVM has the additional hardened configuration discussed in the article: bounded resources, reviewed mounts, syscall restrictions and a maintained runtime.
- The allowlist, sanitized workspace and brokered capability are preconditions, not facts that this page verifies.
- Approval binds the exact action, actor, target, scope and validity period. Actual approval and credential handling stay outside the model and sandbox.
- An allowed result is not a security score, proof of isolation or permission to perform a real action. No external action or credential request is made by this reader.
04 / Think it through
Questions behind the example.
Why does an external message need exact approval even when its destination is allowlisted?
Why does host-wide filesystem access violate this teaching policy before any side effect is requested?
Why does changing a container boundary to a microVM not grant network capabilities or action authority?
Primary documentation