This one slipped past the front page with two upvotes, but it's exactly the kind of unglamorous security writing that the LLM-agent ecosystem desperately needs right now. The thesis is in the title: which model you route a request to is not a security boundary. And yet, increasingly, that's how teams are treating it.

You can see the pattern everywhere. A team builds an agentic system, notices that the cheap small model occasionally does something dangerous, and "fixes" it by routing sensitive operations to a bigger, smarter model that's "less likely" to be tricked. Or the inverse — they restrict a tool to a "trusted" fine-tuned model, assuming attackers can't reach it. Both are variations of the same fallacy: treating probabilistic alignment as access control.

A technical audience should care about this for a few reasons:

• It reframes a common architectural mistake. Authorization has well-understood primitives — capabilities, scopes, signed tokens, deterministic policy engines. Models are none of those. A jailbreak, a prompt injection from a fetched webpage, or even a stochastic bad sample can flip the "smart" model's behavior, and there's no audit log that says "the model decided not to authorize this."
• It maps cleanly to existing security thinking. "Don't put business logic in the frontend" is the same shape of argument. The LLM is the frontend here. Trust boundaries belong in deterministic code that runs after the model's output.
• The repo context matters. The doc lives inside llm-agent-audit, suggesting it's part of a broader checklist for auditing agent systems — which is the genre of writing that's currently underserved compared to the flood of "build an agent in 50 lines" tutorials.

The likely concrete recommendation: put a deterministic policy layer (allowlists, OPA-style rules, signed tool manifests) between the model and any side-effectful tool call, and treat the model's output as untrusted user input — because functionally, that's what it is once any external content has touched the context window.

This is the security-architecture conversation that should be happening loudly right now, while teams are still wiring up MCP servers and tool-calling pipelines, rather than after the first big agent-driven data exfiltration incident.