Blog / 31 October 2026

Deep dive · 31 October 2026 · 8 min read

The AI agent security checklist for 2026

Securing an AI agent comes down to four things: limit what it can reach, limit what it can spend, make what it breaks reversible, and be able to prove afterwards what it did. Here are 26 checks in eight areas. Each one is mapped to the OWASP Top 10 for LLM Applications 2025 (LLM01 to LLM10), the OWASP Top 10 for Agentic Applications 2026 (ASI01 to ASI10), or the MCP security best practices.

AI agent security checklistOWASP agentic top 10OWASP LLM top 10 2025MCP securityAI agent sandbox

01Isolation: where does the agent's code run?

An agent that reads untrusted text can be steered by it. That is prompt injection, LLM01, and its agent form, goal hijack, ASI01. You cannot filter every instruction out of a web page or an issue comment, so plan for some to get through and limit where they can act. For unexpected code execution (ASI05), OWASP's agentic list recommends sandboxed execution, never running as root, and limiting file access to a dedicated working directory.

Treat the sandbox as the outer wall. Every other check on this list narrows what can happen inside it.

Run agent-written and agent-downloaded code in a sandbox, never on a developer's host or a production server. Maps to ASI05 and LLM05.
Use a boundary with its own kernel (gVisor or a microVM) for code nobody reviewed. Keep shared-kernel containers for trusted code. Maps to ASI05 and ASI10.
Mount only the project directory, read-only where you can. Never mount the home directory, SSH keys or the Docker socket. Maps to ASI05 and LLM06.
Give each agent or session its own sandbox, clear it between tasks, and cap CPU, memory and run time. Maps to ASI03 and LLM10.

02Credentials and network: what can a hijacked agent reach?

Assume an agent will be hijacked at some point. What it can then do depends on the keys it holds and the hosts it can reach. OWASP's agentic list asks for short-lived, task-scoped credentials (ASI03), and for egress allowlists that deny every destination not approved (ASI02). The MCP security best practices add a warning about server-side request forgery (SSRF), where a client is tricked into requesting internal addresses such as 169.254.169.254, the cloud metadata endpoint.

Credentials and network work as a pair. A key the agent never holds cannot leak, and a host the agent cannot reach cannot receive anything.

Keep real API keys out of the sandbox. Have a proxy outside it add them to outgoing requests. Maps to LLM02 and ASI03.
Use short-lived tokens scoped to the task, not a developer's long-lived personal token. Maps to ASI03 and ASI02.
Give each agent its own identity, so logs and approvals name the agent rather than just 'an agent'. Maps to ASI03 and LLM06.
Have one command that revokes an agent's credentials and stops the agent. Maps to ASI10.
Deny egress by default, and allow only the hosts each task needs. Maps to ASI02.
Enforce the allow-list outside the sandbox, so root inside cannot lift it. Block private ranges and metadata endpoints. Maps to ASI02 and the MCP SSRF guidance.

03Tools, MCP servers and human approval

Excessive agency, LLM06, is the risk that an agent has more tools, more functions or more permissions than its task needs. OWASP's mitigations for it include keeping tools to the minimum, preferring granular tools over open-ended ones like a shell or URL fetch, enforcing authorization in downstream systems rather than leaving it to the model, and requiring a person to approve high-impact actions.

The MCP security best practices say a client must get the user's consent before it runs a local MCP server's command, and recommend running those servers in a sandbox with minimal privileges. They also say an MCP server must not accept tokens that were not issued for it. ASI09 warns about the human side of approval: people who approve too often start approving without reading.

Keep an inventory of every tool and MCP server, approve each one per team, and deny anything not on the list. Maps to LLM06 and ASI02.
Prefer narrow tools to a raw shell or open URL fetch. Maps to LLM06.
Run each third-party MCP server in its own sandbox with only the network access it needs. Maps to ASI04 and the MCP local-server guidance.
Pin tool definitions, and require a fresh approval when a description changes. Maps to ASI04 and ASI02.
Require human approval for deploys, deletes, payments and privilege changes, and show the exact call or a diff. Maps to LLM06, ASI02 and ASI09.
Require two named approvers for the riskiest actions, and keep the auto-approve list under version control. Maps to ASI05 and ASI09.

04Undo and state: can you put it back?

Even with approvals in place, some mistakes will get through. For memory and context poisoning (ASI06), OWASP lists snapshots, rollback and version control, and it advises against feeding an agent's own outputs straight back into trusted memory. For goal hijack, it advises regular red-team tests that check rollback actually works.

Undo also changes how you approve. When a step can be rolled back in seconds, fewer actions need a person to stop and read them.

Take a snapshot before every risky step, and test the restore regularly, not only on the day you need it. Maps to ASI06 and ASI01.
Keep agent changes in version control, and review diffs before they reach a shared branch or the host. Maps to ASI05.
Do not write agent output into long-term memory without review, and expire memory that nobody verified. Maps to ASI06.

05Audit and evidence: can you prove what happened?

After an incident, the first question is which agent did what, and who approved it. OWASP's agentic list asks for immutable logs of every tool invocation (ASI02), tamper-evident, time-stamped logs bound to agent identities (ASI08), and tamper-proof records of agent actions (ASI09). The MCP scope guidance adds that broad, catch-all scopes make audit trails harder to read.

Decide in advance who reads the log and how often. A log nobody checks will not reveal that someone tampered with it.

Log every tool call, egress decision and approval, and record whether a human or an agent acted, and which agent. Maps to ASI02 and ASI03.
Make the log tamper-evident, with a hash chain or append-only storage, and verify it on a schedule. Maps to ASI08 and ASI09.
Keep secrets, prompts and raw arguments out of the log by default, and store digests instead. Maps to LLM02.
Be able to export one agent's or one sandbox's record as a package an incident reviewer can check. Maps to ASI08.

06Supply chain: what did the agent install?

Agents install packages, pull images and load tools quickly, often from names they generated themselves. LLM03 and ASI04 both cover this risk. ASI04's mitigations include allowlisting and pinning dependencies, scanning for typosquats, keeping SBOMs and AIBOMs, pinning prompts and tools by content hash, and having a kill switch that disables a compromised component.

These checks belong in your build pipeline as much as in the agent's sandbox.

Pin dependencies with lockfiles, and only allow packages from approved registries. Maps to ASI04 and LLM03.
Check signatures and provenance, and keep an inventory of the models, prompts, tools and packages in use. Maps to ASI04 and LLM03.
Have a kill switch that disables a compromised tool, model or package everywhere at once. Maps to ASI04 and ASI10.

Takeaways

Assume prompt injection will sometimes succeed, and limit where it can act.
Keep real keys and an open network out of the agent's reach, and enforce both from outside the sandbox.
Treat every MCP server as code someone else wrote: sandbox it, pin its definitions, and limit its scopes.
Put a person in the loop for high-impact actions, and watch for approval fatigue.
Snapshots and a tamper-evident log turn an incident into something you can undo and explain.
Map each check to OWASP's LLM and agentic lists so reviewers can trace why it is there.

Where kosa8 fits

kosa8 provides controls for several of these checks. Each agent gets a microVM with its own kernel that sees one workspace folder. The network is closed except for an allow-list you write. API keys are injected on the host by an egress broker, so there are 0 real keys inside the sandbox. Third-party MCP servers can each run in their own sandbox behind one policy, and risky actions can wait for one or two named human approvers. A checkpoint saves the whole running machine and a rewind puts it back. Every action goes into a hash-chained, tamper-evident audit log marked human or agent. kosa8 does not replace dependency pinning, provenance checks or memory hygiene, which still belong in your own pipeline.

Check yourself · +100 XP

Which OWASP entry covers an agent having more tools, functions or permissions than its task needs?

Questions people ask

What should an AI agent security checklist include?

It should cover eight areas: isolation, credentials, network, tools and MCP servers, human approval, undo and state, audit and evidence, and supply chain. Each check should name the risk it addresses, for example in the OWASP Top 10 for LLM Applications 2025 or the OWASP Top 10 for Agentic Applications 2026.

What is the OWASP Top 10 for Agentic Applications?

It is a list from the OWASP GenAI Security Project, dated 9 December 2025. Its entries run from ASI01 (Agent Goal Hijack) to ASI10 (Rogue Agents), and they include Tool Misuse and Exploitation, Identity and Privilege Abuse, Agentic Supply Chain Vulnerabilities and Unexpected Code Execution. It builds on the OWASP Top 10 for LLM Applications rather than replacing it.

How do I secure MCP servers used by an AI agent?

Approve each server explicitly, and run local servers in a sandbox with minimal file and network access. Pin tool definitions, keep OAuth scopes small, and do not let a server accept tokens that were not issued for it, as the MCP security best practices require.

Sources

OWASP Top 10 for LLM Applications 2025 — OWASP GenAI Security Project
LLM06:2025 Excessive Agency — OWASP GenAI Security Project
OWASP Top 10 for Agentic Applications for 2026 — OWASP GenAI Security Project
Security Best Practices — Model Context Protocol specification
How do I run untrusted LLM-generated code safely? — kosa8 guides
How do I give an AI agent API keys without exposing them? — kosa8 guides
How do I limit an AI agent's network to an allow-list? — kosa8 guides
How do I run MCP servers in a sandbox? — kosa8 guides
Require human approval for risky AI agent commands — kosa8 guides
How do I undo what an AI coding agent did? — kosa8 guides

Written by the kosa8 team. Every kosa8 command was checked against the CLI, and every claim about another product links to that product's own documentation. Spotted a mistake? Tell us.