If you're building LLM-powered agents and relying on prompts alone to enforce access controls, you're setting yourself up for a bad time. A new deep-dive on DEV.to makes this point with refreshing clarity: the model will do what it thinks you meant, not necessarily what you wrote in that system prompt three weeks ago.

The Fundamental Problem with Prompt-Based Security

The article walks through Part 7 of an ongoing experiment building an LLM-powered customer support agent. The core insight is brutally simple: somewhere in that codebase is a prompt that says 'only ever access the requesting customer's data.' That's great, until it isn't. Models hallucinate boundaries under pressure, interpret instructions creatively when context gets dense, or simply miss scope constraints buried in a wall of text.

Tool Scoping as a Defense Layer

The author's approach flips the security model on its head. Instead of trusting the model's interpretation of natural language constraints, they enforce permissions at the tool-calling layer itself. The agent doesn't just get told it can't access other customers' data—it physically cannot call the function that would retrieve it without the right context.

Deterministic Boundaries Beat Probabilistic Trust

This is where most developers drop the ball. We treat LLM outputs as somewhat trustworthy by default and then try to patch edge cases. The real move is making security decisions before the model ever sees the request. If a user isn't authorized for resource X, the function that fetches resource X should never appear in the available tool list.

Key Takeaways

  • Prompts are guidance, not guarantees—models will find creative interpretations under load
  • Enforce permissions at the infrastructure level, not the instruction level
  • Tool scoping lets you build deterministic security even when the model itself is probabilistic
  • The companion repository contains working code demonstrating these patterns in practice

What This Means for Your Stack

If you're shipping anything with LLM agents accessing user data, you need to be asking hard questions about your permission model right now. Not 'how do we prompt it correctly'—but 'what happens if the prompt fails?' Because it will fail. The question is whether you have a safety net.

The Bottom Line

Tool scoping isn't optional hardening for production LLM systems—it's table stakes. Build your permission model assuming your prompts will eventually lie, because they will. The author's work shows there's a better way: deterministic boundaries that don't depend on how well the model reads instructions.