Reviewing an LLM application for security touches several distinct risk categories, each with its own specific questions. This checklist consolidates them into a single working reference, organized by category so a review can move through it systematically rather than relying on memory for what to check.
Prompt injection and untrusted content
Confirm every content source other than your own fixed system instructions is treated as untrusted, including retrieved documents, fetched web pages, email and messaging content, and tool responses. Confirm there is an explicit hierarchy defining which sources can act as instructions versus data only, and that this hierarchy is reflected in prompt structure with clear, consistent delimiters. Confirm no rule with a real consequence depends solely on a system prompt instruction holding under adversarial pressure.
Tool authorization and action risk
Confirm every tool the model can call has an authorization check that is independent of the model's own request, verifying the calling identity's actual permissions rather than trusting the model's stated intent. Confirm hard limits, transaction amounts, rates, destinations, are enforced outside the model's control. Confirm high-impact or irreversible actions require approval with enough context for that approval to be meaningful, not a routine rubber stamp.
Output validation
Confirm generated output is validated appropriately for its actual destination before it reaches a browser, database, shell, or another agent. Confirm this validation includes both format checks and policy checks, since well-formed output can still violate a business rule that format validation alone would not catch. Confirm output passed between agents in multi-agent architectures receives the same validation as output reaching a human or an external system.
Data exposure and minimization
Confirm prompts include only the data a specific task actually needs, not full records included for convenience. Confirm retrieval applies access control before ranking by relevance, so unauthorized content never enters the model's context. Confirm sensitive values that do not need to appear in plain text are redacted or tokenized. Confirm logs that capture prompt or response content have defined retention limits and restricted access, separate from general application logs.
System prompt design
Confirm no secrets, credentials, or internal identifiers appear in system prompt templates. Confirm the prompt does not embed detailed reasoning about sensitive rules that would be useful to an attacker if exposed. Confirm prompt changes go through a review process comparable to code review, rather than being treated as casual text edits.
Failure and degraded conditions
Confirm every security-relevant dependency, a policy service, an approval system, an authorization check, has an explicit, deny-by-default fail-safe for high-impact actions. Confirm this behavior has actually been tested under a simulated outage, not just assumed based on the code's intended design.
Monitoring and detection
Confirm logging captures identity, policy decisions, tool calls, and outcomes for every meaningful interaction, not just infrastructure-level request logs. Confirm specific abuse signals, denial rate, unusual tool sequences, volume and cost anomalies, injection-pattern frequency, are actively tracked, not just theoretically loggable. Confirm there is a defined response process for when a signal crosses an alerting threshold.
Testing coverage
Confirm testing has covered direct injection with a current range of techniques, indirect injection planted in documents, web content, and messages, jailbreak resistance as a separate category from application injection, and multi-turn attack scenarios, not only single-message tests. Confirm testing has been repeated after any model version update, prompt change, or new tool integration since the last assessment.
Ownership and incident readiness
Confirm a specific person or role owns this feature's security and can answer detailed questions about its data, tools, and behavior. Confirm there is a fast, clearly defined way to disable the feature if something looks wrong, and that the person authorized to do so does not need to wait for a committee decision during an active incident.
Using this checklist proportionally
Not every item deserves the same depth of scrutiny for every feature. A read-only, low-reach internal tool can move through this checklist quickly. A customer-facing agent with tool access to sensitive actions deserves a thorough pass through every category, since the cost of a missed item scales with the feature's actual worst-case impact.
Where TELEON fits
Several items on this checklist, tool authorization, fail-safe behavior, monitoring, and audit logging, map directly to what TELEON's runtime policy enforcement and audit trail provide when deployed through the gateway or supported middleware. The remaining items, prompt structure, data minimization, output validation logic, and testing coverage, are application-level work that has to be done regardless of what runtime infrastructure sits underneath it.
The checklist in short form
- Prompt injection and untrusted content sources
- Tool authorization and action risk limits
- Output validation, format and policy
- Data exposure and minimization
- System prompt design and secret handling
- Failure and degraded-condition behavior
- Monitoring and detection signals
- Testing coverage across injection types and attack patterns
- Feature ownership and incident readiness
Working through these categories systematically, rather than relying on a general impression of a system's security, is what turns an LLM security review into something that reliably catches the risks that actually recur in practice.