WHITEPAPER OVERVIEW
Containment by Design
The security thinking behind the platform, in overview: the six-step argument, the five commitments, and the ten principles for securing AI systems that reason, adapt, and act autonomously — and the deterministic architecture that follows from them.
Bring one AI workflow, one consequential action, or one data boundary.
CONTAINMENT.AIDOC C-WP-001
CONTAINMENT
BY DESIGN
BY DESIGN
Ten principles for securing autonomous AI systems
— The action, not just the answer
— Deterministic policy holds the gavel at the moment of execution
— Fail closed at the boundary
— Evidence as a byproduct
… and six more, below
OVERVIEW EDITION — ALL TEN PRINCIPLES STATED ON THIS PAGE
FIG. 1 — THE ARGUMENT IN SIX STEPS
From answers to actions. From actions to consequences. From consequences to a ruling.
1
AI has moved from generating answers to initiating actions.
2
The risk has moved from bad output to irreversible consequence.
3
Inventory, identity, observability, and model guardrails remain necessary — but none of them is an independent authorization point for every consequential action.
4
The required control is an enforcement layer: deterministic, in-path, and external to the proposing AI model. Deterministic policy makes the enforcement decision, with evidence produced at decision time.
5
Containment.ai applies that discipline at three boundaries: the human prompt, the agent action, and the mission boundary.
6
You begin with one boundary, prove the control with your own policy, and keep the evidence.
FIG. 2 — FIVE COMMITMENTS
Five commitments the architecture is built to keep.
Stop the consequence, not merely the signal.
Decide before data leaves or an action executes — not after.
Policy — not another model — holds the authority.
Models can inform context; versioned policy makes the ruling.
Evidence is created at the moment of enforcement.
Product-specific decision records let you inspect what was attempted, the recorded ruling, and the response issued by the enforcement point.
One discipline, deployed at the right boundary.
Browser, agent, and mission-edge products are selected by the risk surface and assurance bar.
Trust is the canonical record.
One page states exactly what is attested and deployed — read Trust alongside this overview.
FIG. 3 — THE TEN PRINCIPLES
The argument in ten lines. The platform earns each one.
01
Govern the action, not just the answer. A wrong action costs more than a wrong sentence.
02
No AI model makes the enforcement decision. AI models may inform upstream context; deterministic policy holds the gavel.
03
Fail closed at the boundary. The safe state is the default state, not the fallback.
04
Same input, same ruling. Determinism is what makes a control testable at all.
05
Canonicalize before you evaluate. One stable form defeats a thousand formatting tricks.
06
Policy is versioned code. Pinned at decision time — required for later review and policy re-evaluation.
07
Break the protocol, re-originate the content. Forwarding an attack should be architecturally impossible.
08
The link is never in the loop. Governance that needs the cloud fails exactly when it matters.
09
Evidence as a byproduct. Product-specific decision records fall out of enforcement — not out of a separate tool.
10
Run under your own controls. Publish the failures. A governance vendor that hides incidents isn't one.
THE ARCHITECTURE THAT FOLLOWS FROM THESE PRINCIPLES IS ON THE PLATFORM AND PRODUCT PAGES.
HOW THE OVERVIEW READS
WHO SHOULD READ IT
Security architects
The enforcement model — interception points, canonicalization, the policy engine, and the audit plane — argued here, detailed on the platform pages.
Diligence teams
Read alongside Trust and Compliance — this overview argues the design; those pages state what's attested.
Program leaders
Why probabilistic guardrails don't survive contact with a contracting officer — and what deterministic containment offers instead.
STEP SIX, IN PRACTICE
Begin with one boundary. Prove the control with your own policy. Keep the evidence.
Bring one AI workflow, one consequential action, or one data boundary.