A practical guide to prompt injection testing for LLM applications, including tool use, data exposure, system instructions, authorization and workflow abuse.
Test the application, not only the model
LLM security depends on the surrounding application: retrieval sources, system prompts, tools, identities, authorization checks and downstream actions. A model response becomes materially risky when it can expose sensitive data or trigger an operation the user should not control.
Include direct and indirect injection
Direct prompt injection comes from the user. Indirect injection can arrive through documents, websites, emails or other data the application asks the model to process. Testing should validate how untrusted instructions are separated from trusted system behavior.
Treat tools as privileged interfaces
If an agent can call APIs, query databases, send messages or modify records, each tool needs its own authorization and input validation. The model should not be trusted to enforce business permissions on behalf of the application.
Review retrieval and data boundaries
Retrieval-augmented systems should be tested for cross-user or cross-tenant data exposure, overly broad indexing, hidden sensitive fields and unsafe document ingestion. The application's access model should be enforced before information reaches the model.
Plan for model uncertainty
Security controls should not depend on the model following instructions perfectly. Use deterministic checks for authorization, sensitive operations and policy enforcement, and log important agent actions so teams can investigate unexpected behavior.
What to do next
Use these principles as a starting point, then validate them against your own architecture, users, business workflows and threat exposure. Security priorities become more useful when they are tied to the systems and outcomes the business actually depends on.