Mitigating prompt injection in LLMs is not an input-validation problem, but a privilege problem, as LLMs inherently blur the line between instructions and data. Relying on "better instructions" or filtering mechanisms is insufficient because they depend on the model always behaving correctly, which is not guaranteed. Attackers only need one successful bypass of filtering, which can be circumvented by various encoding tricks or by embedding content in images or documents. The core issue is that LLMs have a single channel for both instructions and data, making it impossible to reliably distinguish between them at a protocol level.Therefore, the control that actually holds is to assume hostile instructions will be executed and design the system to make such execution "boring." This involves several structural changes. First, split the agent into two components: one that reads untrusted content without tools or credentials, and another that acts on structured data returned by the first, never directly seeing the untrusted text. Second, instead of allowing the model to invoke actions, let it propose intents which are then validated against a strict allowlist and schema. Third, break the exfiltration path by allowlisting outbound network requests by host and stripping or proxying remote references from rendered model output to prevent data leakage. Fourth, put a human in the loop for all irreversible actions, allowing the model to draft but requiring human confirmation for critical steps. Finally, bound every credential with per-agent keys, expiry, spend caps, rate limits, and external, append-only logs that record denials. Audit permission sets horizontally, considering how individually harmless capabilities combine to create dangerous configurations. This capability-based approach ensures that even if a hostile instruction is executed, it has nothing valuable to reach or act upon.