MCP Bastion

🛡️ mcp-bastion

A reliability & security proxy for the Model Context Protocol (MCP).

_Self-healing connections, runtime tool-security, and a compliance-mapped audit trail for your MCP servers._

-2ea44f-2ea44f))](https://github.com/Gowthaman90/mcp-defense-bench)

---

mcp-bastion sits between your MCP client (Claude Code, Cursor, Cline, Windsurf, Zed, Claude Desktop, or any MCP-compliant agent) and your MCP servers. It is client-agnostic — it works with any compliant client through configuration alone, with zero client-specific code — and non-invasive: your servers run unchanged, and removing Bastion is a one-line config revert.

📦 Package: mcp-bastion on npm · 🗂️ Official MCP Registry: io.github.Gowthaman90/mcp-bastion

🔒 Security, measured: on the open, vendor-neutral mcp-defense-bench v0.9.0, Bastion covers 66% of the MCP attack surface (24.6/37 vectors; 23 enforced) on development fixtures and 53% on the pre-registered held-out set, at zero false positives on matched controls — the broadest of the proxies measured.

📖 Launch story: Medium · dev.to

👤 Created & maintained by [Gowthaman Arumugam](https://github.com/Gowthaman90) — Independent Researcher. Companion benchmark: mcp-defense-bench.

Contents

• Why
• How it works
• Security model
• Features
• Quick start
• Demo
• Control tools
• Configuration
• Transports
• Per-user identity (gateway mode)
• Delegation checks
• Runtime authorization
• Runtime security
• Audit & compliance
• Client setup
• Architecture
• Development
• Roadmap
• Contributing
• Security
• License

Why

When an MCP server disconnects mid-session, the agent only sees a generic _"No such tool available"_ error — indistinguishable from a tool that never existed — and it cannot reconnect; only a human can. Long agent sessions silently lose capabilities and fail in confusing ways.

Bastion closes that gap. It health-checks every server, auto-reconnects with backoff, and — crucially — exposes control tools so the agent itself can inspect connection health and recover a dropped server without human intervention.

Bastion now spans three layers: reliability (v0.1), runtime security (v0.2 — tool pinning /

rug-pull & poisoning detection), and audit & compliance (v0.3 — pluggable sinks mapped to NIST

AI RMF / OWASP LLM Top 10). See the roadmap.

How it works

Today your client connects directly to each server. With Bastion, your client connects to Bastion, which connects to those same servers on your behalf — so it sits in the tool-call path and can add reliability (and, later, security) transparently.

Before:   Client ─▶ server A / server B / server C

After: Client ─▶ mcp-bastion ─▶ server A ─▶ server B ─▶ server C

Bastion is a standard MCP server to your client and a standard MCP client to each upstream. Because it speaks the protocol faithfully, it works with every compliant client automatically — the only per-client difference is where you put a few lines of config.

Security model

Bastion's security rests on three independent mechanisms. Heuristics feed all three and replace none of them: a heuristic finding is a risk signal, never a proof that a tool is safe.

Every finding carries a kind: deterministic (an exact comparison against a pin, a schema, a policy or a token's claims) or heuristic (pattern matching that can misfire on benign text and can be evaded by a novel payload). What each enforcement profile does with them:

Argument inspection blocks under balanced even though part of it is heuristic: a false positive costs the agent a retry, while a miss can run a command. Inline secret redaction in results (redactResponseSecrets) is on in every profile. Under observe nothing is blocked and each audit event records wouldBlock: what balanced would have done.

Known limits. Poisoning and response heuristics can be evaded by payloads they have not seen. Redaction covers known secret shapes, not every secret. Bastion does not sandbox the upstream server itself. Authorization trusts the identities it is given: bearer clients it authenticates itself, and delegation claims it verifies only in signature mode (see trustStructuralClaims).

Features

• 🔌 Client-agnostic — one binary, config-only integration; no per-client plugins.
• ♻️ Self-healing — health checks + capped exponential-backoff auto-reconnect for stdio servers.
• 🧭 Agent-recoverable — bastion__status and bastion__reconnect let the agent detect and fix drops itself, instead of hitting an opaque "no such tool" wall.
• 🧩 Transparent aggregation — merges many servers into one, with per-server tool namespacing to prevent collisions and tool-shadowing.
• 💬 Legible failures — a dropped server yields an actionable message, not a crash.
• 🛡️ Runtime security _(new in v0.2)_ — pins each tool's definition and blocks "rug pulls" (a server changing a tool after approval); heuristically inspects descriptions for poisoning; detects cross-server shadowing. See Runtime security.
• 🔐 Runtime authorization _(new in v1.4, opt-in)_ — per-caller, per-tool policy decided before any upstream contact: which client, user and agent may call which tool with which argument values, deny-overrides, default-deny, and an observe mode to preview a policy. See Runtime authorization.
• 📝 Audit & compliance _(opt-in)_ — structured, hash-chained audit events to pluggable sinks (console / file / webhook / OTLP), mapped to NIST AI RMF & OWASP LLM Top 10; since v1.4 with HTTPS-only remote sinks, retrying delivery, per-sink redaction and Ed25519-signed checkpoints that make a shortened log detectable. See Audit & compliance.
• 🪶 Non-invasive & reversible — your servers run unchanged; uninstall is a config revert.
• 🧱 Enterprise-grade codebase — strict TypeScript, layered architecture, ESLint + Prettier, and unit + end-to-end tests.

Quick start

Bastion is published on npm as mcp-bastion — the npx command below fetches it automatically, so there's nothing to install first.

1. Add Bastion to your client, pointing it at a config file:

// your client's mcpServers config

{ "mcpSer