The Sovereign Airlock is the principle most teams skip, and framing it as a named architectural component rather than a middleware afterthought is what makes this series worth reading end to end. Controlling what leaves the network is the whole ballgame once you accept that egress is where sovereignty is actually won or lost.
The open question I'd put to the reference implementation — and it's the one we ran into building enforcement for production — is what happens when the Redactor and the Guardian share a process boundary with the agents they govern. A gate is only deterministic if the thing being gated can't reach it. If a compromised or misbehaving agent runs in the same trust domain as the airlock, the airlock becomes advisory: it still works exactly as designed right up until the moment it matters. That's the failure mode that turns a governed system back into a probabilistic one.
That's the layer AIRGP formalizes — not context or tool discovery, which MCP already handles well, but the enforcement invariants underneath: out-of-band policy evaluation, and cryptographic provenance on the governance subject so that after the fact you can prove which policy applied to which interaction. Logs describe what happened; signatures prove it. The distinction is invisible in a demo and decisive in an audit.
Spec is open: https://doi.org/10.5281/zenodo.19655870 — A2ASTC covers the agent-to-agent side of the same problem. They slot underneath what you've built here rather than competing with it: your five principles describe what a sovereign system should do, and the enforcement invariants describe what has to hold for those guarantees to survive contact with an adversary.
Going through the repo this week. If the constraints are useful to the Sovereign Systems Specification, happy to contribute — there's a version of this where the context spec and the enforcement spec reference each other and developers get a complete picture instead of two halves.