# Security practices for AI agents
An agent reads text an attacker could have written, holds credentials and can act. Four practices keep it useful under attack: threat model, adversarial evaluation, runtime controls and incident practice.
Author: Murali Sid (https://linkedin.com/in/muralisid)
Source: https://www.agenticarchitectureskills.com/security
Published: 2026-08-31
Updated: 2026-10-15
Licence: CC BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/
Cite as: Murali Sid. Security practices for AI agents. Agentic Architecture Skills. https://www.agenticarchitectureskills.com/security
---
An agent reads emails, web pages and documents that an attacker could have written. It holds credentials, and it can act on real systems. A hidden instruction in what it reads, called prompt injection, can steer it. So a team cannot rely on the model to refuse a bad instruction. Security for an agent is four practices, in the order a team does them. Threat-model the workflow. Attack it before release. Control it at runtime. Practise for incidents. Each practice assumes the model can be tricked, and puts the control in [enforcement outside the model](/architecture/enforcement).
## The rule every practice protects [#the-rule-every-practice-protects]
Instructions, documents, emails, tool results and messages from other agents all reach the model as text. The model cannot reliably tell an instruction from data. An attacker uses that by putting instructions where the system expected data. NIST describes agent hijacking in these terms. Trusted instructions and untrusted data are not kept apart ([NIST CAISI, January 2025](https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations)). Better prompts and content filters reduce successful attacks. They do not stop all of them. So the design has to hold when the model is fooled.
No text the agent reads may create authority. That includes text from a user, a document, a tool, memory, another agent or the agent itself. Authority comes only from the agent's identity, a person's delegation and policy outside the model. [The delegation chain](/architecture/delegation-chain) traces every action to the person who asked.
The picture shows the same work as six steps. Step 1 is practice 1 below. Steps 4 and 6 are practice 2. Steps 2 and 3 are practice 3. Step 5 is practice 4.
## 1. Threat-model the workflow [#1-threat-model-the-workflow]
Start before the agent is built. Draw the workflow, not only the model. Mark every identity, data source, tool, [memory](/memory) store, approval point and outside effect. Mark which inputs an attacker can write. Mark which actions change something that matters: money, access, records or equipment. Then write down what must stay true even if the model obeys an attacker. Each of those rules gets a control outside the model.
The answers feed [the four questions](/architecture/agent-types) every agent is classified on. Two of them, its permissions and its impact, set the agent's tier on [the risk profile](/architecture/risk-profile). [Threat-model an agentic workflow](/security/threat-model) gives the method step by step.
## 2. Attack it before release [#2-attack-it-before-release]
Put hostile content where the real agent will meet it. That means email, web results, retrieved files, tool descriptions, memory and messages from other agents. Judge what the agent did to the systems, not only what it wrote.
Test usefulness and security together. A defence that stops the attack by stopping all useful work has not solved the problem. Tune the attacks to the defence, and run each one several times. In NIST's tests, attack success rose from 11 to 81 percent once attacks were tuned to the defence (January 2025).
Each failure becomes a regression test in the evaluation suite. The test must still pass after every change to the model, prompt, tool, policy or framework. This work sits at the evaluate and approve stages of [the agent lifecycle](/architecture/agent-lifecycle).
## 3. Control it at runtime [#3-control-it-at-runtime]
These are the controls the threat model called for, running while the agent works. Give the agent its own identity, credentials scoped to the task, a list of allowed tools and an expiry. This is least privilege. A user who may approve a payment does not make every agent acting for that user able to approve it. The agent can never enlarge its own authority.
Check every action outside the model. Enforcement works at three points: the tool gateway, the policy decision point and promoted rules. Validate the arguments of each call. Limit destinations and amounts. Stop the action when a check fails, and do not default to yes. Code the agent writes runs in a sandbox, with outbound network traffic limited to an allowlist.
Some decisions never belong to the model. [The four deterministic zones](/architecture/deterministic-zones) cover access, money, safety actuation and formal records. In those zones the model may prepare or flag. A fixed rule or a named person makes the final call. Models may take permission away, never grant it.
## 4. Practise for incidents [#4-practise-for-incidents]
Record the model, the prompt, the sources read, the tool request, the policy decision, the effect and any human approval. Write the record where the agent cannot touch it. A log the agent can edit is not proof.
Plan the response before you need it, and rehearse it. Revoke the agent's credentials. Stop it with a kill switch. Isolate any poisoned memory. Keep the evidence. Every incident then adds a test to the evaluation suite. [The observability and FinOps layer (R12)](/layers/r12-observability-and-finops) covers the traces and alerts this needs.
## A worked example: a billing exceptions agent [#a-worked-example-a-billing-exceptions-agent]
An energy retailer runs an agent on meter reads that look wrong. It reads the customer's account, including notes that customers write. It can propose a change to a bill. The [billing exceptions use case](/use-cases/billing-exceptions) shows the full design.
* **Threat model.** Customer notes are text an attacker can write. A bill change is in the money zone, so the agent is Tier 3 (strict). One rule must always hold: text in a note can never clear a hardship flag or release a bill change.
* **Attack before release.** Plant an instruction in a test account's notes. Then check the billing system, not the agent's summary. Did a bill change? Did a flag move?
* **Runtime controls.** The model never releases a change. A fixed rule checks the confidence level, a cap on the change and the hardship flags. A specialist approves everything else.
* **Incident practice.** If a planted note gets through, revoke the agent's credentials. Re-check the sample of released cases. Add the note to the test suite.
This is an illustrative design, not a measured deployment.
## What outside frameworks give you [#what-outside-frameworks-give-you]
Three outside sources help. None of them is a full security design.
* **OWASP Top 10 for Agentic Applications 2026.** OWASP is the Open Worldwide Application Security Project. Its list names ten risk areas for agents. They run from goal hijack and tool misuse to memory poisoning and cascading failures. Use it as a coverage check and a shared vocabulary ([OWASP, December 2025](https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/)).
* **MITRE ATLAS.** It is a public catalogue of attacks seen or shown against AI systems. Its agent entries include context poisoning, tool poisoning and credential harvesting. They also include pulling data out through agent tools ([MITRE ATLAS, accessed August 2026](https://atlas.mitre.org/)). Use it to turn a threat into concrete attack paths.
* **AgentDojo.** It is a test environment for agents that use tools. It measures whether the agent finishes a real task. It also measures whether an injection makes it do the attacker's task ([AgentDojo, NeurIPS 2024](https://proceedings.neurips.cc/paper_files/paper/2024/file/97091a5177d8dc64b1da8bf3e1f6fb54-Paper-Datasets_and_Benchmarks_Track.pdf)). It checks what the tools did, not only what the agent said.
The frameworks list threats. Your design still has to give each threat an owner and a boundary. Each defence needs a named place where it is enforced. Each test needs an outcome you can observe. Each control needs to leave evidence. [The security and identity layer (R10)](/layers/r10-security-and-identity) maps the OWASP and ATLAS entries to controls.
## When a security review is done [#when-a-security-review-is-done]
A review is done when it can answer six questions.
* **Intent:** What may the agent pursue, and what is out of scope?
* **Trust:** Which inputs are trusted, which are untrusted, and which can an attacker write?
* **Authority:** Which identities, credentials, tools and effects are available at each step?
* **Containment:** What rule, enforced outside the model, limits the harm if the model is fooled or wrong?
* **Evaluation:** Which normal tasks and attacker goals show the workflow stays useful and safe?
* **Evidence:** Which record, kept apart from the agent, proves the input, decision, approval, effect and recovery?
If an answer is missing, the review is not done. If an answer lives only in the system prompt, it is not a control.
## Read more [#read-more]
This section has one chapter so far.
Map intent, trust, authority, state and effects. Then turn each abuse case into controls and tests.
Other pages cover the rest of the work for now:
* Hostile content in retrieved documents and tool results: [from data to memory](/architecture/data-to-memory).
* Agent identity, least privilege and delegation: [the delegation chain](/architecture/delegation-chain).
* Tools and MCP servers: [the risk profile](/architecture/risk-profile) scores each tool grant. [The integration fabric layer (R03)](/layers/r03-integration-fabric) covers the tool gateway.
* Evaluation and red-teaming, which means attacking your own agent on purpose: the evaluate stage of [the agent lifecycle](/architecture/agent-lifecycle).
* Runtime checks and containment: [enforcement outside the model](/architecture/enforcement).
* Memory, context and data: [memory permissions and lifecycle](/memory/permissions-and-lifecycle).
* Detection, investigation and recovery: [the observability and FinOps layer (R12)](/layers/r12-observability-and-finops).
* OWASP mapped to controls: [the security and identity layer (R10)](/layers/r10-security-and-identity).
## Evidence and limits [#evidence-and-limits]
These practices are narrower than general cybersecurity. Normal application, cloud, identity and supply-chain security still apply. The agent practices add to them. OWASP and MITRE ATLAS change over time, so check them again when their lists change. A benchmark result describes the tested model, tools, attack method and tasks. It does not certify a production system. The practices assume prompt injection cannot be removed at the model. So this guide recommends less authority, checks outside the model, adversarial tests and independent evidence.
## Next step [#next-step]
[Threat-model one agentic workflow](/security/threat-model). Then score the agent on [the risk profile](/architecture/risk-profile).
Explore this topic
* [NIST CAISI: Strengthening AI agent hijacking evaluations](https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations), January 2025
* [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/), December 2025
* [MITRE ATLAS](https://atlas.mitre.org/), accessed August 2026
* [AgentDojo, NeurIPS 2024](https://proceedings.neurips.cc/paper_files/paper/2024/file/97091a5177d8dc64b1da8bf3e1f6fb54-Paper-Datasets_and_Benchmarks_Track.pdf)
* The architecture these practices rest on: [the target-state architecture](/architecture), [the deterministic zones](/architecture/deterministic-zones), [the delegation chain](/architecture/delegation-chain), [enforcement outside the model](/architecture/enforcement), [the autonomy contract](/architecture/autonomy-contract), [security and identity (R10)](/layers/r10-security-and-identity), [governance, risk and sovereignty (R11)](/layers/r11-governance-risk-sovereignty) and [observability and FinOps (R12)](/layers/r12-observability-and-finops)