v2.17.0 — Open Source — MIT License

Every MCP tool call ends in a verdict.

Hangar is a policy enforcement plane for MCP on Kubernetes.

Admission policy per server. Egress rules per tool call. An audit trail that names who did what.

Deterministic — no ML. Self-hosted — no SaaS. MIT.

A call denied on purpose

gh-readonly.yaml
apiVersion: mcp-hangar.io/v1alpha2
kind: MCPEgressPolicy
metadata:
  name: gh-readonly
spec:
  mode: Enforce
  tools:
    allow: ["github.get_*", "github.list_*"]
12:04:41team-research@corptools/callgithub.create_issuedeny-32021

The policy allows two read patterns, so the write is refused before it reaches GitHub — and the refusal is recorded against the caller who made it.

Why enforcement, not detection

MCP is getting a registry, tasks, and interceptors. Nothing in the protocol enforces anything. That's not a bug — it's a layering decision. Hangar is the layer.

No anomaly scores to tune, no baseline to train. If your platform team can review a NetworkPolicy, they can review a Hangar policy.

Detection
risk0.87— review?

A detector produces a signal, and a signal is a question. Someone has to triage it, decide whether it was real, and act after the fact.

  • Alerts you have to triage
  • Scores to tune, baselines to train
  • The call already happened
Enforcement
allow/deny-32021

A policy produces a verdict, and a verdict is an answer. The tool call is allowed or it is not, before it reaches anything.

  • Admission policy on the server spec
  • Per-server egress rules and tool-schema pinning
  • Approval gates on the call path
How it works

One proxy between your agents and your MCP servers

Every call arrives on the same path and meets the same gates, in the same order, whatever the agent and whatever the backend.

AI agentsClaude, GPT, custom
MCP
Hangarone deterministic path
MCP
MCP serversDatabases, APIs, tools

What a call meets inside, in order

  1. Tool-access authz
  2. Tool-withdrawal check
  3. Tool-schema digest-pin verifyopt-in
  4. Circuit-breaker / health
  5. Interceptor validatorsoff
  6. Approval gate
  7. Concurrency / backpressure
  8. Interceptor mutators — requestoff
  9. Egress L7 policy

What you do with it

Four decisions, taken before the call leaves

Govern who calls what

Expose only the tools a caller should see, and hold the dangerous ones for a human. Both decisions are per server and per tool, and both are recorded against the identity that triggered them.

config.yaml
mcp_servers:
  github:
    tools:
      allow_list: ["github.get_*", "github.list_*"]
      approval_list: ["github.create_issue"]
  1. Tool-access authz
  2. Approval gate
The gates →

Pin what tools claim to be

A tool's schema — its name, description and input/output shape — is fingerprinted with SHA-256 over its canonical form (RFC 8785). If an upstream quietly changes what a tool accepts, the call fails closed instead of running against the new shape.

config.yaml
mcp_servers:
  payments:
    tool_projection:
      digest_enforcement: block

Distinct from container image digest pinning, which the operator does separately at admission time.

  1. Tool-schema digest-pin verify
How pinning works →

Control where data goes

The last gate before the wire. An egress policy decides which upstreams a server may reach and which tool calls it may make — down to the arguments — and it is evaluated inside the tool invocation, immediately before any outbound I/O happens.

End-to-end enforcement needs core v1.6.0+ and operator v0.14.0+; the operator ships the MCPEgressPolicy CRD and its controller.

  1. Egress L7 policy
The policy language →
payments-egress.yaml
apiVersion: mcp-hangar.io/v1alpha2
kind: MCPEgressPolicy
metadata:
  name: payments-egress
spec:
  mode: Enforce
  tools:
    allow: ["payments.get_*"]
    deny: ["payments.refund"]

Prove what happened

Every call is written down with the caller attached — allowed and denied alike. A verdict nobody can attribute proves nothing, so identity travels with the record rather than being reconstructed afterwards.

Exportable as CEF, LEEF, JSONL and RFC 5424 syslog. OTLP is a separate trace and audit-span path, not a SIEM format.

12:04:41team-research@corptools/callgithub.create_issuedeny-32021
12:04:52team-research@corptools/callgithub.list_issuesallow

Since 2.5.0

Runs as a fleet

Until 2.5.0 the honest answer to can I run two of them was no — run one and make its restart fast. Now a replica set shares one PostgreSQL and agrees with itself.

One writer for the estate

A single instance holds the management lease. Discovery, deregistration and the other estate-wide moves happen there, so two replicas cannot undo each other's work.

Fenced, not just elected

The lease carries a generation, and a convergence loop's deregistration carries it into the write, so a superseded holder affects zero rows. Re-registering and metric snapshots rest on local belief, where a repeat costs nothing.

A log every replica agrees on

State is an event log the replicas follow, so a server registered on one is visible to the rest instead of living in one instance's memory.

The detail that makes it correct: a follower cannot assume events become visible in the order they were numbered. A lower-numbered event can commit after a higher-numbered one, so a reader that trusted the numbering would step straight over it and never come back. The tail waits for the point past which no earlier write can still appear.

What it takes to run more than one
Governed async tasks

Your longest-running operations were the least governed ones

The export, the migration, the bulk write — everything expensive and hard to undo hands back a handle in milliseconds and does the real work later. Hangar governs the relay of that task, and the moment it pauses for input, without ever becoming the executor.

How the governed relay works

TLS and custom CAs, SSRF refused at registration and re-checked on connect, JWKS-validated identity, rate limiting, value-level secret redaction — and the standards behind them, mapped against the OWASP MCP Top 10 including the three categories Hangar deliberately does not cover.

Security, in full

Install it, understand it, or look it up

Where to go next, depending on why you came.