MCP, Tool Governance & Distribution
Govern every tool call with a four-stage pre-execution chain, run a declarative MCP server registry with instant revocation, and ship signed skills and plugins.
On this page
TL;DR: Every MCP tool call passes a synchronous four-stage chain — scope check, secret scan, blocklist, rate limit — first-deny-wins, before the tool runs, with every decision audited under a trace id. MCP servers live in a declarative registry at /admin/catalog/mcp with per-server auth, role-based entitlement, and immediate revocation; skills and plugins ship through Ed25519-signed manifests.
Pre-execution governance
The chain runs before the tool executes, synchronously, on every call:
- Scope check — does the caller's token carry the scope and audience this server demands?
- Secret scan — do the tool arguments carry credentials that must not leave the boundary?
- Blocklist — is this tool or pattern explicitly denied?
- Rate limit — is the caller within their quota window?
Evaluation is first-deny-wins: the first failing stage stops the call, and the tool never runs. Every decision — allow or deny — is audited with trace linkage, so a denied call is as visible as an executed one:
systemprompt infra logs trace list --limit 20
systemprompt infra logs trace show <trace-id>
The chain's content-safety companion (what the secret and PII scanners actually detect) is covered in Content Safety, PII & Guardrails.
The MCP server registry
/admin/catalog/mcp administers the declarative registry. Each server declares:
- Auth requirements — the token audience and scopes a caller must hold (for example, audience
mcpwith scopeadminfor the administrative server). - Entitlement — which roles (
admin,user) may reach the server, so access follows the role an admin assigns. - Revocation — a server can be disabled with immediate effect, and JTI-based token revocation kills individual issued tokens without waiting for expiry.
Fail-fast schema validation
Registration validates up front: a server with a missing or invalid manifest, or whose declared schema fails to sync to the database, is refused at registration rather than discovered broken at call time. Tool input schemas are captured at discovery, so what a tool accepts is on record. (One caveat: captured schemas are not meta-validated against the JSON-Schema spec itself — see the roadmap.)
Signed distribution of skills and plugins
Skills and plugins are distributed through /admin/catalog/plugins and /admin/catalog/skills, carried by Ed25519-signed manifests: a client verifies the signature before installing, so nothing unsigned or tampered-with reaches a workstation, and central revocation removes an artifact from circulation immediately.
Signed manifests can carry prompt content, but there is no first-class versioned prompt-template object with parameters, pinning, and rollback yet — that lifecycle is on the Enterprise Roadmap.
Verified evidence
Every capability on this page is proven by tagged end-to-end tests run against a seeded instance. To replicate: just start, then just e2e-seed --reset, then the command in the table. Screenshots regenerate with just e2e-screens.
| Ref | Verified behaviour | Replicate with |
|---|---|---|
| REQ-040 | A signed skill/plugin installs after signature verification and disappears from circulation on central revocation | just e2e-req REQ-040 |
| REQ-041 | Each of the four chain stages denies its case pre-execution, first-deny-wins, with the decision audited under a trace id | just e2e-req REQ-041 |
| REQ-042 | The registry enforces per-server auth/scopes/audience and role/group entitlement, and JTI revocation kills an issued token | just e2e-req REQ-042 |
| REQ-043 | Registration of a server with a missing or invalid manifest fails fast; tool schemas are captured at discovery | just e2e-req REQ-043 |
Deeper gateway-level checks for these behaviours also run in the platform's integration suite (just test-integration).
Screenshots
