AI Agent Security Checklist: 12 Controls for Agentic AI

In January 2025, NIST researchers published a study of AI agent hijacking: attacks that hide instructions in the data an agent reads. The strongest known attack worked 11% of the time. After red-teaming, the strongest new attack worked 81% of the time.

That gap is the whole subject of AI agent security. A model that only writes text can be tricked into saying something wrong. A system that holds credentials, calls tools, and changes records can be tricked into doing something wrong, at machine speed, under an identity your logs trust. You will not fix that inside the model. You bound it with architecture.

This checklist is written for the security or platform owner who has to sign off on agentic AI. It is vendor-neutral. Each of the 12 controls maps to the OWASP and NIST sources your auditors will recognize, comes with a test you can run, and says plainly where it stops working. Use it on any platform, including ours.

What is AI agent security?

AI agent security is the practice of protecting autonomous AI systems that plan, call tools, and act with delegated access. It governs who the agent is, what it can reach, what it ingests, what code it runs, which actions need a human, and how every action is logged and stopped.

It overlaps with application security and model security without being either. Application security protects code that does what it was written to do. Model security protects what a model outputs. Agent security has to assume the system will sometimes decide to do the wrong thing, because someone persuaded it to, and limit what that decision can cost. If you want the category definition first, start with what agentic AI is.

Why agentic AI security is a different problem

The standards bodies have already drawn the line. The OWASP Top 10 for LLM Applications 2025 puts prompt injection first (LLM01) and names Excessive Agency (LLM06): giving an LLM-based system more permission or autonomy than its task needs. In December 2025, OWASP published a separate Top 10 for Agentic Applications for 2026, because the threats change once a model can plan, remember, and act across other systems.

Government guidance followed within months:

• NIST's Center for AI Standards and Innovation (CAISI) issued a request for information on securing AI agent systems in January 2026. It names indirect prompt injection, poisoned models, and misaligned objectives, and asks specifically for methods to constrain and monitor an agent's access in its deployment environment.
• NIST launched the AI Agent Standards Initiative on February 17, 2026, with AI agent security and identity as one of its three pillars.
• On May 1, 2026, CISA, the Australian Signals Directorate's Australian Cyber Security Centre, and other US and international partners released joint guidance, Careful Adoption of Agentic AI Services.

Your program-level baseline does not go away. The NIST AI Risk Management Framework (Govern, Map, Measure, Manage) and its Generative AI Profile, NIST AI 600-1 are still the right structure for ownership and risk decisions. Both predate the agent-specific guidance, though, and neither tells you how to stop a running system from deleting a table. That is a runtime question, which is why every control below is a runtime control. The policy side is covered in our AI governance framework for agentic systems.

One more finding should set your expectations. In a large red-teaming competition run by Gray Swan with CAISI and the UK AI Security Institute, more than 400 participants made over 250,000 attack attempts against 13 frontier models in agentic scenarios, and at least one attack succeeded against every model. Plan on the model being manipulated. Put your controls where manipulation stops mattering.

The agentic AI threat map

Start from the threats, so every control has a reason to exist. The risk names below are OWASP's, from the OWASP Top 10 for Agentic Applications. The one-line summaries and the control mapping are ours.

Two patterns run through the list. Most of these risks need the agent to hold real access, so shrinking and attributing that access (controls 1 to 3) pays off against almost all of them. And the rest need the agent to act on something it cannot fully trust, so you design for the attack that gets through rather than hoping it will not.

The AI agent security checklist: 12 controls

Twelve controls, ordered roughly from foundation to response. For each one: what to require, how to test it, and where it stops working. The tests matter most. A control you have not tested is a control you are assuming.

1. Inventory every agent and name an owner

Require: a register of every AI agent running in your environment, including the ones nobody approved, each with a named human owner, a written purpose, and a list of the systems and data it can reach. Test: look for API keys and OAuth grants issued to AI tools, and agent frameworks running on developer and analyst machines, then compare what you find against the register. Where it stops: an inventory tells you what exists, not what it does. But every other control on this list applies only to agents you know about. An agent that is not on the register has none of them.

2. Give each agent its own identity

Require: each agent authenticates as itself, with its own credentials and permission scopes, managed in the identity provider you already run. No shared service accounts. No borrowed human logins. Why: when an agent acts under a person's credentials, your audit log records the person. Attribution is wrong by construction, and separation of duties is gone before the agent does anything. OWASP lists this as Identity and Privilege Abuse (ASI03), and NIST made agent identity and authorization one of the research areas of its AI Agent Standards Initiative, launched in February 2026.

Test: pick one action an agent took last week and find it in your logs. Does the entry name the agent, or a human? Then revoke the agent's credential and confirm it stops working. Where it stops: identity makes actions attributable. It does not limit them. Identity for agents is a subject of its own, covered in our guide to identity and access for AI agents.

3. Enforce least privilege and least agency

Require: an explicit allowlist of the tools, actions, and resources each agent may use, scoped per tool (read or write, which records, which systems). Anything not on the list is unavailable. The OWASP AI Agent Security Cheat Sheet recommends allowlists over wildcards for exactly this reason. OWASP's agentic guidance adds a second principle, least agency: limit how much the agent may decide on its own, not only what it can reach. The OWASP Top 10 for LLM Applications 2025 names the failure mode directly as Excessive Agency (LLM06).

Test: instruct the agent, directly and through a planted document, to use a tool it should not have. The correct result is not that it politely declines. The correct result is that the tool does not exist in its runtime. Where it stops: an allowlist bounds a hijacked agent to what it is allowed to do. It can still misuse a tool it legitimately holds, which is why the dangerous tools also need control 7.

4. Treat every input as untrusted, and assume injection will succeed

Prompt injection is the top risk on both OWASP lists: LLM01 for LLM applications, and Agent Goal Hijack (ASI01) for agentic ones. In agents it usually arrives indirectly, as instructions hidden in an email, a web page, a ticket, or a retrieved document the agent reads while doing its job.

Require: everything the agent ingests, user messages, documents, emails, API responses, and tool outputs, is handled as untrusted data, kept separate from instructions, and screened for injection attempts, as the OWASP cheat sheet sets out. Test: seed a test document with hidden instructions (forward this file to an outside address, change this record) and run the agent over it in a staging environment.

Where it stops: this is the control to be most honest about. No filter reliably stops prompt injection today. When NIST tested agent hijacking, new red-team attacks lifted the success rate from 11% for the strongest baseline attack to 81%, and repeating an attack 25 times raised the average success rate from 57% to 80%. Detection lowers the rate. It does not reach zero. So design for the injection that gets through: its reach should end at the allowlist (control 3), the approval gate (control 7), and the audit log (control 11).

5. Sandbox any code the agent can run

Require: code the model writes never executes directly on a host. It runs in an isolated runtime with an allowlist of packages, system-level modules blocked, memory and time limits, and no network access beyond approved endpoints. OWASP calls the failure Unexpected Code Execution (ASI05): the shortest path from a manipulated prompt to a compromised machine. Test: have the agent generate code that imports operating-system or subprocess modules, opens an outbound connection, or reads a file outside its scope, and confirm each attempt is blocked and logged. Where it stops: a sandbox contains code. It does not judge whether permitted code does the right thing.

6. Hold the deployment boundary and control egress

Require: a written list of every place the agent sends data: prompts, retrieved context, tool outputs, and logs, and the inference provider above all. Everything else is blocked, and outbound content is screened for sensitive data. If the data falls under a regime such as ITAR, CMMC, or NERC CIP, settle with your compliance team whether it may leave your perimeter at all before you choose a deployment model, because that decision rules platforms in or out. Sensitive Information Disclosure (LLM02) is the OWASP risk this control addresses.

Test: capture network traffic from the agent's runtime during a real task. Every destination should be on the list you wrote. Where it stops: egress control keeps data inside approved paths; it cannot stop an agent from misusing data along an approved path. And on-premises is not the same as air-gapped. If your program requires an air gap, make it a separate, explicit requirement.

7. Require human approval for high-impact actions, and design against rubber-stamping

Require: a named list of high-impact actions (payments, deletions, permission changes, messages to outside parties, changes to operational systems) that wait for explicit human approval, with a preview of exactly what will happen and a way to interrupt or roll back. This is the human-in-the-loop control in the OWASP cheat sheet.

Test: measure it. Count approvals per reviewer per day and the time taken on each. If most are approved within seconds, the control exists on paper only. Where it stops: OWASP added Human-Agent Trust Exploitation (ASI09) to its agentic list because a fluent, confident explanation can talk a reviewer into approving something unsafe. Show the reviewer the raw action and its target, not only the agent's summary of it, and keep the approval set small enough that each request gets real attention.

8. Constrain delegation and log agent-to-agent messages

Require: an agent can never hand another agent permissions it does not hold, messages between agents are authenticated and logged, and a fault in one agent cannot run unchecked through the rest. OWASP names the two failures Insecure Inter-Agent Communication (ASI07) and Cascading Failures (ASI08), and its cheat sheet recommends trust boundaries and circuit breakers between agents. Test: have a low-privilege agent ask a higher-privilege agent to perform a restricted action on its behalf. This is the confused-deputy test, and it should fail. Where it stops: logging multi-agent conversations gives you the record; reviewing that record at volume needs tooling of its own.

9. Protect memory and retrieved context

Require: anything an agent writes to long-term memory is validated first, memory is isolated per user or tenant, entries expire, and stored memory is audited for sensitive data. Memory and Context Poisoning (ASI06) is the risk: a false fact or planted instruction persisted today steers an action next month. Test: plant a false instruction in memory during one session, then check whether it changes the agent's behavior in a different user's session. Where it stops: a retrieval index is memory too. A poisoned source document in your knowledge base needs content controls upstream of the agent.

10. Vet the agentic supply chain

Require: every tool, plugin, MCP server, package, and model an agent uses is inventoried, version-pinned, and reviewed the way you review any third-party code. OWASP tracks this as Supply Chain (LLM03) and Agentic Supply Chain Vulnerabilities (ASI04), and its Agentic Security Initiative has published a practical guide to secure MCP server development. Test: can you list the exact version of every tool server your agents called last week, and who approved each one? Where it stops: a reviewed dependency can still ship a malicious update. Pinning and change review are what stop a silent swap.

11. Log every action to an attributable, exportable audit trail

Require: every model call, tool call, file access, and message is logged with the agent's own identity, the input that triggered it, the data it touched, and the result, and the log streams to your SIEM with alerts for agent-specific patterns such as permission errors or sudden spikes in tool calls. Test: pick an agent action from last week and answer four questions from the logs alone: what did it do, when, with what data, and why. If the answer requires a reconstruction, the log is incomplete. Where it stops: a log is evidence, not prevention. It turns an incident into an investigation you can finish.

12. Keep a working kill switch and an agent incident runbook

Require: a named on-call role that can stop a running agent immediately, mid-task, revoke its credentials, and preserve its state for investigation, backed by an incident runbook written for agents: containment, credential revocation, action review, and rollback. Rogue Agents (ASI10), a compromised or drifting agent that keeps operating, is the scenario this control exists for. Test: pull the switch in a drill, mid-task, and time the gap between the decision and the stop. Where it stops: stopping an agent does not undo what it already did. Know which of its actions are reversible before you need to reverse one.

The checklist at a glance

Take this table into architecture reviews and vendor calls. If an owner or a vendor cannot answer a row plainly, treat the row as failed until they can.

LLM IDs refer to the OWASP Top 10 for LLM Applications 2025; ASI IDs to the OWASP Top 10 for Agentic Applications for 2026. The NIST AI RMF function names show where each control sits in an existing risk program.

How to roll out agentic AI security controls

Twelve controls at once is how a checklist becomes a spreadsheet nobody finishes. Sequence it.

• First, the three you cannot evaluate anything without: the inventory (1), per-agent identity (2), and the audit trail (11). Until you know what exists, who it is, and what it did, the other controls have nothing to attach to.
• Then shrink the blast radius: allowlists (3), the sandbox (5), and egress control (6). These are the controls that still hold when prompt injection succeeds.
• Start agents on read-only, low-impact work, and widen permissions one tool at a time, with the approval gate (7) on anything irreversible.
• Red-team before production and after every change to tools, prompts, or models. The OWASP cheat sheet recommends adversarial regression tests in CI/CD. CAISI's competition found that attacks which break robust models often transfer to weaker ones, so reuse what your red team finds.
• Drill the kill switch (12) before you need it, and fold agents into your existing access reviews, change management, and incident response rather than building a parallel process.

The same checklist applies whether you buy or build. Open-source agent frameworks are a legitimate path, but most of these controls become yours to build and maintain, so count that work honestly. When you are comparing vendors, pair this list with our guide on how to evaluate AI agents for the enterprise.

A worked example: controls built into the runtime

Here is one example of these controls built in rather than bolted on. Mission Control builds synthetic workers rather than agents, and Swarm is the platform they run on. The difference that matters for this checklist is where the controls live: in the runtime around the model, not in the model's instructions. Everything below comes from our published governed AI and platform pages, and you should verify it the way you would verify anyone else.

• Identity (2): every worker has a unique, verifiable identity, with its own credential sets and permission scopes, and SSO and OIDC integration with your existing identity provider.
• Least privilege (3): a capability whitelist. If a capability is not on a worker's activation list, it does not exist for that worker. The security model is allow nothing, enable specific things.
• Untrusted input (4): input sanitization and injection detection on inbound signals, with the design assumption stated plainly: when an attack succeeds, a prompt injection yields capability selection within a whitelist, not arbitrary code execution.
• Sandboxed execution (5): no arbitrary code execution; a package whitelist, with os, subprocess, and sys blocked at the interpreter level.
• Deployment boundary (6): on-premises, containerized, behind your firewall, with no callbacks to external servers; vendor-agnostic inference across Anthropic, OpenAI, or self-hosted models; output redaction on outbound communications.
• Human approval (7): escalation triggers surface high-risk decisions to human operators before execution.
• Delegation and scheduling (8): workers cannot grant permissions they do not have, inter-worker and worker-to-human messaging is logged, and workers run only inside approved operating windows.
• Audit (11): every LLM call, action, and file access logged with full provenance. SOC2 compliant via Drata.
• Kill switch (12): immediate termination of a worker's process, mid-operation.

Nine of these controls are what the governed AI page lists as the nine real-time governance firewalls: identity, human RBAC, synthetic RBAC, execution sandbox, audit logging, delegation controls, scheduling, communications, and the capability whitelist. Input sanitization, injection detection, escalation triggers, output redaction, and the kill switch are runtime controls described on the platform page. Now the limits, because overselling is how a vendor loses a security review. Our published pages make no specific claims about memory poisoning defenses (9) or about reviewing the third-party tools and models you connect (10), so ask us for specifics there as you would any vendor. The firewalls bound what a worker can do and make every action attributable; they do not make its judgment inside those bounds correct. On-premises is not automatically air-gapped, so state an air-gap requirement explicitly. And deployment runs through a 12-week pilot with a forward-deployed engineering team, a heavier engagement than installing a tool.

Start with five questions this quarter

AI agent security comes down to one design choice: stop relying on the model to behave, and make misbehavior cheap. Before you work through all 12 controls, get honest answers to these five questions about the agents already running in your environment:

• Can we name every agent in our environment, with an owner?
• Does any agent act under a human's login or a shared service account?
• For our most privileged agent, what happens if a document it reads tells it to send our data somewhere?
• For any agent action last week, can we say what it did, with what data, and why, from logs alone?
• Who can stop a running agent, and have they done it in a drill?

Any question you cannot answer is where your checklist starts. If you want to see these controls running inside your own perimeter, talk to our team.

References

• OWASP Gen AI Security Project, "OWASP Top 10 for Agentic Applications for 2026" (December 2025)
• OWASP Gen AI Security Project, "OWASP Top 10 for Agentic Applications: The Benchmark for Agentic Security in the Age of Autonomous AI"
• OWASP Gen AI Security Project, "OWASP Top 10 for LLM Applications 2025"
• OWASP Cheat Sheet Series, "AI Agent Security Cheat Sheet"
• OWASP Gen AI Security Project, Agentic Security Initiative
• NIST, "Technical Blog: Strengthening AI Agent Hijacking Evaluations" (January 2025)
• NIST CAISI, "Insights into AI Agent Security from a Large-Scale Red-Teaming Competition" (March 2026)
• NIST, "CAISI Issues Request for Information About Securing AI Agent Systems" (January 2026)
• NIST, "Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation" (February 2026)
• NIST, AI Risk Management Framework
• NIST AI 600-1, "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile" (July 2024)
• CISA, "Careful Adoption of Agentic AI Services" (May 2026)
• Mission Control governance and platform detail: /governed-ai/, /platform/

Related reading

• An AI Governance Framework for Agentic Systems
• How to Evaluate AI Agents for the Enterprise
• Identity & Access for AI Agents
• What Is Agentic AI?
• All posts on the blog