· via dev.to (home feed)
dev.to post makes the case for deterministic policy proxies between LLMs and MCP tools
A dev.to post argues that prompt-based guardrails are not access control, and that agents calling MCP tools need a deterministic proxy enforcing policy the model cannot influence.

An old security lesson, reapplied to agents
A post on dev.to argues that any deployment connecting an LLM to tools over the Model Context Protocol (MCP) should place a deterministic policy proxy in between, one whose rules the model can neither reach nor argue its way around. The author, who signs as Cor of Skyblue Soft, presents the piece as commentary on a proxy project recently shown on Hacker News, and notes that the submission drew two points and no comments there. For the author, that gap between practical importance and attention says more about how early the industry is than about the merit of the approach.
The core argument is deliberately unoriginal. Swap the nouns and it becomes the story the industry has told many times about databases and SQL injection: untrusted input reaches a component that holds more privilege than the input should be able to invoke, and the dependable fix is to move the access-control decision somewhere the attacker's payload cannot touch.
What changed is the input
According to the post, the difference now is what counts as untrusted data. It is no longer a form field. It is a webpage the agent fetched, a tool response it ingested, or a document it summarized. The model becomes the target of the social engineering, and the author is blunt that even a well-tuned model is not a security boundary. Expecting it to enforce policy on itself is likened to asking the victim of a con to run the fraud investigation.
MCP made the problem urgent, the post contends, by standardizing how agents discover and call tools. That is good for interoperability, but it also creates a shared protocol surface that poisoned content can target consistently across implementations.
Prompt engineering is not a control
The author separates what is real from what is inflated in current discussion. The prompt-injection risk itself is genuine and, if anything, still underappreciated by people who have not tried to red-team these systems. What gets overstated is the belief that better system prompts can solve it: an instruction telling the model to ignore commands embedded in tool output amounts to a suggestion, and suggestions do not survive contact with adversarial input.
What gets understated, the post argues, is that the underlying problem is plain, classic access control: least privilege, deny-by-default, and enforcement outside the trust boundary of the component being manipulated. The author is skeptical of claims that AI security demands a wholly new discipline, suggesting that framing mostly benefits people selling something, when much of the work is applying known patterns to a new calling convention.
Practical implications
For developers building on MCP or any agent-tool architecture, the recommended posture is to treat the model's tool-invocation intent exactly like a request from an untrusted client, validating it against policy the model cannot influence through its inputs or outputs. If the only thing standing between an agent and a dangerous action is an instruction in the prompt, the post's verdict is that you have a hopeful wish rather than an access control.
For security teams, the guidance is that agent deployments deserve the same architectural review as any new integration with a privileged service, with one twist: the client making the requests is nondeterministic and reads whatever content it is given as potential instructions. That makes it a genuinely different threat model even though the remediation pattern is familiar.
Why it matters
Agentic tool-calling shipped widely before anything resembling a firewall for it became standard, and decisions about where policy enforcement lives are architectural, which makes them hard to retrofit after an incident. The post closes on an open governance question: once agent frameworks build in enforcement by default rather than as an add-on proxy, it is unclear whether the platform vendor, the app developer, or the security team ends up owning that policy, and how much friction people will accept before quietly disabling it. The near-total silence around the underlying project suggests the practice is still immature, which is precisely the stage at which this kind of plumbing gets decided, or skipped.
- #ai-security
- #llm-agents
- #mcp
- #prompt-injection
- #access-control