Three Doors, One Guard

I was in an architecture review with a team two weeks from a production launch. Good team. They had read widely and thought hard, and they walked me through Bedrock guardrails, encrypted storage, access control, audit logging.

The lead engineer said they felt good about this one. From what I'd seen, that was fair.

But one thing in that architecture was the part they were most confident in, and it was the most exposed surface in the whole system.

Nothing they'd built was incorrect. Inspection at the front door, encryption at rest, all of it real work.

The problem was the shape. The model was sitting in a room with three doors and one guard.

So I pulled up Meta's research and turned my laptop around.

The room went quiet. Then the question I was hoping for: "Where exactly are we exposed?"

Draw the model in the middle. Three places it can be attacked.

Everyone protects this. Lambda pre-processing, WAF, structural separation between instructions and data. If a team has done anything at all, they've done this.

Maybe 30 to 40% of the teams I see cover this one.

Before the agent executes a tool call, inspect the proposed action. Guardrails on output, schema validation, allow lists for what it's permitted to invoke. For high-risk actions I'll add a dual LLM judge: a second model evaluating whether the proposed action actually matches the user's original intent.

This team had one and two. They believed that was the whole picture.

Almost nobody covers this, and it drives a large share of that 86%.

RAG documents. Web pages. Emails. API responses. Tool outputs. And in multi-agent systems, the output of one agent becoming the input of another.

Here's what made it sting for that team. They had spent months on their RAG pipeline. Database encryption, access control, audit logging, every layer locked down.

Nobody had looked at the content.

Nothing inspected what was inside the retrieved documents. Nothing inspected API responses coming back into context. It does not take much to poison a database source. It does not take much to poison an ingested PDF. And then your agent starts doing things nobody prompted it to do.

The layer they were proudest of was the one that would have owned them. Which happens more often than you would think, and for a reason worth naming.

This is the reframe that matters. A guardrail is a mechanism you can place at any of the three points. It is not a design.

Most teams place them at one. This team placed them at two. I almost never encounter a team that has placed them at all three, and that gap is the entire finding.

It helps to strip the word down. A firewall is just something that sits between a protected resource and the outside. Substitute the word proxy and the mystery goes away. Something sits between your MCP server and the outside API, looks at what is moving, and asks what are you doing here.

The model cannot tell them apart, and no amount of instruction makes it able to. The only way to keep them separate is architecturally, with something outside the model enforcing the distinction.

Once you accept a proxy at each door, the next question arrives fast. When the proxy catches something, should it fix it?

No. And this is worth being firm about, because the tempting answer is yes.

The firewall detects and refuses. It does not repair. It says I cannot let this through, and it kicks the request back.

You already use a tool that behaves this way. When Claude hits a limit it does not quietly rewrite your request into something acceptable. It tells you what it cannot do and hands the decision back: change the prompt, or change the model.

A proxy that rewrites is making a probabilistic judgment about intent, at the exact boundary you built to be deterministic. So it becomes a second thing that can be wrong, sitting where you needed something that could only be right or refuse. Refusal is the whole product.

Which is also why an active watcher beats a passive one. A monitor that observes and reports is useful for the team investigating afterward. It is not a control. If it cannot stop the thing while the thing is happening, you bought visibility, not a boundary.

A pattern I see when this lands: the team decides the answer is open weights, run the model in-house, nothing leaves.

That addresses one direction and people mistake it for addressing all of them.

Yes, a local model means your data does not go out. It does nothing about what comes in. The retrieved documents still enter the context. The API responses still enter the context. If somebody poisons the source your local model reads from, the model's location is irrelevant to what happens next.

So expand the surface when you have this conversation. It was never only about information leaving.

Three-point inspection is the first layer. It is not the last.

The containment layer is identity and access management with least privilege, enforced by infrastructure instead of by the model. So that when all three inspection points fail, and eventually one will, the agent's IAM rules deny the unauthorized action anyway.

Inspection catches what it recognises. Containment limits what a miss can do. You need both, which is just defense in depth applied to a component that happens to be probabilistic.

That team went from two doors to three. Here is what it actually takes, because I would rather you budget for it than discover it.

Take your production agent and answer three questions honestly.

Most teams answer the first confidently, the second partially, and go quiet on the third.

Then ask the containment question: if all three failed right now, what would the agent's permissions actually stop it from doing?

That 86% describes teams guarding one door. Guard all three, with containment underneath, and you are not in that statistic. It is also the difference between a wrapper and an architecture.

Chris