131 doors.
17 planes. Every one named.
A door is a named, numbered, verified place where an agent’s environment can be turned. It is admitted to this registry only when it has a verifier that fails closed on missing evidence, a measured denominator, a path from a real action, a registry row and a mutation test — and then it is counted. The number on every page of this site is derived from this registry by a script; it is never typed. We publish the map because the map is the design and the customer’s keys are the key. Anyone can read the names. Nobody can copy the admission. The agent behind every door is a superintelligent AI agent — an agent whose action we would not accept on its word.
Plane 1 · LAUNCH & CONFIG · doors 1–7, 115, 121
Tool / MCP manifest (mcp.json)
Startup / lifecycle hooks
System prompt / instruction file
Agent config (model/allowlist/perms)
THE SIGNED CONFIG — the agent refuses its own unsigned configuration, and the refusal is on the record.
Environment vars / secret injection
Sampling params (temp/top-p/logit-bias)
Feature / runtime flags
Harness plumbing
Launch surface beyond git
Plane 2 · TOOLS & CAPABILITIES · doors 8–11, 83, 130
Tool definitions & schemas
Tool registry / dynamic discovery
Tool responses (poisoned returns)
Structured-output / function-call schema
Rendered-surface provenance
Browser hygiene
Plane 3 · CONTEXT & DATA · doors 12–17, 84, 97, 129
Prompt inputs (user / other agent)
RAG / retrieved documents
Memory (short & long term)
Files the agent reads
Embeddings / vector store
Conversation history / context window
Hidden-character injection
Tenancy isolation
Cache provenance
Plane 4 · MODEL & REASONING · doors 18–21, 98, 105
Model weights / registry
Fine-tune / adapter / LoRA
Chain-of-thought / reasoning trace
Eval / probe behaviour (sandbagging)
Eval-to-prod binding
Evaluator independence
Plane 5 · OUTPUT & ACTION · doors 22–26, 99, 101, 110, 122
Action path / sinks (external calls)
Information flow / data egress
Key usage / signing
Rendered screen the human signs
Autonomous fund movement
Covert-channel egress
Observation-to-action atomicity
Route-class check
Control-plane write guard
Plane 6 · MULTI-AGENT · doors 27–31, 79, 104, 117–118
Agent-to-agent messages
Delegation chains (multi-hop authority)
Coalition / collusion
Orchestrator / planner integrity
Shared scratchpad / blackboard
Delegation depth and authority decay
Inter-agent contention
Delegation chain
Second principal
Plane 7 · IDENTITY & AUTHORITY · doors 32–34, 81, 100, 102–103, 119, 127
Agent identity / credentials
Capability grant / mandate / containment
Dormant triggers / backdoors
Agent origin attestation
Legal-person binding
Consent grant control
Delegated-authority persistence
Agent signer grade
Token refresh re-attestation
Plane 8 · RUNTIME · INFRA · SUPPLY · TIME · doors 35–42, 85, 89, 92, 108, 113–114
Scheduler / cron / trigger
Sandbox / container
Network egress / proxy
Telemetry / log pipeline
Behavioural drift over time
Dependencies / packages (npm · pip)
Agent-framework CVEs
Session handoff / context summarisation
Inbound trigger authentication and attribution
Time-source integrity
Telemetry hygiene
Kill-switch efficacy
Capability divergence
Privilege layering
Plane 9 · TRANSPORT — the wire between components · doors 43–48, 125
Agent → model request channel
Model → agent response channel
Agent → tool/executor call channel
Tool → agent response in-transit rewrite
Streaming / token-stream integrity
Router / gateway trust boundary
Destination continuity
Plane 10 · BREAKOUT — the Containment Witness · doors 49–52
Declared isolation against independently observed reach. The wiki incident of 2026, door by door.
Declared isolation vs independent egress observation
Persona forgery
Coalition re-formation after quarantine
Eval integrity
Plane 11 · CHAINGRAPH — composition, tempo, scope · doors 53–68, 107
Closed at one hop, open at two. The composition, not the component - and now the monitor's own robustness.
Chain composition
Chain-context ranking
Choke-point selection
Machine-speed plan
Tempo
Medium
Autonomic arbitration
Emergent capability
Deception density
Defensive-loop completeness
Transitive egress
Rebuild efficacy
Economic irrationality
Simulation framing
Observer invisibility
Scope verification
Monitor robustness
Plane 12 · MACHINERY — the runner proves itself · doors 69–74, 76, 82, 93–94
Black Hat 2026 broke the frameworks every other control is enforced by. This plane makes the surrounding machine prove it is the machine that was enrolled - and holds our own signing key to level-5 custody.
Orchestrator attestation
Inference-runtime attestation
Harness SDK self-attestation
Template-engine injection
Unsafe deserialisation
Runtime module attestation
Tokenizer + chat-template integrity
Self-extension
Signing-key custody
Entropy source integrity
Plane 13 · SILICON — where the model actually ran · door 75
Attesting software on hardware nobody attested is half an attestation. An absent quote is UNVERIFIED, never a pass.
Enclave quote
Plane 14 · HUMAN OVERSIGHT — measured, not assumed · doors 86–88, 106
Article 14(4)(b): the human must not over-rely. A rubber stamp is a FAIL, the approver's phone is a door, and an agent that coaches a human past a control is caught.
Oversight efficacy
Approver device binding
Mandate widening by the agent
Human-proxy coaching
Plane 15 · ECONOMY — settlement, wallet, contract, meter · doors 77–78, 80, 95, 109, 111–112, 116
The independent economic agent pays, spawns, contracts and reports its own usage. Every one of those is a ceiling, and a pending settlement is never DONE.
Agent-to-agent settlement
Denial-of-wallet
Autonomous contracting
Meter reconciliation
Settlement finality
Spend-union
Mandate-bound signing
Rate ceiling
Plane 16 · LIFECYCLE & LAW — erasure, retirement, the legal person · doors 90–91, 96, 126
The record must survive; the personal data inside it must be erasable. An agent switched off must actually be gone. And no action without a liable person behind it.
Lawful erasure vs immutable proof
Decommission attestation
Underwriter-verifiable export
Baseline re-enrolment
Plane 17 · THE UPDATE CHANNEL — every part that changes version · doors 120, 123–124, 128, 131
The attack of the year is a trusted name at a new version: the package, the extension, the tag, the pipeline. On this plane a version earns its way in - it waits, keeps its publisher, proves where it was built, and is named by digest, never by a label someone can move.
Version admission
Extension and plugin update gate
Immutable reference
CI context integrity
The signed config
How a door is admitted
Named, numbered, evidenced
What breaks, where, with the incident or the paper that showed it.
A pure verifier that fails closed
No evidence = FAIL. Unknown verdict = FAIL. A door that can only pass is not a door.
A denominator on every answer
MEASURED n/m, or UNVERIFIED. Never green by silence.
Reachable from a real action
A resource kind routes an action to the door. A door nothing can reach is a door in name only.
A row, signed into the negative space
The bill of materials names what it covers and what it does not.
Replayed with a good and a bad example
Every door has one declaration that passes and one that must fail — and a mutation test that proves it.
The house rule above all of it: when a higher level exists, we take it. Signatures at FIPS 204 level 5, held in hardware custody. Symmetric keys at 256 bits. TLS 1.3 with post-quantum hybrid on every edge.
Every door is sold inside a tier, never as a line item
INTEGRITAS holds planes 1–13, WARRANT and AIM hold the human, the economy and the legal person. The count is the proof of the tier.
INTEGRITAS WARRANT AIM Our score on the five requirements