Putting a Deterministic Cop Between Your LLM and Its Tools Is Not Optional Anymore

Two points on HN, and the most important architecture diagram you'll see this month

A proxy that sits between an LLM and its MCP servers, enforcing policy the model literally cannot reach or reason its way around. It got two points and zero comments on HN. That gap between significance and attention is the whole story of where AI security is right now.

Context: We've Been Here Before, Just with Different Nouns

If you swap "MCP server" for "database" and "prompt injection" for "SQL injection," this is a story we've told a hundred times. Untrusted input reaches a system that has more privilege than the input should be allowed to invoke, and the fix is the same fix it's always been: don't trust the thing that can be manipulated to make the access-control decision. Put the enforcement point somewhere the attacker's payload can't touch.

What's actually new is what the untrusted input is. It's not a form field anymore. It's a webpage the agent read, a tool response it ingested, a document it summarized. The model is the thing being socially engineered, and the model, no matter how well-tuned, is not a security boundary. It's an input-shaped surface with variable output. Asking it to also enforce policy on itself is like asking a con artist's mark to also serve as the fraud investigator.

MCP made this urgent because it standardized how agents discover and call tools, which is great for interoperability and mildly terrifying for anyone doing threat modeling, because now there's a common protocol surface that poisoned content can target consistently across implementations.

Hype Check: The Risk Is Real, the Framing Is Where It Gets Messy

The "prompt injection defeats your agent" risk is not overstated. If anything it's still underappreciated outside people who've actually tried to red-team these systems.

What tends to get overstated is the idea that you can prompt-engineer your way out of it:

• Better system prompts
• More careful instructions
• A stern warning to the model not to follow instructions embedded in tool output

That's not a security control. That's a suggestion, and suggestions don't survive contact with adversarial input.

What's understated: this is fundamentally an old problem wearing a new hoodie. Least privilege, deny-by-default, policy enforcement outside the trust boundary of the thing being manipulated. None of that is novel. The novelty is just that we're relearning it under time pressure because everyone shipped agentic tool-calling before anyone shipped the equivalent of a firewall for it.

Who benefits from the "AI security is a totally new discipline requiring totally new thinking" narrative? Mostly people selling something. The unglamorous truth is that a lot of this is classic access control applied to a new calling convention. That's not a knock on doing it well, it's a knock on pretending it requires reinventing security from first principles.

Implications: The Model Is a User, Not an Admin

For developers building on MCP or any agent-tool architecture, the practical takeaway is boring but correct: treat the LLM's tool-invocation intent the same way you'd treat a request from an untrusted client. Validate it against policy that lives somewhere the model can't influence through its inputs or outputs. If your only access control is "the model was instructed not to do that," you don't have access control, you have a hopeful comment in your prompt.

For security teams, this is a heads-up that agent deployments are going to need the same kind of architectural review that any new privileged-service integration gets, except now the "client" making requests is nondeterministic and reads whatever content it's given as potential instructions. That's a genuinely different threat model even if the fix pattern is familiar.

The low HN engagement here isn't really a signal about the tool's merit, it's a signal about how early we are. Nobody argues about seatbelt design until enough people have gone through windshields.

Open Question

When agent frameworks eventually ship built-in policy enforcement as a default rather than an add-on proxy, who ends up owning that policy: the platform vendor, the app developer, or the security team, and how much friction are people actually willing to accept before they quietly disable it?

• Cor, Skyblue Soft

Sources

• Show HN: A Proxy between LLMs and MCP servers with policy the model cannot reach
• AI-assisted draft or imaging, human-curated, reviewed and edited.

Top Comments (1)

The proxy pattern works best when the policy is dead simple and structural rather than semantic. Once someone tries to make the middleware inspect the intent of the prompt or parse natural language queries, they just push the same prompt injection problem into a second model. In my own local tools, hard path jails, read-only flag enforcement, and fixed token limits on shell output catch almost everything that goes sideways. The LLM can ask for whatever it wants, but the interceptor only honors schemas that were compiled before the agent started running.