CrewAI organizes work around crews, several agents with defined roles collaborating on a set of tasks, often with one agent delegating pieces of work to others. That structure is useful for breaking a complex job into specialized parts, and it also means the number of tool calls and model calls happening across a single crew's run can grow quickly, spread across agents that may not have been individually reviewed as carefully as a single-agent system would have been. TELEON doesn't need to understand a crew's task delegation logic to secure it. It sits at the point where any agent in the crew, regardless of its role, actually reaches out to a tool or a model, through the gateway or supported middleware, and applies policy there.
Every agent in a crew is a separate identity worth its own policy
A crew's agents typically have distinct roles, a researcher, a writer, a reviewer, each with different tools and different reasons to need them. Treating the whole crew as one undifferentiated identity for policy purposes throws away useful information. TELEON's policy enforcement can be scoped per agent identity, so a researcher agent's read-only tool access gets different treatment than a reviewer agent that might have write access to a final output destination. That granularity matters more in a multi-agent crew than in a single-agent setup, precisely because the roles are meant to be different.
Delegation doesn't hide a tool call from enforcement
When one agent in a crew delegates a subtask to another, the delegation itself happens inside CrewAI's own orchestration, but the actual tool calls that result from that subtask still cross the same boundary as any other call. TELEON evaluates each one independently. A delegated task that ends up calling a tool the delegate agent isn't authorized for gets denied the same way a directly-issued call would, regardless of which agent originally kicked off the task.
Task definitions and agent role scoping remain a design decision
CrewAI's flexibility in defining what each agent's role and available tools are is a design surface that policy enforcement doesn't replace. An agent role defined with broader tool access than its actual task requires carries that access into every call it makes, and TELEON's enforcement operates within whatever access was already granted at the framework level. Scoping roles tightly when the crew is built is still the first and most effective control.
Crews built quickly, especially early prototypes that later become production systems without a second pass on their design, are particularly prone to over-broad role definitions, since the fastest way to get a crew working is often to give each agent more access than it strictly needs and sort out the details later. That "later" step is worth actually doing before the crew handles real, consequential tasks.
Watching for coordination patterns that don't look right
A crew's normal operation involves a fairly predictable pattern of which agent calls which tools and roughly how often. Trust scoring and the audit trail, applied across all agents in the crew, can surface when that pattern shifts, one agent suddenly calling tools well outside its usual role, for instance. Interpreting whether that shift reflects a legitimate change in the crew's task or something worth investigating further is judgment that belongs to whoever understands what the crew is supposed to be doing.
Shared context across a crew needs its own scrutiny
Some CrewAI setups share context or intermediate outputs across agents in a crew, letting one agent's output feed directly into another's input. That sharing happens upstream of TELEON's enforcement point, so anything problematic embedded in shared context, an injected instruction from an earlier agent's output, for example, isn't something the tool-call policy layer inspects directly. It only sees the tool calls that eventually result from that context, not the context itself.
This is one of the more subtle risks in multi-agent crews, because an injected instruction that successfully manipulates a downstream agent will often still produce a tool call that, viewed in isolation, matches that agent's normal, allowed pattern. Policy enforcement catches the call if it violates a rule; it won't necessarily catch a call that stays within policy but was triggered by manipulated context rather than the agent's legitimate task.
Where TELEON fits
TELEON enforces policy on tool and model calls from any agent in a CrewAI crew at the gateway or supported middleware boundary, scoped per agent identity where useful, regardless of the crew's internal delegation structure. It doesn't scope agent roles or tool access at the framework level, and it doesn't inspect shared context passed directly between agents inside the crew.
A short checklist
- Scope each agent role in the crew to the minimum tools its task actually requires.
- Apply policy rules per agent identity rather than treating the whole crew as one entity.
- Confirm delegated tasks still route their resulting tool calls through the gateway.
- Monitor for one agent's calls drifting outside its established role pattern.
- Treat shared context between agents as an upstream concern outside policy enforcement's view.
- Test policy behavior against realistic multi-step delegation scenarios.
- Review role and tool scope whenever a crew's task definitions change.
- Use the audit trail to reconstruct which agent in the crew did what, in what order.
A crew's value comes from specialization, different agents doing different things well, and that's also exactly why uniform, undifferentiated policy across the whole crew misses what matters. TELEON's per-identity enforcement respects that specialization instead of flattening it. Making sure each role was scoped narrowly to begin with, and that shared context between agents doesn't quietly become a blind spot, is work that happens inside the crew's own design.