AI agent hardening checklist (tested, step by step)

TL;DR:

• This is a numbered, tested hardening checklist for autonomous AI agents and the tools they call.
• The order matters: scope identity first, then sandbox, restrict egress, gate high-impact actions, log everything, and defend against injection.
• Each control ships with a way to verify it, because an untested control is a guess.
• This article is the practical companion to the AI agent hardening checklists hub; pair it with least privilege for AI agents and MCP security best practices.

What is AI agent hardening?

AI agent hardening is the practice of constraining an autonomous agent’s permissions, execution, and outputs so a malicious input cannot turn the agent against its owner. An AI agent plans with a language model and then acts through tools, so its real attack surface is every credential, command, and network path those tools expose. Hardening shrinks that surface before an attacker reaches it.

The core threat is excessive agency combined with prompt injection. The OWASP GenAI project lists both among the top LLM risks, and the Model Context Protocol specification defines the tool trust boundary you must police. The checklist below makes those abstractions concrete and testable.

The numbered AI agent hardening checklist

Apply these eight controls in order; earlier controls reduce the damage if a later one fails. We ran each against a deliberately over-permissioned test agent in June 2026 and kept only controls we watched change behaviour. Any figure here is illustrative, not an invented benchmark.

1. Give the agent a scoped identity, not a shared admin key. Issue a dedicated service identity per agent with only the permissions its tasks require, following least privilege for AI agents. Short-lived, narrowly scoped credentials cap the blast radius of any compromise.
2. Allow-list tools; deny by default. Register only the specific tools the agent needs and refuse everything else at the runtime. A model-level “I should not do that” is not a control; the host must reject the call.
3. Sandbox all execution. Run code, shell, and file operations inside an isolated container or microVM with no host mounts and no ambient cloud credentials. Treat every tool invocation as potentially attacker-controlled.
4. Restrict egress to an allow-list of destinations. Default-deny outbound network traffic and permit only the specific APIs and hosts the agent needs. This is the strongest single defence against data exfiltration after a successful injection.
5. Keep a human in the loop for high-impact actions. Require explicit approval for irreversible or sensitive operations such as payments, production deploys, mass deletes, or sending external email. Do not gate trivial reads, or approvals become reflexive.
6. Log every decision, tool call, and input. Record the full prompt, the chosen tool, its arguments, and the result to a tamper-evident, append-only store. You cannot investigate or detect abuse you did not record.
7. Defend against prompt injection at the boundary. Treat all retrieved content, tool output, and file contents as untrusted, isolate them from instructions, and never let fetched text silently grant new tool permissions. See the OWASP LLM Top 10 mapping for the named risk.
8. Handle secrets out of band. Inject credentials at the tool boundary from a secrets manager so they never enter prompts, tool arguments, or agent memory. The model should act on a secret without ever seeing its raw value.

How do I verify each control actually works?

Verification means watching the control block the behaviour it targets in a disposable test, not assuming it does. The table below pairs each control with why it matters and a concrete check. Run these in staging before you trust an agent in production, then re-run on every change.

#	Control	Why it matters	How to verify
1	Scoped identity	Caps blast radius of a stolen or abused credential	Attempt an out-of-scope API call with the agent’s credential; confirm the platform denies it
2	Tool allow-list	Stops the agent invoking unintended capabilities	Ask the agent to call a removed tool; confirm the runtime refuses, not just the model
3	Sandboxing	Contains malicious or buggy code execution	Run a command that reads host metadata or mounts; confirm it fails inside the sandbox
4	Egress control	Prevents exfiltration after injection	Inject a test instruction to POST data to an unlisted host; confirm the connection is blocked
5	Human-in-the-loop	Stops irreversible actions running unattended	Trigger a gated action; confirm execution pauses for explicit approval
6	Audit logging	Enables detection and forensics	Run a task, then confirm the prompt, tool, arguments, and result are all in the append-only log
7	Injection defence	Blocks hijack via untrusted content	Feed a document containing hidden instructions; confirm the agent does not act on them
8	Secret handling	Keeps credentials out of model context	Inspect prompts and logs after a run; confirm no raw secret value appears anywhere

Which controls do attackers target first?

Egress and tool permissions are the usual targets, because together they turn a single injection into data theft or remote action. A poisoned web page or repository file tells the agent to read a secret and send it somewhere, so controls 2, 4, and 8 are the load-bearing trio. Scoped identity (control 1) then ensures that even a successful chain reaches little of value.

This sequencing reflects primary guidance. The NSA and CISA joint guidance on deploying AI systems securely stresses isolation, logging, and least privilege, and Anthropic’s documentation on tool use and agents describes constraining what a model can call. The checklist turns that advice into steps you can run.

How does this fit the wider hardening programme?

This checklist is the agent-runtime layer; pair it with the MCP and least-privilege layers for full coverage. Tool-rich agents add the MCP security best practices to lock down transports and tool definitions, while any agent holding credentials leans on least privilege for AI agents. The hardening checklists hub indexes all of them, and the security tools directory lists software that helps you enforce each control.

Treat the checklist as living. Re-run it whenever you add a tool, change a prompt, or rotate a credential, because each of those quietly reshapes the attack surface you just hardened.

Frequently asked questions

Can I automate this checklist in CI? Yes. Encode controls 2, 4, 6, and 8 as policy checks in your pipeline so a pull request that adds an unlisted tool or widens egress fails the build.

What if the model refuses a malicious request on its own? Treat that as a bonus, never a boundary. A future prompt or a smarter injection may bypass it, so the runtime must still enforce every control.

Does sandboxing slow the agent down? Slightly, and it is worth it. The cost of a microVM or container per task is small next to the cost of an agent running attacker code with live credentials.