Red-teaming an LLM application needs two things that conventional penetration testing does not typically combine: the standard techniques used against any web or API-based system, and adversarial testing specific to how language models process and act on content. Skipping either half produces an incomplete picture. Skipping the conventional half misses authentication and authorization bugs that have nothing to do with the model. Skipping the model-specific half misses the risks that make this category of system distinct in the first place.
Start with conventional testing, because it still finds real issues
Before touching anything model-specific, run the standard penetration testing techniques you would apply to any application: authentication bypass attempts, authorization boundary testing, API fuzzing, dependency vulnerability scanning, and infrastructure configuration review. AI features are still delivered through conventional software, and a significant share of real incidents trace back to exactly these kinds of issues rather than anything specific to the model's behavior.
Map the model-specific attack surface before testing it
Before designing adversarial tests, map every content path the model processes, direct input, retrieval, browsing, email, tool responses, memory, and every tool the model can call along with its real-world effect. This map determines what the model-specific portion of the red team actually needs to cover, and skipping it tends to produce a red team that only tests the most obvious path, direct chat input, while missing the indirect paths that are often more damaging in practice.
Test direct and indirect injection separately and thoroughly
For direct injection, use a wide and continuously updated range of adversarial phrasings, not just the most well-known examples that most systems have already been specifically tuned to resist. For indirect injection, actually plant adversarial content in documents that will be retrieved, pages that will be fetched, and messages that will be processed, rather than assuming indirect risk is adequately covered by direct testing alone.
Test jailbreak resistance separately from application-specific injection
Include jailbreak attempts aimed at the model's general safety training as a distinct test category from application-specific injection, since the two target different things and a finding in one category does not tell you anything reliable about the other. Report them separately so the right party, the model provider or your own engineering team, can act on each finding.
Test tool authorization directly, not just through the model
For any tool the model can call, attempt to trigger unauthorized use of that tool both through model manipulation and, where feasible, by directly crafting the kind of request the tool would receive if the model were fully compromised. This tests whether the tool's own authorization check would actually hold even if every upstream defense, prompt structure, content filtering, failed completely, which is the scenario that matters most for understanding worst-case impact.
Measure consequence, not just compliance
For every successful manipulation, whether direct injection, indirect injection, or jailbreak, follow through to determine what actual consequence resulted: did it only produce an undesired response, or did it succeed in triggering an unauthorized tool call, and if so, did an independent authorization check catch and stop that attempt. This distinction is the single most important thing a red team report should communicate clearly, because it separates findings that need urgent fixes from findings that already have an effective backstop.
Test failure and degraded conditions
Include scenarios where a dependency the security architecture relies on is unavailable: what happens if a policy service times out, if an approval system is unreachable, if a rate limiter fails. Confirm the system fails toward denying sensitive actions in these conditions rather than defaulting to allow, since this failure mode is easy to overlook in normal testing but matters considerably during an actual outage.
Repeat testing after meaningful changes
A red team assessment reflects the system as it existed at the time of testing. Model version updates, new tool integrations, prompt changes, and new content sources connected to retrieval or browsing can all change the results of previous tests. Schedule re-testing after any of these changes rather than treating a single assessment as permanently valid.
Where TELEON fits
Where TELEON's policy enforcement is deployed through the gateway or supported middleware, red team testing can specifically verify whether attempted unauthorized tool calls were actually blocked at that enforcement layer, and its audit trail provides a record to confirm what was attempted, decided, and executed during the assessment.
Designing the actual test scenarios, mapping the content and tool surface, and interpreting which findings represent real consequence versus contained attempts, remains work the red team performing the assessment has to do.
A short red-teaming checklist
- Run conventional penetration testing before any model-specific testing.
- Map every content path and tool before designing adversarial tests.
- Test direct and indirect injection separately and thoroughly.
- Test jailbreak resistance as a distinct category from application
injection.
- Test tool authorization directly, not only through model manipulation.
- Measure whether a successful manipulation resulted in a real
consequence, not just an undesired response.
- Test degraded and failure conditions for fail-safe behavior.
- Repeat testing after model, prompt, or integration changes.
Red-teaming an LLM application well requires combining familiar security testing discipline with adversarial techniques specific to how these systems process content, and reporting findings in terms of actual consequence rather than just whether an attempt technically succeeded at the language level.