Working noteAwaiting revisionVersion 0.1
Adversarial Containment Foundations
A short working note for the Rabat session: the boundary assumptions, minimum controls, and questions that need practical examination.
Published 24 July 2026Updated 29 August 2026
Purpose and status
This note framed PESAEAS Morocco #1 in Rabat. It remains a starting point for technical review, not a specification, security guarantee, or statement of consensus.
Containment means limiting what an autonomous system can observe, change, invoke, and transmit when cooperative behaviour cannot be assumed. The concern is the complete operating boundary—not the model in isolation.
Starting propositions
The session used five propositions as a basis for practical examination.
- The boundary includes tools, credentials, runtime, network, data, operators, monitoring, and shutdown paths.
- Authority should be denied by default and granted only for a defined task, duration, and destination.
- Relevant tool, data, network, filesystem, and execution transitions require mediation.
- Time, compute, storage, process creation, retries, and external calls require explicit budgets.
- Policy evidence and emergency control must remain outside the autonomous workload’s authority.
Questions for Rabat
The session was framed around the following unresolved questions.
- What is the smallest useful containment profile an engineer can implement and inspect?
- Where should policy execute so the contained system cannot reinterpret or modify it?
- Which failures must fail closed, and where is a controlled degraded mode safer?
- What evidence distinguishes a blocked attempt from an undetected one?