MCP gateway architecture
The dispatch pipeline, end to end
This page shows what actually happens to a tool call — the pipeline as implemented, not as marketed. Every stage below exists in shipping code.
One governed tool call, end to end
The hero diagram, annotated: every stage below is shipping code, and every stage drops evidence into the chain.
The MCP authorization pipeline
Every governed MCP tool call passes, in order:
- Auth gate — the caller presents an Auth-issued MCP tool token (RFC 9068 JWT, JWKS-verified)
- Scope ceiling — the tool's declared scopes must all be within the token's scope set; a delegated key can never confer more than its owner intends, even for global admins
- Authority tier — the tool's declared authority level is checked against the subject's role standing
- Mid-session revocation re-check — session authority is refreshed before dispatch; a revoked or suspended agent is downgraded on its next call, not at token expiry
- Metering — quota and rate enforcement, usage attributed to the agent identity
- Handler — the tool executes
- Sealed audit — the event lands in the hash chain
Where Cedar fits, honestly: the Cedar policy engine (with policy_explain) governs administrative, platform, configuration, and token-management decisions. It is not evaluated per tool dispatch — the per-call pipeline above is what runs on the hot path. We say this precisely because it's the kind of claim that dies in demos when other vendors round it up.
The hash chain audit log design
SHA-256 row chain with sequence-contiguity checks; Ed25519-signed checkpoints, themselves chained via previous-signature inclusion; kid-keyed rotation that fails closed on unknown keys; unsigned-tail truncation reporting; HMAC-committed actor identities so GDPR crypto-shred erasure leaves the chain verifiable; KMS/HSM as the signing choke point; an advisory-locked sealer so the chain cannot fork.
Full verification semantics and the report schema are on the verify page.
Data plane: tokenization at ingest
Datasets are tokenized at ingest: deterministic HMAC-based tokens that are join-preserving (the same value tokenizes identically, so analytics, joins and entity resolution still work) and vault-reversible (detokenization is a privileged, logged operation, never a default). Classification tags PII/PHI; k-anonymity generalization coarsens quasi-identifiers; masking-by-default SQL views cover the non-tokenized path.
Query engine: DataShield Analytical DB, exposed via MCP. Performance methodology lives in the engineering blog — benchmark numbers are published with hardware, warm/cold state, and percentiles, or not at all.
Open components we build on
Named because they're checkable: Cedar (policy engine), Fastify (Auth services), Hono (fleet services), and SQLite where each fits — on Node 22. Analytical and transactional storage run on the DataShield Analytical DB and DataShield Transactional DB.
Honest limitations
- No inline traffic interceptor. We are not a proxy on your prompt path. Protection is in the data (tokenized at ingest) and at the MCP tool boundary — an agent that bypasses governed surfaces finds no raw PII in governed datasets, but we do not see or filter arbitrary LLM traffic. Run a gateway for that; we coexist with all of them.
LIKEon tokenized text doesn't work — deterministic tokens preserve equality and joins, not substring search. Documented, by design.- Guardian is v0.9.4 and Lighthouse v0.8.2 — live in production on our own infrastructure since April 2026. We say "in production," not "battle-tested."
- No SOC 2 yet — our security posture and its honest status live on the security page.
- Detection is not our layer — prompt-injection and jailbreak classification belong to detection vendors; we govern authority and evidence underneath them.
Questions a page can't answer?
Ask the quoting agentYou've seen the proof
Ready for a number? Scope your deployment and we'll price it against your own economics.
Get your quote →