Security practices for AI agents

An agentAgent. Software that uses an AI model to work toward a goal on its own: it reads, decides the next step, uses tools, and keeps going until the job is done or a limit stops it. 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 injectionPrompt injection. An attack where instructions hidden in content the agent reads (an email, a web page, a document) trick it into doing something its user never asked for., can steer it. So a team cannot rely on the modelModel. The AI engine that reads and writes text. On its own it has no access to your systems; everything built around it decides what it may do. 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.

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). 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.

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

Start before the agent is built. Draw the workflow, not only the model. Mark every identity, data source, toolTool. A function an agent can call to do something real: look up a record, send an email, run a query. Tools are where agents touch your systems., 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 every agent is classified on. Two of them, its permissions and its impact, set the agent's tier on the risk profile. Threat-model an agentic workflow gives the method step by step.

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 suiteEval (evaluation suite). A set of test tasks with known right answers, written by people who know the work, used to check an agent before and after any change.Read the page. 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.

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 privilegeLeast privilege. Giving an agent only the access its current task needs, and taking it back when the task ends.. 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 gatewayGateway. The single door every agent request passes through on its way to a tool or model. Because everything goes through it, it is where rules are enforced and activity is recorded.Read the page, the policy decision pointPolicy decision point. The component that says yes or no to an action by checking rules against who is asking. The agent asks, the decision point decides, and the agent cannot skip it.Read the page 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 sandboxSandbox. An isolated environment where agent code runs with limited access to the network and the rest of the machine, so mistakes and attacks stay contained.Read the page, with outbound network trafficEgress control. Rules about what a sandbox or agent is allowed to send out to the internet or to other systems. limited to an allowlist.

Some decisions never belong to the model. The four 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

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 switchKill switch. A guaranteed way to stop an agent immediately, built at more than one point so that one failure cannot disable it.Read the page. Isolate any poisoned memory. Keep the evidence. Every incident then adds a test to the evaluation suite. The observability and FinOps layer (R12) covers the tracesTrace. The step-by-step log of one agent run: what it read, what it called, and what it decided.Read the page and alerts this needs.

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 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

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).
• 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). 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). 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) maps the OWASP and ATLAS entries to controls.

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

This section has one chapter so far.

Other pages cover the rest of the work for now:

• Hostile content in retrieved documents and tool results: from data to memory.
• Agent identity, least privilege and delegation: the delegation chain.
• Tools and MCPMCP (Model Context Protocol). An open standard for connecting agents to tools and data, like a universal plug. An MCP gateway is the governed version of that plug.Read the page servers: the risk profile scores each tool grant. The integration fabric layer (R03) covers the tool gateway.
• Evaluation and red-teaming, which means attacking your own agent on purpose: the evaluate stage of the agent lifecycle.
• Runtime checks and containment: enforcement outside the model.
• Memory, context and data: memory permissions and lifecycle.
• Detection, investigation and recovery: the observability and FinOps layer (R12).
• OWASP mapped to controls: the security and identity layer (R10).

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

Threat-model one agentic workflow. Then score the agent on the risk profile.

Explore this topic

• NIST CAISI: Strengthening AI agent hijacking evaluations, January 2025
• OWASP Top 10 for Agentic Applications, December 2025
• MITRE ATLAS, accessed August 2026
• AgentDojo, NeurIPS 2024
• The architecture these practices rest on: the target-state architecture, the deterministic zones, the delegation chain, enforcement outside the model, the autonomy contract, security and identity (R10), governance, risk and sovereignty (R11) and observability and FinOps (R12)