# Deterministic containment

The enforcement envelope outside the model: isolation, deny-by-default access, typed allowlists, quotas, transaction ceilings, network boundaries, timeouts, rollback, quarantine, and tested stop controls.

core-concept · Security & governance · maturing · Reviewed 2026-08-09

## Definition

The enforcement envelope outside the model: isolation, deny-by-default access, typed allowlists, quotas, transaction ceilings, network boundaries, timeouts, rollback, quarantine, and tested stop controls. Probabilistic decisions must terminate inside deterministic boundaries.

Isolation and policy primitives are established; agent-specific containment architectures are still converging.

## Why it matters

Probabilistic decisions must terminate inside deterministic boundaries.

The operating shift is from “Ask the model to be careful” to “Make unsafe effects mechanically unreachable.”

## System anatomy

- **Practice 1:** Default-deny tools, data, network, and credentials
- **Practice 2:** Validate every consequential action before effect
- **Practice 3:** Exercise rollback, quarantine, and kill paths independently



## Important distinctions

- **Ask the model to be careful:** This concept moves the engineering system toward make unsafe effects mechanically unreachable.



## Implementation signals

- Default-deny tools, data, network, and credentials
- Validate every consequential action before effect
- Exercise rollback, quarantine, and kill paths independently

## Failure modes

- Natural-language guardrails used as the only boundary
- A kill switch sharing the same compromised control path



## Related knowledge

- [Agent execution substrate](https://aisdlc.ai/agentic-engineering/execution-substrate) — The isolated, stateful environment in which agents observe and act, including compute, filesystem, browser, network, credentials, resource limits, and session lifecycle.
- [Runtime policy enforcement](https://aisdlc.ai/agentic-engineering/runtime-policy-enforcement) — The pre-action decision and enforcement layer that evaluates identity, purpose, risk tier, tool, resource, data class, limits, approval state, and current evidence before allowing an agent action.
- [Agent incident response](https://aisdlc.ai/agentic-engineering/agent-incident-response) — An agent-specific response discipline that detects unsafe behavior, contains execution, revokes authority, preserves evidence, reconciles external effects, involves accountable owners, restores safely, and converts incidents into controls and evaluations.

## Sources and further study

- [Google Cloud — Agent Sandbox on GKE and Agent Substrate](https://cloud.google.com/blog/products/containers-kubernetes/bringing-you-agent-sandbox-on-gke-and-agent-substrate) — An agent-specific execution architecture emphasizing isolation, state, scheduling, and environment control. **Use:** First-party case study. **Limitation:** This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.
- [OWASP GenAI Security Project — State of Agentic AI Security and Governance 2.01](https://genai.owasp.org/resource/state-of-agentic-ai-security-and-governance/) — A current threat and governance synthesis covering instruction-data confusion, containment gaps, autonomous action, and agentic incident readiness. **Use:** Official guidance. **Limitation:** Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.
- [Open Policy Agent — OPA Management APIs and Architecture](https://www.openpolicyagent.org/docs/management-introduction) — An established policy-engine architecture for distributed enforcement, centrally managed policy bundles, decision logs, and enforcement telemetry. **Use:** Standard or protocol. **Limitation:** A specification defines an interface or control pattern; conformance alone does not establish authorization, security, or fitness for a use case.

---

This library synthesizes cited research, standards, official documentation, and clearly attributed practitioner perspectives. Maturity describes the state of a concept—not vendor endorsement, production readiness, or permission to deploy. Benchmarks and demonstrations do not replace use-case evaluation, governed controls, independent verification, or named human release authority.