Adding a language model to an existing system, a feature that already has its own established security posture, is a distinct moment that deserves its own threat modeling pass, separate from the broader AI threat modeling guidance that applies once a system is already AI-native. The question here is narrower and more actionable: what new risk does this specific connection introduce to a system that was previously secure without it.
Identify exactly what the connection exposes to the model
Before anything else, list precisely what data and functionality this connection newly exposes to the model: what existing data will the model now be able to read, what existing functionality will it now be able to trigger. This list is often bigger than the feature team initially expects, because connecting a model to "answer questions about orders" might, depending on implementation, expose broader access than the feature description implies. The threat model needs to work from the actual technical access being granted, not the feature's marketing description.
Ask whether the existing system's trust assumptions still hold
The existing system was built with certain trust assumptions: maybe every request reaching a certain internal function was assumed to come from validated, well-formed application code, not from arbitrary content a language model decided to generate. Connecting an LLM to trigger that function introduces a new caller whose input isn't written by a developer but generated from unpredictable, potentially manipulated context. Explicitly checking whether each trust assumption the existing system relied on still holds once an LLM becomes a caller is the core of this specific threat model.
Trace what happens if the model is fully compromised at this connection point
Apply the assume-compromise exercise specifically at the new connection point: if the model were fully manipulated by an attacker the moment it calls into the existing system through this new integration, what's the worst it could cause. This often reveals that an existing internal function, perfectly safe when called only by trusted application code, becomes a meaningful risk once callable based on a model's potentially manipulated decision, even though the function's own code hasn't changed one bit.
Check whether existing authorization checks are sufficient for this new caller
Many existing internal functions rely on authorization checks assuming the caller is trusted application code acting on behalf of an already-authenticated request. Confirm these existing checks correctly apply the actual requesting user's permissions once the caller is a model's decision rather than a fixed code path, since a gap here can let an attacker's injected instruction bypass authorization that would have correctly applied to a conventional, non-AI code path making the same call.
Consider what happens to data that previously never left its original context
If connecting an LLM means data that previously stayed inside a specific, well-controlled internal context now flows into a model's prompt, and potentially into logs, traces, or a generated response, that's a new data exposure path the original system's design never accounted for. Explicitly tracing this new data flow, and applying the data minimization and logging discipline covered elsewhere, closes a gap that's easy to overlook when all the attention is on the new feature's functionality rather than its data flow implications.
Review this threat model before implementation, not after
The value of this specific threat modeling exercise comes from running it before the connection gets built, while findings can still shape the implementation's design, rather than as a retrospective review after the integration's already shipped. A finding that surfaces during design, "this internal function needs an additional authorization check before it's safe to expose to a model," is cheap to address. The same finding discovered after launch, once the integration's already relied on, needs a far more disruptive fix.
Document the specific new risks and their mitigations
Capture the specific new risks this threat model identifies, and the specific mitigations applied for each, as part of the feature's design documentation. That record supports later review of whether the mitigations actually got implemented as designed, and it's useful input for threat modeling the next similar connection, since the specific risks a given existing system introduces when connected to an LLM tend to recur in similar form for related integrations.
Where TELEON fits
Where this threat model identifies a specific action that needs independent authorization or an approval requirement at the new connection point, TELEON's policy enforcement, applied through the gateway or supported middleware, provides a place to implement that specific finding consistently.
The threat modeling exercise itself, tracing what a new LLM connection exposes and whether existing trust assumptions still hold, is analysis work that has to be done directly against the specific existing system being connected.
A short checklist
- List precisely what data and functionality the new connection exposes
to the model.
- Check whether the existing system's trust assumptions still hold with
an LLM as a new caller.
- Trace worst-case impact assuming the model is fully compromised at this
connection point.
- Confirm existing authorization checks correctly apply to model-driven
requests.
- Trace new data exposure paths created by data flowing through the
model's context.
- Run this threat model before implementation, not as a retrospective
review.
- Document specific new risks and mitigations for future reference.
Connecting an LLM to an existing system is a distinct moment worth its own focused threat model, since it introduces a new kind of caller whose behavior the existing system's design and trust assumptions were never built to anticipate.