An agentic AI system involves at least three distinct components with different security properties: the model itself, which interprets language and produces variable output; the tools it can call, which perform real actions; and the underlying data those tools and the model's context touch. Drawing explicit boundaries between these three, rather than treating the whole system as one undifferentiated unit, clarifies exactly where each component's own security responsibility begins and ends.
The model boundary: interpretation, not authority
The model's boundary is defined by what it does: interpret content and produce a decision or response. It doesn't, in a secure architecture, hold authority to directly execute an action or directly access data without passing through the other two boundaries. Drawing this boundary explicitly means treating anything the model produces as a proposal subject to further evaluation, not an instruction that automatically executes, the same principle running throughout tool authorization guidance in this content series.
The tool boundary: authority, scoped and checked
A tool's boundary is defined by the specific operation it performs and the authorization check governing whether a given request to perform that operation is legitimate. This boundary is where the model's proposal becomes a real action, or doesn't, and it's the boundary most directly responsible for containing the consequence of a manipulated or incorrect model decision, since it's the last checkpoint before an action's real-world effect actually happens.
The data boundary: access rights, independent of the caller
A data boundary is defined by who's authorized to access a given piece of data, independent of whether the request comes from the model directly, a tool acting on the model's behalf, or a conventional application code path. Drawing this boundary explicitly means the data layer's own access control shouldn't assume a request is safe just because it originated from a tool call rather than a direct database query, since the requesting identity's actual authorization is what should govern access regardless of which component initiated the request.
Why conflating these boundaries causes specific failures
When these boundaries never get drawn explicitly, specific failures recur: a tool trusts the model's stated intent with no independent check because the boundary between model interpretation and tool authority was never clearly separated, or a data access point trusts any request coming through a tool without checking the underlying requester's actual permissions because the boundary between tool authority and data access rights got assumed rather than enforced. Naming each boundary explicitly in architecture documentation makes it possible to ask, for a specific integration, whether each boundary is actually being respected or has quietly collapsed into an assumption of trust.
Multi-agent systems multiply these boundaries
In a system where multiple agents interact, each agent introduces its own version of these three boundaries, and the boundaries between agents themselves become an additional consideration, covered in multi-agent security guidance: one agent's output crossing into another agent's model boundary should get treated with the same scrutiny as any other untrusted content crossing a boundary, not assumed trustworthy just because it came from another component within the same overall system.
Drawing the boundaries as an architecture review exercise
A useful architecture review exercise draws these boundaries explicitly for a specific system, model, tools, data, and any additional agents, and walks through each boundary asking whether it's actually enforced independently or has collapsed into an implicit trust assumption. This exercise, similar to the trust boundary mapping covered in threat modeling guidance, often surfaces specific, addressable gaps a more general architecture review focused on components rather than boundaries would miss entirely.
Boundaries should hold even when components change
A well-drawn boundary should keep holding correctly even as the specific model version, tool implementation, or data source behind it changes, since the boundary's enforcement logic doesn't depend on the specific characteristics of whatever sits on either side of it. This resilience to component change is part of what makes explicit boundary design valuable: it produces an architecture that stays secure through model upgrades, new tool integrations, and evolving data sources, rather than one whose security rides on assumptions specific to a particular component version.
Where TELEON fits
TELEON implements the tool boundary specifically, applied through the gateway or supported middleware, providing the authorization checkpoint between a model's proposed action and its execution, consistently across different models and tools.
Drawing and enforcing the model boundary, treating model output as a proposal, and the data boundary, enforcing access rights independent of the calling component, remain application-level architecture decisions that have to be designed directly into each specific system.
A short checklist
- Treat the model's output as a proposal subject to further evaluation,
not an authoritative instruction.
- Enforce tool authorization independently at the tool boundary,
regardless of the model's stated intent.
- Enforce data access rights based on the actual requesting identity,
regardless of which component initiated the request.
- Treat boundaries between agents in a multi-agent system with the same
scrutiny as any other untrusted content boundary.
- Explicitly review whether each boundary is enforced or has collapsed
into an implicit trust assumption.
- Design boundaries to hold independently of specific component versions
changing over time.
Drawing explicit security boundaries between the model, its tools, and the underlying data clarifies exactly where each component's own security responsibility lives, and it surfaces the specific, common failure mode of one component implicitly trusting another without an independent check.