Runtime privacy gateway

Decide each tool call before it leaves.

Every other check reads a trace after the fact. agentleak proxy sits between your agent and an MCP server and judges each tools/call against your flow rules before it is sent. The call is allowed, redacted or blocked, and the decision goes into a hash-chained evidence log.

Three answers, decided in time

The proxy launches the real server as a child process and forwards JSON-RPC untouched, except tools/call, which goes to the policy first.

  • allow: the call passes unchanged
  • redact: only the refused values are removed
  • block: nothing is sent, and the agent gets a readable reason
  • Every message other than tools/call crosses untouched

Judge the flow, not the presence

A SIN sent to your KYC vendor for identity checks is fine. The same SIN sent to analytics is a leak. Rules name the data type, the sender, the recipient and the declared purpose.

  • The same rule grammar as the CI gate
  • Purpose read from the call's _meta
  • A missing purpose fails a rule that requires one
  • Deny beats allow, whatever the rule order

Evidence an auditor can check

Each decision is one line carrying the hash of the line before it. agentleak evidence verifies the chain and names the first entry that was edited, removed or reordered.

  • Tamper-evident, hash-chained JSONL
  • Data types recorded, never raw values
  • --verify for a CI step
  • Text or JSON summary

The mental model

A gateway that breaks the agent gets switched off.

Blocking whatever looks sensitive stops the task, and within a week somebody removes the gateway. So a refusal redacts by default, and only the values whose flow was refused: the order number stays, the SIN goes. Blocking is kept for flows that a deny rule names, because a deny rule means “not this, ever”.

Before

A report tells you next week that a tool call carried a SIN to the wrong server.

With AgentLeak

The SIN is removed before the call is sent, and the log shows why.

  • Redact is the default refusal; block is explicit
  • A refusal comes back as a tool result the agent can read, not a broken frame
  • Types no rule names pass unjudged, so you tighten one data type at a time

How it works

From a flow rule to a verified decision log.

1

Write flow rules

Add privacy_policy.flows to agentleak.yaml: who may receive which data type, and for what purpose. The CI gate already reads the same rules.

2

Wrap the server

In your MCP client configuration, launch agentleak proxy with the real server command after --.

3

Let calls through

Permitted flows pass, refused values are redacted, and denied flows are blocked with a reason the agent can act on.

4

Verify the evidence

Run agentleak evidence to summarize decisions and check that no entry in the chain was altered.

Guard an MCP server

{
  "mcpServers": {
    "github": {
      "command": "agentleak",
      "args": ["proxy", "--config", "agentleak.yaml",
               "--evidence", "evidence.jsonl", "--",
               "npx", "-y", "@modelcontextprotocol/server-github"]
    }
  }
}

Read the complete implementation guide →

FAQ

Questions, answered.

Ready when you are

Test the path, not only the answer.

Create a local workspace, run a bundled scenario, then wire AgentLeak into CI or let your agent onboard itself.