Your coding agent talks to a model provider over HTTPS.
That connection is a straight line: the agent asks, the provider answers, the answer lands in your editor.
Nothing in the middle looks at what came back.
For most of what an agent produces, that's fine.
For the rest of it — the query built by string concatenation, the API key the model helpfully echoed back into a code sample, the on user input — you find out later, in review, or in a scanner run, or never.
This is a walkthrough of putting a policy layer in that line: a local proxy your agent points at instead of the provider, which inspects the response stream and decides , , or before the text reaches you.
I'll use Cencurity Engine because it's the one I build, it's Apache-2.0, and it runs entirely on your machine.
The pattern generalises — if you're building your own gateway, the steps below are still the shape of the problem.
What you need first Go installed (the engine is a Go binary you run from source) An API key for whatever provider your agent already uses An agent or IDE that lets you override the API base URL That last one is the real prerequisite.
If your tool hardcodes the provider endpoint, none of this applies to it.
Most don't: Roo Code, Continue, Claude Code and Gemini CLI all expose a base URL, and anything reading will work too.
Step 1: Start the gateway Clone the repo, open a terminal in it, and run: Three flags, and each one is doing something you should understand before moving on: is where the gateway accepts traffic.
Local only. is your real provider base URL.
Swap it for , , — whatever you actually use. is the rule file. ships in the repo and is a working starter set, not a placeholder.
Note what is not in that command: your API key.
The gateway forwards whatever header your agent sends.
The key stays where it already lives, which means adding this layer doesn't create a second place a credential can leak from.
Step 2: Check it before you trust it loads your config and reports the active rule count.
Run it now, and run it again every time you edit the policy file.
A JSON typo that silently drops half your rules is the exact failure mode this catches — a gateway with zero loaded rules passes everything and looks perfectly healthy from the outside.
The gateway also exposes: — liveness — Prometheus-format plaintext Curl before you repoint anything.
If it doesn't answer, your agent is about to fail every request and you'll waste twenty minutes blaming the agent.
Step 3: Repoint your agent Change your agent's API base URL from the provider to .
The paths are passthrough, so the endpoint shape you were already using keeps working: OpenAI-compatible: Anthropic Messages: Gemini streaming: Then use your agent normally.
If you skip this step nothing breaks — your traffic simply keeps going straight to the provider and the gateway sits there doing nothing.
That's a surprisingly easy state to end up in and believe you're protected, so verify with the tests in the next step rather than assuming.
Step 4: Prove all three actions actually fire Testing a security control by hoping it never triggers is not testing it.
Drive each outcome deliberately.
Use so the SSE stream stays open: allow — ask for something ordinary, like a function that sums a list.
The stream should flow normally and the structured stdout log should carry . redact — ask the model to print a string shaped like a secret.
The stream stays open, the matching token comes through as , and the log shows . block — ask for Python that uses on a string.
The stream terminates right after the matching chunk.
Downstream receives followed by , and the log shows .
That last one is the detail worth internalising.
A block is not a clean HTTP error — the connection is already open and streaming when the decision happens.
Your agent sees a stream that ends early.
If your tooling treats an early as a successful empty completion, you'll get silent truncation rather than a visible refusal, and you'll want to know th