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.
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, append-only audit chain over every governed call.
Mint → relay + ledger + TaskCreated → follow-ups → consent gate → recorded decision, one diagram at a time.
A real, blocking human decision on an input_required task -- 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.