The demonstrator panel

The gateway ships an admin panel with a read-only demo mode (View Demo on the login screen). Demo mode runs the same enforcement code paths as a live deployment on simulated traffic: the findings you see are the real scanner and gate output, not hand-drawn examples. The panel is the fastest way to see every agent governance surface in one place, and this page maps each demo surface to its documentation and the live endpoints that back it.

Demo mode is gated by the RAUCLE_DEMO_KEY environment flag: when it is not set, every /api/demo/* route answers 404 exactly like any unconfigured route, and panel access falls back to ordinary authenticated operation.

What the demo panel demonstrates

Panel surface	What it shows	Where to read more
Dashboard & connections	Live allow/deny/escalate decisions across banking, government, health and capability scenarios; a Threats lens keeps only denied and escalated calls	Chain reconstruction graph
Policies	The policy editor over the live policy files; every change is a re-minted, signed capability set	Security model
Simulate	Dry-run a policy against canned presets on a dedicated demo plane, with no apply route	Prove a policy (SMT)
Data protection	PII/DLP findings from the gate’s real scanner on simulated traffic	`raucle/scanner.py`
Prompt injection	Injection findings labelled per call; enforcement stays structural because the gate decides on signed capabilities, not model judgement	Security model: capability gate
Shadow AI	Unknown models, unapproved endpoints and bring-your-own-key attempts observed in traffic	OWASP Agentic Top 10 mapping
MCP Scanner	Static analysis of MCP tool manifests for hidden instructions, secrets, rug-pull wording and SSRF targets, driven by the gateway’s real scanner engine	MCP clients: vetting a server
Receipts	Every gate decision as a signed receipt, with filters, export and ancestry; hybrid PQ-signed receipts are labelled from the JWS header	Provenance Receipt v1, PQ1 hybrid extension
Offline verification	A third-party view of the demo’s receipts: JWS signature check and hash linkage recomputed locally, without contacting the operator	Verify a bundle offline
Emergency stop	The read-only emergency authority stop screen: OFF by default, arming is receipted, a global stop needs two distinct approval receipts	Emergency authority stop
Key model	Which key signs what: classical Ed25519 and hybrid ML-DSA-65 holders, and what failure of each means	Key operations

Capability tokens

The capability scenario in the demo exercises the capability gate end to end: agents act only inside an explicitly minted, Ed25519-signed capability whose scope covers the tool plus a constraint set, with expiry, issuer pinning through the trust registry, and revocation that cascades to the whole subtree. The Ancestry view under the receipts tab reconstructs a receipt’s capability chain, and revocation is a receipted API call on the gateway (RaucleGateway.revoke_capability). The token format and enforcement are described in the security model; the implementation lives in raucle/capability.py.

A guided walkthrough in the panel (the tour that starts on first entry) steps through capability tokens, policies and what the proofs guarantee.

Cross-org verification

Capabilities can cross organisational boundaries only after a cross-org handshake resolved through the agent trust registry: trust anchors are registry-signed checkpoints, and a capability only verifies if its issuer is registered. Two organisations do not share trust; they resolve it, per delegation, against a pinned registry. The handshake protocol is raucle-handshake/v1 and the trust registry is raucle/trust_registry.py.

Conformance without disclosure

The conformance re-verification layer (Provenance Receipt v1, companion design document) lets an auditor verify that policy constraints were satisfied without seeing the underlying call arguments. Field-level Merkle commitments pin selected argument fields; a partial re-check reports SATISFIED / VIOLATED / UNKNOWN per constraint, and UNKNOWN fails closed. A full zkVM proof is the only path that converts every UNKNOWN to SATISFIED without disclosure. This is v1 Draft 2.1 companion design, not a wire-format change; see the spec changelog.

Live demo endpoints

The demo routes are read-only demo-plane API routes on the gateway. They exist only when demo mode is configured (RAUCLE_DEMO_KEY); otherwise every one answers 404. Demo routes use the gate’s ordinary API-key authentication with the read-only demo key, which the authenticated panel fetches from GET /api/demo-key.

Endpoint	Surface
`GET /api/demo/mcp/manifests`	List the simulated MCP manifests
`GET /api/demo/mcp/manifests/{name}`	Fetch one labelled-simulated manifest
`POST /api/demo/mcp/scan`	Run the real MCP scanner engine over a manifest
`GET /api/demo/policy-simulate/presets`	Simulation presets
`POST /api/demo/policy-simulate`	Dry-run a policy against a preset
`GET /api/demo/stop`	Emergency authority stop screen state
`GET /api/demo-findings`	DLP, prompt-injection and shadow-AI findings from the real scanner and evaluation machinery
`GET /api/demo/capabilities`	Capability calls captured by the gate, minted envelopes and verification state
`POST /api/demo/capabilities/{call_id}/verify`	Offline-style gate re-verification of one capability call (fail-closed)
`GET /api/receipts/key-family`	The live signing key family: classical Ed25519 and hybrid ML-DSA-65 holders
`GET /api/demo/users`	Demo-mode user roster and operator roles
`GET /api/demo/siem`	SIEM forwarding view over simulated destinations
`GET /api/demo/config`	Read-only deployment configuration profile

Live gate endpoints (not demo-plane, same panel): GET /api/receipts, GET /api/receipts/{receipt_hash}/ancestors, GET /api/receipts/export, POST /api/receipts/{receipt_hash}/offline-verify and POST /gate for enforcement.

Every response is produced by the gateway’s real machinery in a disposable sandbox. Nothing in the demo writes to live policy, mints production capabilities or publishes anything.