AI · Practical Technology

AI Security Checklist: What to Check Before Launching an AI Feature

AI features can be useful without being complicated, but they still need normal engineering discipline plus a few controls that are specific to AI systems. This checklist is designed for a final review before an AI-powered feature reaches real users.

Published August 15, 2026 · Panos Khan

1. Define exactly what the AI is allowed to do

Start with a narrow capability statement. Write down what the model can read, what it can produce, and which actions it can trigger. If an AI feature can call tools or services, give each tool only the permissions it actually needs.

A useful rule is: the model should not receive authority merely because it can ask for it. Application code should enforce permissions independently of the model's output.

2. Treat user and retrieved content as untrusted input

Prompt injection is one of the important security concerns in modern LLM applications. A message, web page, document, or retrieved passage can contain instructions that conflict with the application's intended behavior. OWASP's 2025 guidance includes prompt injection among the risks developers should consider. citeturn0search0

Keep system instructions, application policy, user content, and retrieved data conceptually separate. Validate sensitive actions in application code rather than trusting the model to recognize every malicious instruction.

3. Protect sensitive data

• Minimize the personal or confidential data sent to the model.
• Do not place secrets such as API keys in prompts, browser code, or client-visible configuration.
• Define retention and deletion rules for prompts, outputs, uploaded files, and logs.
• Check whether third-party model providers receive or retain the data used by your feature.

4. Put limits around actions and spending

AI systems can create unexpected usage and cost when loops, retries, long inputs, or automated actions are not bounded. OWASP's 2025 LLM guidance specifically expands its treatment of unbounded consumption to include resource management and unexpected costs. citeturn0search5

Set sensible limits for request size, output length, tool calls, retries, execution time, and daily or monthly usage. Make failure predictable rather than allowing an AI workflow to continue indefinitely.

5. Log enough to investigate failures

Good observability is more useful than simply storing every prompt forever. Record the events needed to understand what happened: request identifiers, model and application versions, tool calls, important validation results, latency, and errors. Avoid putting sensitive content into logs unless there is a justified need and appropriate protection.

6. Add human review where the impact is high

If an AI output can make a consequential decision or trigger an irreversible action, introduce a human approval step or another strong control. The exact boundary depends on the application, but the principle is simple: higher-impact actions deserve stronger verification.

7. Test the whole workflow, not just the prompt

A polished prompt does not make an application secure. Test the complete path: authentication, authorization, input validation, retrieval, model calls, tool permissions, output handling, error states, and monitoring. OWASP's GenAI Security Project provides a useful reference for organizing these AI-specific security reviews. citeturn0search4

8. Use a simple pre-launch decision

Before launch, ask four questions:

1. Can the AI access anything it does not need?
2. Can untrusted content change what the application is authorized to do?
3. Can a bug or unexpected model behavior create uncontrolled cost or activity?
4. Can the team detect, investigate, and stop a bad outcome?

If any answer is unclear, the feature needs another engineering pass before release.

Where this fits into a practical web workflow

For a small site or product, security does not need to become a giant process. Start with least-privilege access, careful data handling, bounded execution, useful logging, and tests that represent realistic misuse. These controls can be added alongside normal web-development work rather than treated as a separate AI project.

For related practical work on this site, see the Documentation, Research, Labs, and AI Blog.