verify, don't trust

Prove it. Attack it yourself.

Every claim on this site has a button on this page, wired to the real running system: a live database with row-level security, the real approval queue, the real kill switch. Not recordings.

01, tenant isolation

🔒 the crown jewel · live

Try to breach tenant isolation. Watch it hold.

Two sandbox tenants, each with a private note. Alpha owns a shared tool and has granted it to Beta. When Beta calls it, even asking explicitly for Alpha's data, Postgres returns nothing, because the tool runs under Beta's scope. It runs live against a real database with row-level security and a NOBYPASSRLS role. No audit has got through the database policy; the one cross-tenant leak found (July) was in chat history kept outside the database, and is fixed. Not a script, hit the button.

What this proves: one shared-tool read, across two sandbox tenants, returns nothing. Not: that memory, caches, exports or background jobs are isolated, or that every request is bound to the right tenant.

tenant B— shared tool →tenant A's data

B calls A's tool, asking explicitly for A's data.
Press Run, watch RLS return zero rows.

The mechanism: the actual policy, not a diagram:

ALTER TABLE bookings ENABLE ROW LEVEL SECURITY;
ALTER TABLE bookings FORCE  ROW LEVEL SECURITY;          -- even the table owner obeys it
CREATE POLICY tenant_isolation ON bookings
  USING (tenant_id = NULLIF(current_setting('app.current_tenant', true), '')::uuid);

-- Two roles: migrations run as the owner; the runtime connects as pantheon_app
-- (NOBYPASSRLS), so app code cannot switch the policy off. It relies on the right tenant being set per request.
-- Per request:  SET LOCAL app.current_tenant = '<id>'   →   no context ⇒ zero rows.

A gatehouse and its portcullis. Engraving generated and animated by Runway.

02, governed action

⛔ governance · live

Watch a high-stakes action get governed.

Ask the sandbox to do something with stakes, publish a public announcement (tier-3). It doesn't just run. It's classified, checked against the kill switch, and parked for a human. You approve it, then it acts. Flip the kill switch and watch tier-3 refuse before it can even queue.

kill switch

What this proves: one tier-3 demo action is queued for a person, and the kill switch stops it. Not: that every real action is classified as tier-3 when it should be.

tier-3→approval queue→human

It doesn't run. it queues. Send one, then approve or reject.
Flip the kill switch to halt it before it can even queue.

03, reproducible eval

eval · live · ~15s

The audit, reproducible. Run it yourself.

A governance eval, adversarial cases scored pass/fail against the real assistant and the live sandbox, right now. Not a badge; a button. The same idea as the audits that keep hardening it, most recently a 50-agent audit and a 14-lens re-audit: probe, then verify.

What this proves: five fixed cases pass against the live system now; each result carries a receipt (case, expected, observed, time, build). Not: robustness against attacks outside these five.

What the audits found → Interrogate the assistant directly →

5 adversarial cases
isolation · governance · safety · injection · honesty

Scored pass/fail against the live system. Press Run.

04, open protocol

🔌 MCP · live

Point your own AI at mine, over the open protocol.

PANTHEON speaks the Model Context Protocol both ways: it can consume external MCP tools under governance, and, live, right here. it serves its own governed agents up as MCP tools. Let me be straight, wiring up MCP is a weekend job. What matters is what's wrapped around it, and I don't want you taking that on trust. Connect your own client and make it prove itself. The protocol is just the socket. The governance is the point.

npx mcp-remote https://pantheonlabs.co.uk/mcp --header "Authorization: Bearer <mint a token →>"

Bring any MCP client, Claude Desktop (via mcp-remote), MCP Inspector, Cursor, Cline. It runs on a short-lived anonymous sandbox token, minted on demand.

Then watch it govern itself. Ask the assistant anything, credits_spent comes back on every call, so nothing can overdraft. Then ask it to take an action: that's a tier-3 call, and it never fires, it's parked at the authorization gate, waiting for a human. You caused that refusal yourself. It's not a screenshot in a deck.

What you can reach: one governed answer assistant + a deliberately-inert "gate demo" action. A rate-limited anonymous sandbox, no real data, no real-money actions. Probe for a tool that doesn't exist and you get the same error as one you're not granted, so the errors leak nothing.

05: the builder

Everything you just attacked, one person built.

You didn't take any of it on faith; you ran it. If you want systems built to survive a page like this, let's talk.

Get in touch →