# AI security best practices: 14 controls for LLM apps, each with a test

Source: https://airedteamingservices.com/guides/ai-security-best-practices/
Publisher: Excession Labs (airedteamingservices.com)
Last updated: 2026-11-09

AI security best practices as a checklist of 14 controls for LLM apps and agents, each with a test and the OWASP LLM 2026 ID, plus a release gate and cadence.

> **Short answer:** AI security best practices start from one rule: treat the model as an untrusted component inside a trusted application. Limit what it can read and do, validate what it outputs, protect data and secrets, vet models and tools, log what happens, and test before every release. This page lists 14 controls, each with a test and its OWASP LLM 2026 ID. None of them stops prompt injection alone.

AI security best practices fit in one rule: treat the model as an untrusted component inside a trusted application, and build controls around it. The model reads text from users, documents and tools, and any of that text can carry instructions. This page lists 14 controls for LLM apps and agents, each with a test and the ID from the OWASP Top 10 for LLM Applications 2026. For the overview of the field, read [AI security](/guides/ai-security/).

## What makes AI security different?

Three properties set AI systems apart from ordinary web applications: the model cannot reliably tell instructions from data, its output varies between runs, and it often acts through tools. The first property drives most of the risk. OWASP's 2026 entry LLM01 defines prompt injection as input that alters model behavior in ways the developer did not intend, where the input can be user input, retrieved content, tool output, an image, audio, video or memory.

No known control removes this. NIST AI 100-2 E2025, section 3.4.4, says that because current mitigations do not offer full protection against all attacker techniques, designers may design systems "with the assumption that prompt injection attacks are possible if a model is exposed to untrusted input sources". The UK NCSC wrote in December 2025 that the best we can hope for is reducing the likelihood or impact of attacks.

So the practices below split into two groups. Some lower the chance that an attack works. Others cap what a working attack can do. Put more weight on the second group.

OWASP published a new LLM Top 10 on 4 August 2026. Entry IDs and order changed from the 2025 list, and many blogs still show the old IDs. The table at the end uses the 2026 IDs.

## How do you control model input and output?

Screen and constrain what goes in, and validate everything that comes out before anything downstream uses it. Input screening helps against known patterns. The OWASP cheat sheet says to treat it as one layer and not as a security boundary, so pair it with output controls and permission limits.

1. Separate trusted instructions from untrusted content. Put system instructions in the system role, mark retrieved text and tool output as data, and never concatenate user text into the instruction block. Test with documents that contain instructions and check that the model does not follow them.
2. Filter inputs and outputs with a guardrail, and measure it. A guardrail model is an LLM and can itself be fooled. Record the bypass rate against an attack set. See [AI guardrails](/guides/ai-guardrails/).
3. Validate model output like any untrusted input. Escape it before HTML rendering, parameterize it before it reaches SQL, and check it against a schema before a tool uses it. LLM10 covers output that flows downstream without validation and can cause XSS, SSRF or remote code execution.
4. Block outbound channels for data. Markdown images and links can carry data to an attacker's server when a client renders them. Strip or allowlist them. See [data exfiltration through Markdown images](/guides/data-exfiltration-through-markdown-images/).

## How do you limit tools, data and permissions?

Give the model and its agents the least access that the task needs, and put a human approval step in front of actions that cannot be undone. LLM03, Excessive Agency, covers systems that take damaging actions on unexpected, ambiguous or manipulated model output. OWASP's agentic list names Tool Misuse (ASI02) and Identity and Privilege Abuse (ASI03) for the same area.

5. Scope each tool to the caller. Run tool calls with the end user's permissions, not a shared service account. A model that acts as an admin hands an attacker an admin. See [AI agent permissions](/guides/ai-agent-permissions/).
6. Require approval for high-impact actions: sending email, moving money, deleting data, changing access. Test whether the approval screen shows the real action or only a model-written summary. See [human approval bypass](/guides/human-approval-bypass/).
7. Cap consumption. Set rate, token and cost limits per user and per session. LLM06 covers uncontrolled inference that causes outage, cost or model cloning.

The test for this group is the same: sign in as a low-privilege user, plant an instruction in content the agent reads, and see which tools it calls. Read [excessive agency](/guides/excessive-agency/) for worked cases.

## How do you protect data, RAG sources and secrets?

Assume the model can repeat anything it can read. Keep secrets out of prompts, enforce access rules at retrieval time, and design on the assumption that hidden instructions can be found. OWASP's LLM08, Hidden Context Exposure, says to design on the assumption that hidden context can be extracted.

8. Keep credentials out of the context window. Store API keys in the tool layer, so the model never sees them. Test by asking the assistant for its configuration and scanning logs for secrets.
9. Enforce document access at query time. Filter retrieval by the signed-in user's permissions and tenant before the model sees any chunk. LLM09 covers embedding and similarity search risks, including cross-tenant leakage. See [RAG security](/guides/rag-security/).
10. Treat the system prompt as public. Write it so that leaking it exposes no secret and no security rule. See [system prompt leakage](/guides/system-prompt-leakage/).

## How do you secure the supply chain: models, packages and MCP servers?

Treat models, adapters, datasets, packages and tool servers as third-party code. LLM04, Supply Chain, covers weak integrity in training data, models, adapters, conversion pipelines and deployment platforms. LLM05 covers data and model poisoning. OWASP's agentic list adds Agentic Supply Chain Vulnerabilities (ASI04).

11. Pin and verify. Record the model name and version, the hash of any downloaded weights, and the source of each tool server. Review a tool server's code and permissions before you connect it, and re-review when it updates. See [MCP security risks](/guides/mcp-security-risks/).
12. Control the memory and training data you accept. Memory that any user or document can write to is a poisoning path. See [agent memory poisoning](/guides/agent-memory-poisoning/) and [data poisoning attacks](/guides/data-poisoning-attacks/).

## How do you monitor, log and respond?

Log enough to reconstruct what the model saw and did, and decide in advance how you respond. You cannot investigate an incident if the prompt, the retrieved sources and the tool calls were not recorded.

13. Log each request with the user, the prompt version, the retrieved sources, the tool calls and the result, and protect the logs because they hold sensitive content. Alert on unusual tool use, such as a support bot calling an export tool.
14. Write a response plan for AI incidents: how to disable a tool, revoke a token, roll back a prompt or model, and notify affected users. Practice the first step.

## How do you test before release: gates and cadence?

Run a release gate that tests the controls above whenever the model, system prompt, tools, data sources or permissions change. Treat it like a regression test suite for security. Google describes layered defenses that raise the "difficulty, expense, and complexity faced by an attacker". It does not claim prevention, and neither should your gate.

Use this gate list before each release:

- Run the attack set for direct and indirect prompt injection and record the rate over repeated runs.
- Test each tool with a low-privilege account and with another tenant's identifiers.
- Check output rendering for script, link and image injection.
- Scan prompts, logs and responses for secrets.
- Confirm approval rules for each high-impact action.
- Review new dependencies, models and tool servers.
- Retest every finding fixed since the last release.

Outside the gate, schedule an independent test of the full system. An [AI application security assessment](/llm-application-security-assessment/) covers this, with scope agreed in writing first. Publish no promise that a test finds everything.

## Checklist: control, test and OWASP ID

Use this table as a working checklist. The IDs are from the OWASP Top 10 for LLM Applications 2026 and the OWASP Top 10 for Agentic Applications.

| # | Control | How to test it | OWASP ID |
|---|---|---|---|
| 1 | Separate instructions from untrusted content | Plant instructions in a document and check the model ignores them | LLM01 |
| 2 | Guardrail with a measured bypass rate | Run an attack set and record the rate | LLM01 |
| 3 | Validate and encode output | Return script, SQL and URL payloads and check downstream handling | LLM10 |
| 4 | Block data exfiltration channels | Render Markdown image and link payloads in the real client | LLM02 |
| 5 | Least privilege per tool and user | Call each tool as a low-privilege user | LLM03, ASI02, ASI03 |
| 6 | Approval for high-impact actions | Check the approval screen shows the real action | LLM03 |
| 7 | Rate, token and cost limits | Send repeated and long requests and watch limits trigger | LLM06 |
| 8 | No secrets in context | Ask for configuration and scan logs | LLM02 |
| 9 | Retrieval access control | Query as user A for user B's documents | LLM09, LLM02 |
| 10 | System prompt holds nothing secret | Extract it and review its contents | LLM08 |
| 11 | Pin and verify models and tool servers | Review versions, hashes and tool server code | LLM04, ASI04 |
| 12 | Control memory and training data writes | Write poisoned content as a normal user and trace its use | LLM05, ASI06 |
| 13 | Log prompts, sources and tool calls | Replay an incident from logs alone | Not listed |
| 14 | AI incident response plan | Run a tabletop exercise | Not listed |

## Questions

### What is the first control to put in place?

Limit what the model can do. Give each agent or tool the least privilege it needs, and require approval for actions that change data or spend money. Filters can miss an attack, and a narrow permission set limits the damage when one gets through. Then add output validation and logging.

### Can a prompt filter stop prompt injection?

It lowers the rate of known attacks. It does not stop the class. The UK NCSC says to beware of products that claim to stop prompt injection, and NIST AI 100-2 says to design systems with the assumption that prompt injection is possible when untrusted input reaches a model.

### How often should we test an AI feature?

Test before each release that changes the model, system prompt, tools, data sources or permissions. Between releases, rerun your attack set on a schedule your risk justifies. We publish no universal cadence, because the right interval depends on how often the system changes and what it can do.

### Do these controls apply to generative AI in internal tools?

Yes. Internal assistants often hold broader data access than public chatbots, so the data and permission controls matter more. The user population is smaller, but a prompt injection in a shared document or ticket can still reach every employee who uses the assistant.

### Where do secure AI development practices differ from normal secure development?

The usual practices still apply: threat modeling, code review, dependency checks and secrets handling. AI adds model and data supply chain risk, untrusted instructions inside data, and non-deterministic output. Test results can change between runs, so repeat attacks several times and record the rate.

## Sources

- [OWASP GenAI-LLM-Top10 2026 README (final list, entry meanings)](https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/README.md)
- [OWASP GenAI LLM Top 10 2026 resource page](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/)
- [OWASP Cheat Sheet Series: LLM Prompt Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html)
- [NIST AI 100-2 E2025: Adversarial Machine Learning taxonomy, sections 3.4.4 and 3.5](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-2e2025.pdf)
- [UK NCSC: Prompt injection is not SQL injection (8 December 2025)](https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection)
- [Google Security Blog: Mitigating prompt injection attacks with a layered defense strategy (June 2025)](https://security.googleblog.com/2025/06/mitigating-prompt-injection-attacks.html)
- [OWASP Top 10 for Agentic Applications (blog, 9 December 2025)](https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-era-of-autonomous-ai-systems/)