Sanctuary v1.3.0 GA: the Castle Architecture ships

Sanctuary v1.3.0 ships the Castle Architecture as the canonical enforcement model for operator-owned agents. The model is now four layers with distinct contracts: the Castle Wall enforces at the operating-system boundary, Sentinels observe inside the boundary, Cooperative MCP gives compliant agents a richer sovereignty surface, and cryptographic receipts plus reputation carry accountability across castles.

The headline for GA is simple: real Castle Wall enforcement now exists on both Linux and macOS. Linux Phase 1 shipped on May 7, 2026. macOS Phase 1 shipped on May 13, 2026 with a Developer-ID signed NetworkExtension content-filter-provider artifact. Six of nine v1.3 work packages are structurally complete, both v1.x principle-closing work packages are complete, and the Recognition Layer has reached the production-credibility threshold.

Current correction, 2026-08-07: every “Linux Phase 1 shipped” statement in this release note is retired. v1.3.0 did not ship Linux kernel enforcement, and Linux was never a production enforcement baseline for this release. Read “on both Linux and macOS” as macOS only. Open defect: IC-02, IC-03, IC-04.

Later evidence, 2026-10-04: a later package, not part of v1.3.0, was proven on Ubuntu 24.04 (x86-64): a fresh install of the shipped package enforces a signed operator policy per user account: blocked destinations stay blocked and allowed ones connect, through five reboots, on three fresh servers, with the evidence checked by two independent reviewers.

Layer count, 2026-10-12: this note counts four layers because it predates naming Mantle, the install-time substrate binding that shipped in this same release, as a layer. The Castle Architecture now ships as five named mechanisms: Castle Wall, Sentinels, Charter (the cooperative MCP surface this note calls Cooperative MCP), Heralds (the receipts and reputation this note describes), and Mantle. The root README’s Castle Architecture section is the current description.

The Castle Architecture, in plain English

Sanctuary’s Castle Architecture has four layers. Each layer does one job. The layers compose, but they do not substitute for each other.

Castle Wall. The Castle Wall is operating-system-level egress filtering at the boundary between the operator’s machine and the external world. It is kernel-level enforcement. Even a prompt-injected agent cannot bypass it within the proven macOS scope, because the agent does not get to decide whether unauthorized traffic reaches the network. The operating system rejects unauthorized cross-boundary calls. Linux Phase 1 shipped on May 7, 2026. macOS Phase 1 shipped on May 13, 2026. This layer is real enforcement, not advisory policy. (Correction, 2026-08-07: that description holds on macOS within the proven scope: one host, one OS version, signed extension installed and armed, attended reboot proof only. The Linux sentence is retired: v1.3.0 did not ship Linux kernel enforcement, and Linux was never a production enforcement baseline for this release. Open defect: IC-02, IC-03, IC-04.) (Later evidence, 2026-10-04: a package outside this release was proven on Ubuntu 24.04 x86-64 for the narrowed per-account signed-policy claim in the Assurance Matrix.)

Sentinels. Sentinels observe what happens inside the boundary. They use audit-log statistical detectors to surface anomalies to the operator through the unified inbox. They do not enforce. They are pure observation. The shipped detector set covers per-agent activity, CUSUM, PSI, cross-agent timing, tool-call sequence, and audit-event-class distribution.

Cooperative MCP, Charter. Cooperative MCP is the additive sovereignty surface for agents that honor the operator’s policy. It includes approval gates, English-authored policy gates, honeypot authoring, the auto-trigger ladder, and the unified inbox with operator-facing operations. This is the path for compliant agents to work well inside the castle.

Cryptographic receipts and reputation, Heralds. Heralds is post-action accountability across castles. Concordia receipts and Verascore reputation compose so operators can carry signed evidence, reputation, and cross-castle accountability outside a single vendor relationship.

What’s new since v1.2.x

Castle Wall enforcement. Castle Wall macOS Phase 1 ships a kernel-level NetworkExtension content-filter-provider with a Developer-ID signed binary. With Linux Phase 1 already shipped on May 7, both platforms operators actually use now have real egress enforcement. (Correction, 2026-08-07: the second sentence is retired; v1.3.0 shipped real egress enforcement on macOS only. Later evidence, 2026-10-04: a package outside this release was proven on Ubuntu 24.04 x86-64 for the narrowed per-account signed-policy claim.)

Sentinels observation. The Sentinels work package is structurally complete across Phi-1 through Phi-5. Anomaly detection is at 5/N across Chi-1 through Chi-5 detectors. Coordination handoff visualization is complete across Omega-1 through Omega-3.

Charter cooperative surface. The unified inbox bridge has producer wiring, at-rest encryption, and operator-facing operations across Psi-1 through Psi-3. Concierge depth is complete across Tau-1 through Tau-5. The cross-harness approval inbox is complete across Upsilon-1 through Upsilon-4. English-authored policy gates are complete across Xi-1 through Xi-3. The auto-trigger ladder ships with operator-promoted action classes across Nu-1 through Nu-3 plus Nu-2 wiring. Honeypot authoring is at 4/N across Pi-1 through Pi-4 trap classes.

v1.x principle-closing work. Query-Layer Anonymity is complete end to end across Rho-1 through Rho-3: header strip, Tier B basic PII rewrite, and Tier B smart mode with reverse-mapping memo. The Recognition Layer has reached the production-credibility threshold through the did:web Path C builds: foundation, exit-bundle integration, fortress-config auto-inclusion, and key rotation.

Why this matters

Sanctuary’s substrate position is operator-level sovereignty that is enforceable, not advisory.

The Castle Wall is the core enforcement piece. If an agent gets prompt-injected and tries to exfiltrate operator data, the operator does not have to trust that agent to remember the rules. The kernel rejects unauthorized cross-boundary calls before they escape the machine within the proven macOS scope.

Cooperative MCP matters for a different reason. It is the sovereignty surface for agents that do honor policy: approvals, policy gates, honeypots, unified inbox routing, receipts, and operator control in the normal flow of work. That layer should be easy to use. It should feel like the right path.

v1.3 ships both: hard enforcement at the boundary plus a usable cooperative surface inside it.

How to install

Stable v1.3.0 GA:

npm install -g @sanctuary-framework/mcp-server

Preview reference, from the v1.3.0-rc.1 soak on the next channel:

npm install @sanctuary-framework/mcp-server@next

Castle Wall macOS Phase 1 requires the signed .app artifact and Apple’s Network Extensions entitlement. Deployment instructions live in server/docs/castle-wall-macos-deploy.md.

Castle Wall Linux Phase 1 deployment is documented in the public Linux Phase 1 release reference at docs/_posts/2026-05-08-castle-wall-phase-1-linux.md.

Acceptance drill summary

v1.3 GA is tested against the 60-minute operator drill:

  1. Wrap three harnesses.
  2. Run a coordinated workflow.
  3. Trigger drift.
  4. Author an English gate.
  5. Author a honeypot.
  6. Configure the auto-trigger ladder.
  7. Run concierge through query categories.
  8. Run three approvals through the cross-harness inbox.

Drill results: GHA Linux drill run 26056732996

What’s still in progress, and what that means for users

WP-V1.3-2 Anomaly Detection is closed at 5/N through the features doc. Chi-6 and later detectors are additive future work, not GA requirements.

WP-V1.3-5 Honeypot Authoring is closed at Pi-1, with Pi-2, Pi-3, and Pi-4 shipping the trap-class library. Additional trap classes are future additive work.

Castle Wall macOS Phase 2, including system-extension install scope, and the live kernel-block end-to-end demo are deferred to Alpha-4. The v1.3 GA artifact is the foundation, filter, manifest sync, and signing pipeline.

Cooperative MCP action classes, including block_egress, auto_deny_tool, and throttle_agent, are audit-only stubs in v1.3 GA. Paired enforcement wires land in v1.3.x as Castle Wall expands. The dashboard footer signals this clearly to operators.

Coverage gate

The 2-week wall-clock soak gate was retired before v1.3.0 GA in favor of synthetic fixture coverage. Without real-user traffic, calendar progression produces no signal; parameter-space adversarial fixtures across the assurance matrix produce denser signal on every PR. The synthetic-coverage harness at scripts/synthetic-coverage/ covers 17 of 20 ASSURANCE_MATRIX rows and is the gate (a) artifact for v1.3.0 GA (gate_a_green on main commit cf70877 from run 26294012155).

Acknowledgments

Sanctuary v1.3 composes with partners across the agent stack: Coinbase x402, Anthropic, Google AP2, and Hermes A2A.

Thanks also to the co-coordination partners helping pressure-test the substrate: A2CN with Christian Magorrian, BidAngel with Brian P., the AIVS working group, and the DIF KYA-OS task force.

What’s next: v1.4+

The post-v1.3 roadmap focuses on the Crypto Agility Sprint, including real MLS RFC 9420 support and bundled ML-DSA/ML-KEM-768 hybrid post-quantum primitives; Castle Wall macOS Phase 2 and Phase 3 Windows; and additional Chi-N detectors plus Pi-N trap classes as operator demand surfaces.