GOVERNANCE PIPELINE. FOUR GATES BEFORE EVERY TOOL CALL.

Without a single enforcement surface, every team writes its own guardrails. Finance wraps its MCP servers one way, data wraps theirs another, and security ends up auditing five permission models instead of one. A blocklist update has to be coordinated across every team that owns a tool.

systemprompt.io collapses that into one gate. Every MCP tool call from Claude Code, a scheduled agent, or another MCP server passes through the same permission check before any handler runs. The check loads the per-server deployment config, pulls the bearer token from the request, decodes and validates the JWT, and returns a typed authentication result. Every agent inherits the same policy without opting in, and a CISO reads one audit surface instead of N.

The gate runs in-process, not as a proxy or sidecar. There is no network hop between the agent and the policy decision. There is no second binary to deploy and upgrade. There is no ambiguous "did the sidecar see that request" moment during an audit. The middleware is named in the reference below, alongside the registry loader and the session manager that tracks live connections.

When a Claude agent tries to run a tool it should not have, the question is whether that stops at policy or at the backend. In a stock MCP deployment, nothing catches it until the downstream call fails, if it fails at all. systemprompt.io runs four synchronous gates in the request path before dispatch, and the first failure blocks the call.

Gate one checks whether the caller's role tier permits the server's required OAuth scopes, using a hierarchy comparison so an admin inherits everything below it. Gate two passes the request to the scanner detector, which rejects probes that typically precede credential theft: env-file sweeps, admin-path fingerprinting, high-rate bursts. Gate three matches the call against deny entries for specific tools, users, or data domains. Gate four applies a token-bucket rate limit per endpoint, multiplied by role tier, so an admin script gets headroom an anonymous caller does not.

Every gate returns a typed outcome. The request either moves on with an authenticated context, or it is denied with the failing gate named in the error. There is no "probably fine" state. The execution log records the attempt before dispatch and the outcome after. A CISO running "which calls did we block last week and why" gets the answer from one table rather than stitching five log streams together.

Role-based access control without enforcement is a spreadsheet. systemprompt.io encodes role tiers (Admin, User, Service, A2a, Mcp, Anonymous) as a single enum with numeric hierarchy levels, so a caller is either at or above a required tier or it is not. There is no fuzzy string match. There is no "senior admin" role that sneaks past a check because nobody added it to the whitelist. A tier mismatch returns a typed error at the gate.

Tiers alone are not enough. A finance analyst and an engineering analyst share a tier but should not share a tool surface, so the request context also carries department scope, the caller's roles, and a session ID. Tools outside the caller's scope are not hidden behind a 403 at call time. They are absent from the manifest the caller loads, which closes the information-leak variant of the access bug. The caller cannot know a tool exists to attack it.

Upstream identity still has to land somewhere. A proxy-verified authentication path reads identity from headers a trusted upstream proxy attaches, then runs the same scope and audience checks as a direct bearer token. An existing SSO or identity-aware proxy fronts systemprompt.io without forcing every caller to re-authenticate, and the audit row still names the end user, not the proxy.

Governance that runs after the tool call is a post-mortem, not a control. If a leaked admin token calls a destructive tool at 3am and the alert fires five minutes later, the damage is done. systemprompt.io evaluates policy in the request path, returns an authenticated or anonymous context from the gate, and never dispatches a denied call. A block at policy time is a block the backend never sees.

The security team and the product team deploy on different clocks. A tightened rate limit, a new blocklist entry, or a revised scope definition should not wait for a product release. Those configurations live in a YAML file the loader re-reads at runtime, so a security change is a config push, not a coordination tax on engineering.

Every decision is recorded, allow or deny. The tool dispatcher writes a pending row before execution and updates it to success, failed, or timeout after. A hooks system raises lifecycle events (pre-tool-use, post-tool-use, failures, session start and end, user prompt submit, notifications, stop, subagent start, subagent stop) so an external action fires on a specific moment without rebuilding the binary. An auditor answering "was this tool blocked or did it execute" reads one table with a status column that rejects partial rows.

A SIEM buyer runs one test before committing to an audit source. Does the event schema import into Splunk or Datadog without a custom adapter? systemprompt.io emits structured JSON events (SSE-compatible) for every policy decision and every tool invocation. The trace_id, user_id, session_id, context_id, client_id, and task_id fields are fixed, so a SIEM search by user or by session is one query, not a regex over free-form strings.

Three output paths cover the three places security teams actually read events. File-based structured logs feed syslog or Fluentd for SIEM ingestion. A real-time event stream with per-user connection tracking, a short heartbeat, and automatic cleanup of dropped subscribers powers live dashboards without a background job reaping stale connections. A CLI event query lets a terminal-native responder filter events without opening a browser during an incident.

Rate limiting feeds the same audit surface. Per-endpoint base rates and per-tier multipliers produce decisions logged alongside scope and blocklist decisions. A single "rate-limited in the last hour, by caller" query answers the question a CISO asks after a runaway agent incident, without pulling a second dataset from a separate rate-limit service.