Threat modeling an AI agent starts by mapping what it can do, not what it's supposed to do, and then walking through every way that capability could be misdirected. That's a different exercise than threat modeling a conventional application, because the agent's actual behavior at runtime depends on model output that isn't fully predictable in advance. You can't just diagram the code paths. You need to diagram the tools, the data sources feeding each decision, the trust relationships between components, and the worst-case outcome at every step where the agent chooses what to do next. Done well, this produces a prioritized list of where to put controls first, rather than a vague sense that "the agent could go wrong somehow."
Start with an inventory, not a diagram
Before drawing anything, list every tool the agent can call, every data source it reads, every identity it operates under, and every other agent or service it communicates with. Teams that skip this step and jump straight to a fancy diagram usually discover mid-review that they forgot a tool, an internal API the agent quietly gained access to months ago through a shared credential. The inventory is tedious and it's also where most of the real findings show up.
Walk the plan, not just the entry point
For each significant workflow, trace the agent's likely multi-step plan from the initial prompt through to the final action. At each step, ask what happens if the agent's current understanding is wrong, whether from a hallucination, a stale piece of memory, or a deliberately injected instruction. A threat model that only examines the first prompt misses everything that can go wrong three or four steps into a plan, which in practice is where a lot of real agent incidents start.
Rank actions by reversibility and cost
Once you have the list of possible actions, rank them by how hard they'd be to undo and how expensive a mistake would be, not just by how sensitive the underlying data is. A read query against a sensitive table is a lower-severity finding than an irreversible write against a public-facing system, even if the write touches less sensitive data. This ranking is what tells you where to spend limited review time and where to require human approval.
Identify every trust boundary explicitly
Draw a line everywhere control passes from one party to another: user to agent, agent to tool, agent to another agent, agent to memory store. Every one of these lines is a place where verification either happens or doesn't. Teams often find, once they draw this explicitly, that an internal agent-to-agent boundary has no verification at all, purely because nobody thought of it as a boundary in the first place.
Test the model, don't just review it on paper
A threat model on a whiteboard tells you where things could go wrong. Testing against realistic prompt injection, goal manipulation, and tool misuse tells you whether your existing controls actually catch it. Run both direct and indirect injection attempts against each identified trust boundary, and treat any successful bypass as a finding regardless of how contrived the attack scenario felt when you designed it.
Document the assumptions, not just the diagram
A threat model is only as good as the assumptions baked into it, and those assumptions rarely get written down anywhere durable. "We assume the retrieval index only contains internally reviewed documents" or "we assume the orchestrator never forwards a subagent's raw output directly to a tool call" are exactly the kind of statements that quietly stop being true a few months later, when someone adds a new data source or refactors the orchestration logic without realizing a threat model depended on the old behavior. Writing these assumptions down explicitly, next to the finding they support, gives future reviewers something concrete to check before they assume the original analysis still holds.
Where TELEON fits
Once a threat model identifies which tool calls matter most, TELEON gives teams a place to enforce the resulting policy consistently: a gateway between the agent and its tools or model providers that applies authorization checks at runtime and records what actually happened, which helps validate whether the threat model's assumptions hold up once the system is live. It also gives incident responders a concrete audit trail to check the threat model against after a real event.
The threat modeling exercise itself, mapping the agent's specific plans, tools, and data flows, is work only the team building that agent can do, since it depends entirely on what the agent is actually designed to accomplish.
A short checklist
- Inventory every tool, data source, identity, and connected agent the system uses.
- Walk full multi-step plans, not just the initial prompt, for each major workflow.
- Rank every possible action by reversibility and cost, not just sensitivity.
- Draw every trust boundary explicitly, including agent-to-agent communication.
- Check whether verification actually happens at each boundary you identified.
- Test direct and indirect prompt injection against every trust boundary.
- Prioritize controls for the highest-impact, least-reversible actions first.
- Repeat the exercise whenever a new tool, data source, or agent gets added.
A threat model for an agent is never really finished, because the system keeps changing underneath it: new tools, new data sources, new agents joining the workflow. Treating threat modeling as a recurring practice tied to every meaningful change, rather than a one-time document, is what keeps it useful past the first review.