v1.9.0-rc.2 (2026-10-27)

This opt-in release candidate is published on npm’s next channel. The stable latest channel remains v1.8.4 until 1.9.0 ships. rc.2 adds the dashboard work merged since rc.1. No claim below goes beyond the bounded rows of the Assurance Matrix. The full list is in CHANGELOG.md.

npm install -g @sanctuary-framework/mcp-server@1.9.0-rc.2

The public prerelease is v1.9.0-rc.2.

What changed since rc.1

• Approval cards you can read. With the dashboard as the approval channel, a held Tier 1 request appears as a card that says in plain language what the agent asked for, and the operator’s Approve or Deny is what the held call receives. Card text, decision labels, operator token entry and the findings count were reworked since rc.1.
• A livelier console. The dashboard’s live stream now carries inbox and agent status updates, and while that stream is open and the tab is visible the console also refetches its inbox and agent data about once a minute. Live refresh stays partial in the Assurance Matrix; the dashboard does not promise real-time delivery.
• Restore a locked-down agent (macOS). On macOS, the operator can give a locked-down agent its network access back from the dashboard, through Tier 1 approval. A second approval of the same restore is refused, so one approval set restores once; a restore that fails leaves the agent locked down and can be tried again.
• Exports hand over their re-key key once. A dashboard export that contains encrypted state shows its re-key key once, in the approving dashboard only. If that response is lost, make a new export.
• Honest empty states. The inbox can project budget warnings and agent errors from the local agent registry, but no shipped component writes budget caps or an agent error status to it yet. Budget-warning cards therefore stay empty, as do blocked-egress, privacy and recovery cards until their producers carry evidence the card may claim. Agent-error cards from a failed fortress-wide lockdown still appear as before.
• Audit verification is stricter. audit-chain verify no longer passes an export with unsigned checkpoint records.
• Quieter automation. Runs with the CI environment variable set no longer open the dashboard in a browser. The MCP SDK dependency is updated to 1.32.0.

No signed macOS app is attached to this preview yet; the v1.8.4 app does not pair with it. Everything else in the rc.1 notes below still applies.

v1.9.0-rc.1 (2026-10-21)

This opt-in release candidate is published on npm’s next channel. The stable latest channel remains v1.8.4 until 1.9.0 ships. rc.1 carries the unpublished v1.8.5 changes, the v1.8.6 pre-release fixes, and everything merged to main since v1.8.4. No claim below goes beyond the bounded rows of the Assurance Matrix; changes with no matrix row are behavior changes, not new capability claims. The full list of changes is in CHANGELOG.md.

npm install -g @sanctuary-framework/mcp-server@1.9.0-rc.1

The public prerelease is v1.9.0-rc.1.

What changed

• Linux wall, published. On Ubuntu 24.04 (x86-64), the separately published Castle Wall Linux 0.1.0-1 package enforces a signed operator policy per user account, through five reboots on three fresh servers, and this release’s command line signs policies in the uid-<uid> scope form that package accepts (sanctuary-linux-policy-sign; tested, not drilled) and provides its upgrade command (sanctuary castle-wall upgrade-linux). That is the whole claim: one distribution and architecture, literal addresses only, a checksum-verified package with no signature or apt repository yet, no real agent harness tested, and unattended reboot survival is not claimed.
• Setup an agent or script can finish. sanctuary protect --passphrase-stdin reads the fortress passphrase from piped input, so setup completes without a terminal prompt. A refused protect now exits non-zero and says what to do.
• A smoother first install. Fixes from the unpublished 1.8.5 and the 1.8.6 previews, which never reached the default channel, are carried here: the fortress opens with the keyring factor init enrolled, the recovery key is staged outside the fortress, and a fresh fortress passes doctor. Default init no longer touches the machine-wide Castle Wall trust anchor; that changes only through a confirmed sanctuary castle-wall re-pin.
• The install planner says what it found. It reports whether an operator approval path is actually usable, where the staged recovery file is, and whether the vault is provisioned, so an installing agent knows before it acts.
• Ask the server before you wrap anything. sanctuary_help answers “should I install this”, “what are the bounds” and “how do I verify or uninstall” by pointing to read-only posture tools or the exact command.
• More complete backups and restores. Full exports and checkpoints include every exportable durable namespace (reserved internal namespaces are not exported); state import and checkpoint restore check version floors before writing anything and accept entries signed before an identity rotation; an interrupted restore or master-key rotation finishes on the next retry. The export and exit guarantee as a whole stays partial in the Assurance Matrix.
• Memory that survives restarts. Memory handles from sanctuary_remember persist across server restarts, and command-line memory ingest works on a fresh store. The command-line memory verbs now need the wrapped agent’s SANCTUARY_AGENT_ID and apply the same vault owner rule as the server.
• Verascore publishing asks first. reputation_publish now always requires operator approval, including on installs whose policy file lists it under tier3_always_allow, because Sanctuary wrote that line at first setup. No migration step is needed.
• Two more SIEM formats. audit_export_siem adds ecs (Elastic Common Schema) and xdm (Cortex XDR) output from the same redacted audit view as cef and ocsf, with field-mapping references in integrations/siem/.
• A dashboard that fails gracefully. It starts without waiting on optional requests, labels panels with no live data as unavailable instead of erroring, and a busy dashboard port no longer stops the MCP server: approvals are refused in that session instead.

Dashboard

The dashboard is now a console, dark by default, with a rail for Overview, Approvals, Agents, Machines, Enforcement, Findings, Evidence and Policies, and Talk as a side panel. On the new screens a value the server does not serve reads Unknown or Not evaluated with its reason, never zero.

• Overview shows the Castle Wall arm state, approvals waiting, open Sentinel findings, the audit chain check and how many detected agents have protection requested. Outbound connection counts appear only beside a current, passing audit chain check over a window the server read in full.
• Approvals is one queue for Tier 1 and Tier 2 holds with filters and a drawer that says what each request does and why it is held. Tier 1 approval takes two steps. Every decision ends in one kept result (taken, refused or unconfirmed), and decision controls on every screen pause while one is being sent.
• Agents, Machines, Findings, Policies and Evidence read served data: an agent detail page with its configured reach, a machine health check that reads Unknown rather than down when a machine does not answer, and an Evidence view of the audit log that states the server’s own chain verdict.
• Talk keeps a draft and the reader’s place through refreshes and between the side panel and the full page.

Security

• Ed25519 signatures checked through the shared identity verifier must meet a strict profile: non-canonical encodings, small-order points and points outside the prime-order subgroup are refused.
• A state export approved at the Tier 1 gate runs on the namespace set fixed when approval was requested.
• Command-line refusals for an unrecognized option or argument never print the text that was typed, apart from a single-letter short flag.
• Storage resolves each namespace name to one directory and checks stored names before changing anything; exit-bundle and memory-archive files are read through a size-checked, bounded reader.

Capability bounds

These bounds from earlier releases still stand, and nothing in rc.1 removes them:

• macOS Castle Wall boot survival is proven only for attended reboots on one host and one OS version; unattended reboot survival is not claimed.
• No audited per-rule, per-flow trail is claimed for the wall on macOS or Linux.
• On Linux, only the narrowed Ubuntu 24.04 (x86-64) claim above is proven. Fault injection, other distributions and CPU architectures, hostname and DNS rules, a real agent harness, and any Linux package build other than 0.1.0-1 are not covered.
• Agent wrapping is tested on representative harness paths and is not proven for every harness version.

Carried from v1.8.6 (pre-releases) and v1.8.5 (unpublished)

See v1.8.6.md and v1.8.5.md: the shared credential resolver for protect, export-passphrase, the install planner, the server boot and the dashboard boot; the recovery key staged beside the fortress; the default principal policy; explicit pin adoption or refusal; honest failure cleanup.