Since no single technique reliably prevents prompt injection, the practical goal shifts from prevention to containment: build enough independent layers that a single technique failing does not translate into a real-world consequence. This is the same logic behind defense in depth in conventional security, applied to a risk that specifically resists a single, complete fix.
Layer one: prompt structure and content labeling
Most teams start here, and it's a reasonable place to start: structure prompts to clearly separate trusted instructions from untrusted content, use consistent delimiters, and tell the model explicitly which sections are data rather than instructions. This catches a meaningful share of unsophisticated attempts. It's worth doing. It just can't be the only thing you do, because a convincing enough sentence will still slip past it.
Layer two: filter what reaches the model in the first place
Restrict what the model even gets to see. Access control on retrieval, applied before ranking by relevance, keeps unauthorized content out of the context entirely, no matter how convincingly it might read once it's there. Restricting browsing tools to necessary domains, where the use case allows it, cuts down exposure to the open web's essentially unlimited injection surface. Less untrusted content reaching the model means less content the model has to successfully resist in the first place.
Layer three: keep tool scope narrow
This is where you bound the damage a successful injection could actually do. Every tool the model can call should expose only the narrowest operation it genuinely needs. A manipulated model that can only call a tool scoped to looking up a single order, with an ownership check built in, isn't going to cause much damage even if the injection fully succeeds at the language level. That's the point of this layer: it caps the worst case regardless of whether the first two layers held.
Layer four: authorization that doesn't take the model's word for it
Somewhere, something needs to check whether a requested action is actually permitted, using logic that doesn't depend on the model's own reasoning or stated intent. If an injected instruction talks the model into requesting a refund above the approved limit, this is the layer that actually stops the refund, because the check evaluates the request against a policy the injection has no way to touch.
Layer five: validate output before anything sensitive happens
Treat generated output as untrusted input to whatever consumes it next: a database, a shell, another agent, a rendered page. Validating and encoding that output for its actual destination catches the cases where an injection did successfully manipulate what the model produced, in a way that would otherwise cause harm downstream even after making it past every earlier layer.
Layer six: monitor for what got through anyway
At some point you have to accept that some attempt, somewhere, will get further than you'd like, and build for noticing it fast: unusual denial rates, injection-like patterns showing up in logged content, tool call sequences that don't look like anything you've seen before. This layer doesn't prevent an incident on its own. What it does is shrink the gap between an incident starting and someone actually noticing, and that gap is what determines how much damage piles up before anyone responds.
Why layering matters more than perfecting any one layer
A team that spends most of its effort perfecting the prompt structure layer, while leaving tool scope broad and skipping independent authorization, has built a defense that fails completely the moment a novel injection technique defeats that one layer. A team that implements every layer at a moderate, reasonable level of rigor has a defense where a single layer failing still leaves several more standing between the injection and an actual consequence. This is why defense in depth outperforms a narrow, deep investment in any single technique for a risk like prompt injection that cannot be fully solved at its source.
Prioritizing layers under limited time
Teams without unlimited security engineering time should prioritize layers three and four, tool scope and independent authorization, ahead of perfecting layer one, because these are the layers that bound worst-case impact regardless of whether the injection itself succeeds. A well-scoped tool with strict authorization is valuable even against an injection technique nobody anticipated. A perfectly worded system prompt provides no protection at all against a tool with no scope or authorization limits.
Where TELEON fits
TELEON directly supports layers four, five to some extent through policy on tool outputs, and six: independent authorization at the tool-call boundary, applied through the gateway or supported middleware, and an audit trail that supports detection and investigation. This gives a consistent implementation of the layers that matter most for bounding worst-case impact, across different agents and model providers.
Layers one through three, prompt structure, content filtering, and tool scope design, are application-level decisions that have to be made and implemented for each specific integration.
A short layered-defense checklist
- Structure prompts to separate instructions from untrusted content
clearly.
- Filter and access-control content before it reaches the model.
- Scope every tool to the narrowest operation needed.
- Enforce authorization independently of the model's stated intent.
- Validate and encode generated output for its actual destination.
- Monitor for injection patterns and unusual tool activity.
Prompt injection defense works as a set of independent layers, not a single solution. The goal is not eliminating every possible injection attempt; it is making sure that when one inevitably gets past an earlier layer, several more stand between it and an actual consequence.