Home Dashboard GitHub

Runtime Security Convergence — 4-Stage Pipeline with Guardrail MCP Tools

2026-03-10

securityguardrailsmcpdashboard

What We Built

A unified runtime security model that documents and exposes BrainstormRouter's 4-stage enforcement pipeline: pre-model, pre-tool, post-tool, and post-model. Each stage maps to specific security components already running in production — rate limiting, budget caps, RBAC, tool safety, PII scanning, streaming firewall, and anomaly detection.

Three new MCP tools (br_get_guardrail_config, br_update_guardrail_config, br_test_guardrails) give AI agents direct access to guardrail management without leaving the MCP session. This brings the total MCP tool count to 46.

Why It Matters

Enterprise customers need to understand exactly where security enforcement happens in the request lifecycle. The 4-stage model gives CISOs a clear mental model: every request passes through pre-model checks (can this agent make this request?), pre-tool checks (is this tool call safe?), post-tool checks (is the result clean?), and post-model checks (is the output safe to return?). No request bypasses all four stages.

For AI agents managing their own guardrail configuration, the new MCP tools eliminate the need to drop out of an MCP session to make API calls — agents can inspect, modify, and test guardrails inline.

How It Works

The 4-stage pipeline enforces security at each phase of request processing:

  1. Pre-Model: Rate limits, budget caps, policy engine rules, kill switch check
  2. Pre-Tool: RBAC permission verification, tool safety classification, argument scanning
  3. Post-Tool: Result validation, PII detection, data classification
  4. Post-Model: Streaming firewall (7-check pipeline), anomaly detection, audit logging

Guardrail MCP tools use config.read/config.write permissions — matching the HTTP API's RBAC contract for /v1/guardrails/*:

br_get_guardrail_config    → config.read
br_update_guardrail_config → config.write
br_test_guardrails         → config.write

The Numbers

  • 4 enforcement stages covering 100% of request lifecycle
  • 46 total MCP tools (up from 43)
  • 9 security API endpoints documented
  • 7 guardrail API endpoints documented
  • 3 new MCP guardrail tools

Live-Verification Boundaries

> Operational note: The items below are acceptance gates for production deployment. They require live infrastructure and cannot be covered by unit tests alone.

The following behaviors cannot be fully validated by unit tests and require live verification:

  • External guardrail provider execution: Both POST /v1/guardrails/test and br_test_guardrails resolve external providers via resolveProvider(), which constructs an HttpGuardrailProvider for registered external providers. Both paths use identical provider resolution and selection semantics. Live verification confirms actual HTTP callback latency, error handling, and response parsing.
  • MCP incident-response flow: The kill-switch → MCP tool blocking behavior is tested at the unit level but the full MCP-over-SSE transport path (client connects, kill switch activates, subsequent tool calls are rejected) requires a live MCP session.
  • Cross-surface RBAC consistency: This phase aligned guardrail permissions to config.read/config.write across HTTP RBAC, MCP tool manifest, and agents.json. Live verification should confirm that an API key with only config.read can call br_get_guardrail_config but not br_update_guardrail_config.
  • Kill-switch exemption under load: The governance tool exemption set (11 tools) is unit-tested, but behavior under concurrent MCP sessions with an active kill switch requires live validation.

These items are documented as acceptance gates for production deployment, not blockers for this phase's code approval.

Competitive Edge

No other AI gateway documents a staged enforcement model where security is applied at four distinct points in the request lifecycle. Portkey has rate limiting. OpenRouter has content filtering. BrainstormRouter enforces security pre-model, pre-tool, post-tool, and post-model — with MCP tools that let agents manage their own guardrails under RBAC governance.

Lockstep Checklist

  • [x] API Routes: Security and guardrail endpoints already existed; no new routes added.
  • [x] TS SDK: Already has full security + guardrails parity (status, policies, config, test, providers).
  • [x] Python SDK: Already has full guardrails parity (list_providers, add_provider, config, test).
  • [x] MCP Schemas: 3 new guardrail tools added to tool-manifest.ts, server.ts, agents.json.
  • [x] Master Record: Runtime security documented in concepts/runtime-security.mdx.