Feature
Personal and sensitive data — names, emails, addresses, secrets, social security numbers — should never reach an AI harness or a model just because a tool returned it. Hodor removes it in flight, on every call, in both directions. You choose which fields are sensitive; the gateway enforces that choice.
A system prompt that says do not repeat personal data is advisory. It is text, competing with every other instruction in the context window, and it is read before the data arrives. Tool responses are appended afterwards — by the time a record carrying a customer name and a home address lands in the transcript, the instruction has already been processed and the data is already in context.
From that point it is out of your hands. Anything that persists the transcript persists the personal data with it, and every later turn re-sends it. Filtering after the fact means asking a model to forget something it has already been told.
Hodor sits between your agents and your applications and brokers every tool call, so the filtering happens before the payload ever becomes context. A model cannot repeat what it was never given.
Never reaches the model
Sensitive fields are stripped before the payload reaches the harness or the model. The work still gets done — the data just never leaves your perimeter.
Redact or tokenize
Remove a field outright, or tokenize it so the agent can reference and round-trip a value without ever seeing the real one.
You choose the fields
Names, emails, addresses, secrets, social security numbers — you decide what counts as sensitive, and Hodor enforces that choice on every call.
Both directions
The same control applies whether the model is sending arguments or reading a tool's response.
The agent calls a tool through its own connector
Each agent identity opens its own MCP connection to Hodor. The tool call arrives at the gateway rather than at your application.
The payload is evaluated against the policies bound to that identity
Policies are authored as code, with plan and apply diffs, and ship with built-in PII and secret detectors.
Sensitive fields are redacted or tokenized
A redacted field is gone. A tokenized field is replaced with a stand-in the agent can carry and hand back, with the real value never entering the context window.
Hodor swaps in the real credential and executes
The harness holds a Hodor key, never the credential for the application it is targeting. Hodor validates the request, substitutes the real secret, and makes the call.
The response is filtered on the same terms
The model reads a payload that never contained the personal data, so there is nothing sensitive for it to summarise, quote or pass on.
The decision is written to the audit trail
Every call is recorded with the identity, the arguments, the policy in force, the verdict and the latency — append-only, and replayable against either the policy that applied at the time or your current one.
Redaction is only as strong as the boundary it runs inside. With self-hosting, the gateway runtime runs in your own VPC: every tool call is intercepted and evaluated on your network, credentials are encrypted at rest in your own Vault, and the append-only audit log is written to your storage under your retention rules. Hodor's control plane keeps handling identity issuance, the policy editor and the MCP plumbing.
Related: all features · the MCP gateway · use cases
Bring a tool call that returns data you would rather a model never read. Thirty minutes, your stack on the screen.
