Briefing: Prompt Injection Is a Design Constraint, Not a Bug

Abstract dark textural background for a luxury private members club. Deep near-black charcoal surface with extremely subtle warm amber-gold gradient light bleeding from one corner. Fine grain texture, cinematic, moody, editorial. No objects, no people, no text. Very dark overall, high-end minimalist aesthetic like a Soho House interior at night.
Abstract near-black textural background evoking a private members club

The situation. As teams move from chat interfaces to agents that read email, browse pages, and call tools, prompt injection has quietly changed category. It used to be a curiosity — a way to make a chatbot say something off-script. In a system that can take actions, it’s the thing standing between “the model read a hostile web page” and “the model used my tools on the attacker’s behalf.” It is not a bug you patch. It’s a property of how these systems work, and it belongs in your design, not your backlog.

What we’re seeing.

  • The boundary moved, and most designs haven’t caught up. For a decade, the security boundary was the user. With a tool-using model, any text the model reads — a document, a search result, a webhook payload — can carry instructions it may follow. The untrusted input is no longer just what the user types. It’s everything the model ingests.
  • “Better prompting” is not a control. System prompts that say “ignore malicious instructions” reduce the rate; they don’t close the hole. Treating a probabilistic instruction-follower as if it will reliably refuse is wishful thinking dressed as mitigation. If the only thing between a hostile document and a real action is a strongly worded system prompt, there is effectively no control there.
  • The real controls are old ones. The mitigations that hold aren’t AI-specific. Scope the tools the model can reach. Require a human confirmation for actions that move money, change permissions, or send data outward. Keep the model’s privileges no higher than the least-trusted input in its context. This is least privilege and the confused-deputy problem, wearing new clothes.
  • Autonomy is the dial that sets the risk. The exposure isn’t “we use a model.” It’s “we let the model act without a checkpoint.” Every step you let it take unsupervised is a step an injected instruction can take too. The question isn’t whether the model is clever enough to resist — it’s what you were willing to let it do without asking.

What it means for you. Decide, per action, what you’re comfortable letting the model do on the say-so of text it didn’t get from you. Draw the line at effect, not intent: reads with narrow scope can run free; anything that writes, spends, or sends gets a gate. Design as if the model will occasionally follow the wrong instruction — because on a long enough timeline, it will — and make sure that when it does, the blast radius is something you chose in advance rather than something you discover in an incident.

Leave a Reply

Discover more from Nullhaus

Subscribe now to keep reading and get access to the full archive.

Continue reading