Threat-modeling the agentic stack in one page

Securing AI Agents in Production: A Practical Checklist

The deployment checklist compresses from a threat model that fits on one page, and stating it that way serves the teams who need to brief it upward. The assets: tool credentials, agent sessions, model context, and the instruction set itself. The adversaries: injected content (arriving through retrieved data, tool outputs, and the [poisoned-description channel](#)), compromised infrastructure (the MCP servers and runtimes the agents depend on), confused deputies (legitimate agents following attacker-influenced instructions into legitimate actions), and the persistence class (agents re-hijacked through surviving context and configuration, the [AutoJack lineage](#)).

The mapping from adversaries to controls is the checklist in causal form: injection meets content-marking and context separation; infrastructure compromise meets sandboxing and egress control; confused deputies meet the resolved-parameter confirmation gate; persistence meets configuration-integrity monitoring and session revocation. Every control in the seven-point program answers a named adversary on this page, and the briefing version for leadership is one sentence per row: this is what we hold, this is who wants it, this is how each path is closed. The one-pager earns its keep in the design review, the incident review, and the audit — the three rooms where agentic security is actually decided.

The page closes with its maintenance clause: the adversary column grows with every capability the agents gain, so the page reviews at every tool-grant expansion rather than on a calendar — the [prompts-as-code discipline](#) applied to the threat model itself. The teams that keep the page current hold the model; the teams that wrote it once hold a snapshot of a system that no longer exists; and the difference, in the agent era specifically, is measured in the speed at which snapshots rot. One page, four adversaries, seven controls, and a review trigger attached to growth: the whole program, briefcase-sized, ready for the rooms where it matters.

A year ago, AI agents were demo-ware: cute videos of an assistant “booking your flight.” In 2026 they’re in production — reading tickets, writing code, calling APIs, moving money between systems. And with real deployments came real incidents: agents exfiltrating data through tool calls, prompt injection hijacking an agent’s instructions, an MCP server with a poisoned tool description turning a coding assistant into an insider threat.

This post is the checklist I wish someone had handed me before putting agents into production. It assumes you’ve already read our primers on prompt injection in 2026 and MCP security — here we’re focused on deployment practice.

The Core Mental Model: Your Agent Is an Untrusted Insider

The single most useful reframing: treat every LLM agent like a well-meaning contractor with amnesia who reads everything you show them and follows instructions from anywhere.

• It reads untrusted content (web pages, emails, documents, tool outputs) and treats those as instructions.
• It holds real credentials to real systems.
• It acts faster than any human reviewer can watch.

Most agent security failures are failures of that model: someone gave the amnesiac contractor domain admin and pointed them at the internet.

The Checklist

1. Least-privilege tool access — scoped per tool, not per agent

Don’t give the agent one big API token. Break capability into narrow tools:

• ❌ run_database_query(sql) with a production DSN
• ✅ get_order_status(order_id), issue_refund(order_id, amount) — each a thin wrapper with server-side validation, fixed schemas, and its own scoped credential

Every tool should be answerable to: what’s the worst this can do if fully hijacked? If the answer is “everything,” split it.

2. Human-in-the-loop for destructive and outward-facing actions

Auto-approve reads; gate writes. Specifically require human confirmation for:

• Anything that spends money, sends external messages, or modifies production data
• Credential/permission changes (including the agent modifying its own tools — a classic prompt-injection escalation path)
• Bulk operations, even “safe” ones — a loop with a hijacked condition is a wrecking ball

The confirmation UI must show the actual resolved parameters, not the agent’s summary of them. Agents that narrate “I’m just updating the customer’s address” while the tool call deletes records are a real, observed failure mode.

3. Sandbox the agent’s execution environment

• Run code-execution tools in ephemeral, network-restricted containers (no IMDS endpoint, no internal DNS, egress allow-list).
• Give file-system tools a scratch directory, not a home directory with .ssh and .aws in it.
• Treat MCP servers as untrusted code: run third-party servers in isolation, pin versions, and review tool descriptions — they’re injected into your model’s context and are a proven injection vector.

4. Separate data planes: never mix untrusted content with privileged context

The deadliest agent architecture is one context window where untrusted web content sits next to your internal documents and live credentials. Injection in the untrusted stream then commands actions in the privileged stream.

Mitigations, in order of strength:

1. Don’t mix: separate summarizer agent (reads web) vs. actor agent (holds tools), communicating through validated structured messages.
2. Mark and wrap: clearly delimit untrusted content and instruct the model never to follow instructions inside it (helps, not guarantees — this is mitigation, not defense).
3. Strip tools from read-only phases: an agent that can’t call tools can’t be weaponized mid-read.

5. Log agent decisions, not just agent actions

When something goes wrong, “what did the model call” isn’t enough. Persist:

• Full tool call arguments and results
• The model’s stated reasoning and the instruction set (system prompt version) in effect
• Which content sources were in context at decision time

These logs turn a mysterious incident into a one-hour post-mortem. They’re also becoming an audit requirement as agentic AI lands in regulated processes — see our coverage of the OWASP Agentic Skills Top 10 for where the standards are heading.

6. Rate-limit and budget everything

Agents fail fast and expensively. Set hard ceilings on:

• Tool calls per task (stops injection-driven loops)
• Spend per task (stops runaway token and API bills)
• Wall-clock time per task

A hijacked agent that can only make 20 calls and spend $2 is an incident report; one without limits is a headline.

7. Plan for the supply chain

Your agent’s brain is a model you don’t control, its hands are MCP servers and libraries from wherever, and its memory is a vector store fed by whoever. Pin and review all three. The XZ backdoor showed how patient upstream compromise works; agent stacks multiply that surface. For a broader treatment, see our software supply chain security guide.

What I’d Tell You to Do First

If you do only three things this week:

1. Inventory every credential your agents hold, and cut each one down to the narrowest scope that still works.
2. Add human confirmation to every irreversible tool — it’s the cheapest control with the biggest blast-radius reduction.
3. Turn on full tool-call logging with parameters, before you need it.

The Bottom Line

Agent security isn’t a new science — it’s the old science (least privilege, isolation, auditability, fail-safe defaults) applied to a component that reads instructions from its data. The teams doing it well aren’t the ones with magic prompt shields; they’re the ones who assumed the agent would be hijacked on day one and built so that it barely mattered.

This post is part of our AI security series. Continue with Prompt Injection in 2026, MCP security, and the OWASP Agentic Skills Top 10 walkthroughs, or check out our security services for an agent architecture review.

The checklist at deployment scale

Turning the seven-point checklist into a deployment program: the sequencing that mature teams converged on treats credential scoping as the first deliverable (the tool-by-tool credential inventory, each scoped to its minimum — the item with the highest blast-radius reduction per engineering day), human-in-the-loop gating second (the irreversible-action confirmation layer, with the resolved-parameter display the [deepfake-era](#) interface lessons demand — because the human confirming a hijacked agent request needs to see the actual parameters, not the narration), and sandboxing plus context separation as the architectural workstream that ships behind them. Logging and rate-limiting arrive as configuration defaults rather than projects, which is the maturity marker: the checklist absorbed into the platform rather than executed against it.

The governance layer that deployments discover they need: an agent-change process (agent instruction sets, tool grants, and model versions change the system behavior the way code changes do, and the review discipline that treats prompts-as-code prevents the quiet drift that turns a hardened deployment soft), and an incident-response chapter for agent compromise (session revocation at the tool layer, context preservation for forensics, credential rotation for the tool inventory — the [agent-IR extensions](#) this canon assigns). The deployments that skipped the governance layer discovered it during their first behavioral incident; the record prices the discovery at the usual rate.

The closing economics: agent security is an architecture cost paid once, against an attack-surface class that compounds with every tool, integration, and model capability added. The checklist items are each individually cheap; the expensive version is the absence, priced in the incident classes this series documents at every layer — and the agent layer, being the newest and least battle-tested, inherits the record oldest lesson at its freshest: everything old is new again, deployed faster, holding credentials, reading instructions from its data. The checklist is short because the doctrine is old; the deployment is careful because the record is long.

Frequently Asked Questions