Concepts, hands-on walkthroughs, and the design reasoning behind the enforcement plane — explore by the part of the request path you care about, or filter the library below.
mcp-hangar.io/enforce-egress=true.TaskRelayNotSupported.Install the operator, apply a policy, and watch the same call go from allowed to denied.
One deterministic allow/deny path for every MCP tool call — and why that beats a passive gateway.
A visual walk from the client, through the enforcement seam, to the upstream — and where each control fires.
Why a governing chokepoint on the call path beats a passive proxy in front of your MCP servers.
No scores to tune, no baseline to train -- enforcement you can read, test, and reason about.
Every other page here argues what Hangar does. This one is the bill and the fence: the real cost of putting it on the call path, and the things it deliberately refuses to do.
An enforcement plane sits on the call path, so its availability is the floor under everything it governs. Running a second one was a governance problem long before it was a scaling one — here is why, and what the answer costs.
Hands-on: deny by default, allow only read-only tools, and pin egress to a single upstream.
Glob allow/deny/requireApproval plus secret-pattern and payload-size argument scanning -- deterministic, no ML.
Pin a tool schema fingerprint at authorize time; any drift fails the call closed.
OTel GenAI/MCP semconv spans and an identity-attributed audit record exported to OTLP and your SIEM over every governed call.
Mint → relay + ledger + TaskCreated → follow-ups → consent gate → recorded decision, one diagram at a time.
Governing an input_required task on the SEP-2663 wire -- gated on the client's own tasks/update, recorded and fail-closed.
Follow a relayed task from mint through follow-ups, an input_required consent prompt, to a recorded decision.
An MCP task hands the caller a promise the work will finish later. Most gateways either drop that promise on the floor or grow a job runner to keep it. Hangar does neither -- it relays the task and governs its lifecycle at the proxy seam, so every async task_id is a first-class governed object without Hangar ever running a job.
SEP-2663 promotes Tasks out of experimental into a negotiated extension -- the unblocker for governed relay.