Security boundaries in multi-agent systems are the explicit checkpoints where one agent's output gets verified before another agent treats it as fact or acts on it. Most multi-agent architectures don't have these checkpoints by default. Agents pass messages to each other over the same channel, using the same trust assumptions, that a single agent uses for its own internal reasoning, which means a manipulated or compromised agent anywhere in the system can push its influence to every agent downstream without triggering anything that looks like an alert. Building real boundaries means deciding, deliberately, where verification happens, what gets verified, and what the receiving agent is allowed to do with unverified input.
Why implicit trust is the default failure mode
When teams build a multi-agent system, the natural instinct is to treat internal messages as more trustworthy than external user input, because they came from "inside" the system. That instinct is exactly backwards from a security standpoint. An agent that reads untrusted external content, a webpage, an email, is one hop away from every other agent that trusts its summaries or conclusions. Without a boundary, that untrusted content effectively travels through the system with rising credibility at each hop, simply because each agent assumes the previous one already checked.
Where boundaries actually need to sit
A boundary belongs anywhere control or trust changes hands: between an orchestrator agent and its subagents, between agents owned by different teams or handling different sensitivity levels, and especially between any agent that processes external content and any agent that acts on the first agent's conclusions. The boundary doesn't need to be elaborate. It needs to do one job well: decide what level of confidence the receiving agent should place in what it just received, and constrain what actions can follow from low-confidence input.
What crossing a boundary should require
At minimum, a message crossing a boundary should carry enough context for the receiving agent, or the infrastructure around it, to evaluate where it came from and what it's claiming. Some architectures tag messages with a provenance marker, distinguishing "verified fact" from "unverified summary of external content." Others route boundary-crossing messages through a policy check before the receiving agent can use them to trigger a tool call. Either approach beats the common default of passing messages through with no distinction at all.
The orchestrator is not automatically safe
Teams often assume the orchestrator agent, coordinating subagents, is the trusted center of the system and doesn't need its own boundary controls. That assumption breaks the moment a subagent returns manipulated output that the orchestrator passes along or acts on without question. The orchestrator needs the same skepticism toward subagent output that any well-designed agent should apply to external content, because from a security standpoint, a subagent's output is external content relative to the orchestrator's own reasoning.
Isolation limits how far a compromise travels
Beyond verification, physical or logical isolation, separate credentials, separate memory stores, separate rate limits per agent, limits how far damage spreads if a boundary check fails anyway. An agent that shares one broad service credential with five other agents turns a single compromised agent into a compromise of all five. Isolating credentials per agent means a boundary failure caps out at whatever that one agent's specific permissions allow.
Ownership changes are a boundary risk too
Multi-agent systems often get built by more than one team, and the boundary between agents frequently lines up with a boundary between teams as well. When one team updates its agent's behavior, its output format, its confidence signaling, without coordinating with the teams that consume that output, the trust assumptions baked into the receiving agent can silently stop matching reality. This isn't a hypothetical process failure, it's a routine one, and it's worth treating agent ownership handoffs and updates as security-relevant events that warrant a boundary re-check, not just a compatibility test for whether the integration still technically works.
Where TELEON fits
TELEON enforces policy at the tool-call boundary for each agent individually, which gives multi-agent systems a practical way to apply per-agent scoping and logging even when the agents themselves were built to freely exchange messages. Because enforcement happens at the gateway rather than inside any one agent's code, it applies consistently across agents built on different frameworks, and the resulting audit trail can show exactly which agent's decision triggered a given downstream tool call, which is often the hardest part of investigating a multi-agent incident after the fact.
Designing the actual verification logic between agents, deciding what "trustworthy" means for a given message type, is application-specific work that has to happen in the agent architecture itself.
A short checklist
- Draw every point where one agent's output feeds another agent's decision.
- Treat agent-to-agent messages as untrusted input, not implicitly verified fact.
- Tag or track provenance so receiving agents know what they're actually trusting.
- Give the orchestrator agent the same skepticism toward subagents as toward users.
- Issue separate credentials and memory stores per agent, not one shared identity.
- Route boundary-crossing messages through a policy check before high-impact actions.
- Log which agent's decision triggered which downstream tool call.
- Test what happens when one specific agent in the chain returns manipulated output.
Multi-agent systems get sold on the idea of specialization, each agent doing one thing well, but specialization without boundaries just means more places for a single bad decision to spread quietly. The systems that hold up under real attack are the ones that treat every agent-to-agent handoff as a decision point worth checking, not a formality.