CloakPipe documentation
Model proposes. Code disposes. An agent’s model decides which tool to call and with what arguments. CloakPipe sits between the agent and its tools, checks every call against rules you wrote down, and only lets through the calls those rules allow. It runs on your machines as one binary, cloakpipe, and is MIT-licensed.
CloakPipe does three jobs at the action boundary, the point where a model’s text becomes a side effect:
- Stop a tool call that is out of contract: an undeclared tool, an undeclared argument, an email to an address the task never mentioned, a refund over the limit.
- Ask a human when policy says a call needs approval, and let through only the exact call that was approved.
- Leave evidence: a signed, hash-chained entry for every decision, anchored to outside timestamping services, that an auditor can check offline without trusting you.
Declare, enforce, prove
| Step | What you do | What CloakPipe does |
|---|---|---|
| Declare | Write one cloakpipe.manifest.yaml: the tools the agent may call, what each argument may hold, which calls have side effects and which need approval. Optionally point it at a Cedar policy for rate limits and tiers. |
Loads and checks it at start-up, and refuses to start on a bad rule. See Manifest reference and Policy. |
| Enforce | Run your MCP server behind cloakpipe mcp-proxy. |
Checks each tools/call in order (contract, Cedar, approval, side-effect state) and forwards it or answers with a JSON-RPC error. See MCP tool gate. |
| Prove | Export the ledger with cloakpipe ledger export. |
Every decision is a signed ledger entry; epochs are anchored with an RFC 3161 timestamp authority and Sigstore Rekor; cloakpipe verify checks a pack offline. See Evidence & verification. |
The quick start runs all three on a sample support agent in a few minutes. In that example, a prompt-injected send_email to attacker@evil.example is refused as scope_mismatch, and a call to an undeclared export_customers tool is refused as undeclared_tool.
Release status
The latest release is v0.12.0 (27 October 2026): a GitHub release and the Docker image ghcr.io/rohansx/cloakpipe:0.12.0. It is not on crates.io yet; the quick start installs it from the tag. Every page labels what it describes:
- v0.11 since v0.11, and still in v0.12.0.
- v0.12 new in v0.12.0.
- Roadmap planned, not built.
| Capability | Status |
|---|---|
cloakpipe mcp-proxy over stdio, one upstream MCP server |
v0.11 |
Signed approval receipts bound to one exact call (cloakpipe approve) |
v0.11 |
Side-effect tracking with reconcile-before-retry (--operations-db, cloakpipe operations) |
v0.11 |
The single-file cloakpipe.manifest.yaml, closed by default, with one_of_context, idempotency_key and conditional approval |
v0.12 |
Cedar policies with persistent call counters and @approval |
v0.12 |
A signed decision ledger written by default, shadow mode (--mode shadow) |
v0.12 |
Scheduled anchoring epochs, cloakpipe ledger export and cloakpipe verify |
v0.12 |
| A lean default binary, MIT-only licence | v0.12 |
HTTP/SSE MCP transport, several upstreams behind one gate, tools/list pinning |
Roadmap |
| Tool-call checks in the OpenAI/Anthropic-compatible LLM proxy | Roadmap |
| Webhooks and OpenTelemetry export, an approval broker, replay of a candidate manifest | Roadmap |
v0.11.0 configured the gate with the older pair of files, an AgentRelease plus a ToolContract. v0.12.0 still reads that pair, with a deprecation warning, for one more release.
What it is not
- Not a sandbox. It decides whether a tool call goes through. It does not contain a tool server that is already running, or code the agent runs some other way.
- Not a prompt filter or jailbreak detector. It does not read the model’s reasoning. It checks the call the model proposes against rules that do not depend on the model.
- Not observability. Traces show what happened afterwards. The gate decides before the call happens and records why.
- Not identity or access management. It does not issue or broker credentials. It decides what a release may do with the tools it already has.
- Not a hosted service. The gate runs on your machines and calls no CloakPipe service. The only outside calls are the ones you turn on: anchoring sends a signed epoch head (hashes, no arguments) to the timestamp authority and Rekor log you choose. Hosted alerts and approvals are not built; if you want them, tell us on the waitlist.
The threat model is specific about what the gate does and does not protect against.
Open source
Everything on these pages is in rohansx/cloakpipe under the MIT licence. There is no paid tier of the gate. The same binary also has a PII transform (mcp-proxy --transform pii, and an OpenAI/Anthropic-compatible proxy, cloakpipe start) that pseudonymizes personal data in arguments. It is an optional transform on calls the gate has already allowed, not the product.
Where to go next
- Quick start: run the support-agent example and watch the gate refuse the injected email.
- MCP tool gate: every flag, the decision order and the refusal codes.
- Integrations: put the gate in front of a server in Claude Code, Cursor or Codex.
- Comparison: how CloakPipe differs from other agent governance tools.