Is a second local LLM actually a security boundary, or just another probabilistic opinion?

I keep seeing the same security architecture proposed for local agents: user input → main model → guard model → tool execution It looks clean in a diagram. I’m not convinced it creates a reliable security boundary. The guard model is usually expected to classify inputs containing code, shell commands, SQL, Base64, URLs, retrieved documents, security research and red-team prompts. Those are also completely legitimate workloads for many local deployments. Increase sensitivity and the guard starts blocking useful technical work. Reduce sensitivity and indirect injections, encoded instructions and multi-turn attacks begin slipping through. It also seems risky to assume that a second model that is often trained on similar data and vulnerable to similar instruction confusion, can reliably supervise the first one. A more defensible architecture might be: The model proposes a structured action instead of executing it directly. Deterministic policies validate the tool, arguments, file path, destination and data classification. Retrieved documents are treated as untrusted data, never as authoritative instructions. Secrets and sensitive-data detection run independently from the model. High-impact actions require explicit approval. The guard model contributes a risk score, but does not make the final authorization decision. For people actually running local agents with shell, browser, filesystem, API or RAG access: Where is the real enforcement point in your stack? Has a local guard model added measurable value after deterministic controls were already in place? And how are you testing indirect or multi-turn prompt injection without drowning in false positives? Concrete failure cases would be more useful than lists of guardrail products: model, architecture, test traffic, threshold and what broke.