---
title: "Agentic AI Security Checklist: Twenty Questions to Answer Before Launch"
description: "Twenty pre-ship questions in five themes, covering authority, untrusted input, action gating, dependencies and response. Each one closes against evidence, not opinion."
author: "Renn Calloway"
category: "Defensive Architecture & Security Controls"
date: 2026-10-12T09:45:14.546Z
canonical: "https://agenticcyber.co/blog/agentic-ai-security-checklist-pre-deployment"
---

# Agentic AI Security Checklist: Twenty Questions to Answer Before Launch

![A security and privacy dashboard with its status](https://images.unsplash.com/photo-1751448555253-f39c06e29d82?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w4OTQwNjJ8MHwxfHNlYXJjaHwzfHxUaGUlMjBBZ2VudGljJTIwQUklMjBTZWN1cml0eSUyMENoZWNrbGlzdCUyMHR3ZW50eSUyMHllc29ybm8lMjBxdWVzdGlvbnN8ZW58MXwwfHx8MTc5MTc5NTczNXww&ixlib=rb-4.1.0&q=75&w=1200&auto=format)

> Twenty pre-ship questions in five themes, covering authority, untrusted input, action gating, dependencies and response. Each one closes against evidence, not opinion.

The build works end to end. A launch date is already on the calendar. Then somebody asks whether it is safe to put in front of customers, and the answer turns into a discussion instead of a document.

What follows is the document. Twenty questions in five themes, each one answerable with something you can point at: a configuration value, a log query, a passing test, a merged diff. The list certifies nothing. It tells you which decisions nobody has made yet, and the decisions nobody made are where the expensive incidents start.

## What This List Settles, and What It Only Exposes

No questionnaire proves an agent is safe. This one does something narrower and more useful: it turns quiet assumptions into written answers, and every written answer either names evidence or becomes a ticket. Treat an honest "probably" as a no. The ambiguity is the finding.

## Why an Agent Review Is Not a Code Review

A conventional service executes paths a reviewer read before merge. An agent assembles its next move at runtime out of text, and some of that text arrives from people outside your trust boundary. So the review question moves from what the code does to what the system can be talked into doing with the authority it holds. The UK NCSC puts the designer's goal as working to "reduce the risk and the impact" of prompt injection, on the reasoning that complete mitigation may never arrive; the argument is laid out in its post on [why prompt injection is not SQL injection](https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection). A pre-ship list written for that world spends most of its questions on blast radius rather than on filtering.

One constraint organises the themes below. Meta's security team published a rule it calls the [Agents Rule of Two](https://ai.meta.com/blog/practical-ai-agent-security/), which holds that a session should carry at most two of three traits: it reads input you do not control, it touches private data or sensitive systems, or it mutates state and talks to the outside world. Several questions test which pair you have deliberately accepted, and which third one you are quietly allowing as well.

## Theme One: Who the Agent Is and What It May Hold

Authority comes first, because every control further down inherits it.

- Can you name the principal the agent authenticates as, and is it distinct from any human account and from any key a team shares?

- Do its credentials expire on a short clock, and does each one unlock only the tools that principal actually calls?

- Is there a written inventory of callable tools, with the most damaging legitimate call noted beside each entry?

- Have broad grants been narrowed to named operations? The Model Context Protocol maintainers warn that "Poor scope design increases token compromise impact, elevates user friction, and obscures audit trails" in the project's [security best practices](https://modelcontextprotocol.io/specification/draft/basic/security_best_practices).

Evidence that closes this theme: an identity provider record for the agent itself, the token lifetime in configuration, the tool inventory under version control, and a diff showing which grants went away.

## Theme Two: Every Channel an Outsider Can Write Into

The second theme is an enumeration exercise, and teams almost always finish it with a longer list than they expected.

- Can you name every channel that delivers the agent text an outsider could have authored, including ticket bodies, calendar invitations, scraped pages, attachments and tool responses?

- Does a session that reads attacker-reachable content run stripped of the privileges that would make an injected instruction worth sending?

- Does the surface rendering agent output refuse to fetch remote assets or follow links on its own?

- Does each retrieved document and tool result arrive tagged with its origin, in a field your logs actually keep?

The failure mode worth studying here is instruction text that survives a handoff between components, which is covered at defender level in [how adversarial instructions cross agent boundaries](/how-adversarial-instructions-cross-agent-boundaries).

## Theme Three: The Gap Between a Decision and Its Effect

A model proposes. Something else has to decide whether the proposal executes.

- Does code outside the model check each tool call against a schema, an allowlist and an upper bound before it runs?

- Does an action with no reverse, meaning a payment, a deletion, an outbound message or a deployment, wait for a person who sees the literal arguments and not the model's description of them?

- Does generated code execute somewhere with no outbound network route by default?

- Is there a ceiling on spend, call rate and step depth that trips before a loop becomes an invoice?

Isolation is the control most teams defer and most regret deferring; [sandboxing agent tool calls](/sandboxing-ai-agent-tool-calls-an-isolation-architecture) sets out an architecture worth copying.

## Theme Four: Code and Servers You Did Not Write

An agent inherits the trustworthiness of everything it loads, and most of that arrives from strangers.

- Are MCP servers, plugins, skills and packages held at versions a named person has read?

- Does a version bump travel through review instead of landing overnight?

- Do your MCP servers check the audience claim on an incoming token and decline to pass it onward?

- Have you compared your framework and runtime versions against current vendor advisories?

Audience validation is the subtle item and the one an attacker reaches for. A server that accepts a token minted for somebody else becomes a deputy for whoever asks, which is the mechanism in [MCP authorization and the confused deputy problem](/mcp-server-authorization-token-audience-confused-deputy).

## Theme Five: Noticing It, Stopping It, Having Practised It

The last four questions decide how long a bad session lasts.

- Does every tool call reach a log that carries the agent identity and the task that triggered it?

- Are you alerted when a call is refused, when a call sequence falls outside the usual shape, and when volume shifts suddenly?

- Can you take a single agent offline and invalidate its credentials within minutes, without shipping a release?

- Has anyone walked a fabricated agent incident through the response runbook, with the people who would actually be paged?

Those signals exist only if somebody built them, and [runtime monitoring for AI agents](/runtime-monitoring-for-ai-agents) describes the telemetry that makes the last four answers possible at all.

## Reading the Answers Without Totalling Them

Resist the urge to score it. Look for clusters instead: three or more negatives inside one theme means the area needs design attention, not a ticket. A negative on the tool inventory, on validation outside the model, on human approval for irreversible actions, or on the ability to switch the agent off should hold a launch for any system touching regulated data or able to act without a reverse. Have the build team answer the list, then hand it to a reviewer with no stake in the launch date, and read the disagreements first: they mark where the design lives in one person's head and nowhere else.

Notice what the list never asks. It asks nothing about whether the model is aligned or inherently well behaved. Those belong to whoever trains it. Yours concern the enclosure around it: what the system can reach, what it can emit, and who holds the switch. Those answers set how large the incident gets on the day a model is fooled.

## Open Items Need an Owner and a Date

A list with no names attached decays into a page nobody opens. Give every unresolved item one owner and one date, and keep it in the tracker that already holds the rest of the launch work. Close an item only against evidence: a merged configuration change, a green test, a log query returning the rows you expected, a screenshot of a limit refusing a call. A conversation is not evidence.

Two agents make the point. A summariser that reads public pages for a research team consumes hostile text all day, holds nothing private and cannot act, so it fails a handful of items and each failure is cheap: pin the browsing tool, log the calls, tag the sources. An agent that works the support inbox, reads customer records and books refunds carries all three traits at once, so Themes One and Three decide whether it ships. It needs its own principal, a refund ceiling enforced in code rather than in a prompt, and an approval screen showing the amount and the destination account. Both ship with items still open. The difference: one set sits in a backlog, the other sits on a gate.

## Map the Questions to a Published Taxonomy Before Anyone Argues About Them

A list written inside one company reads as one engineer's preferences. Hanging it off published work removes that objection and finds your blind spots. The OWASP GenAI Security Project published [the Top 10 for Agentic Applications for 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications/) on 9 December 2025, aimed at what it calls the most critical security risks in autonomous and agentic systems, with the numbered categories inside the downloadable document. Its companion, [Agentic AI: Threats and Mitigations](https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/) from the project's Agentic Security Initiative, is dated 17 February 2025 and is the threat-model reference the category list sits on top of.

The exercise takes an afternoon. Write the category identifier from the Top 10 beside each of the twenty questions, then look for categories with no question against them. That empty cell is the honest output, and an outside reviewer will find it first if you do not. It also gives you a vocabulary that travels further than "Theme Three".

## Run a Scanner, and Know Which Layer It Tested

There is a free tool worth running before launch, with an honest limit attached. [garak](https://github.com/NVIDIA/garak), maintained in NVIDIA's GitHub organisation under the Apache-2.0 licence, is a vulnerability scanner for language models, installed with a single pip command and free to use by its own description. Its probe families include prompt injection, package hallucination, encoding tricks, training-data replay and scripting payloads in model output, which maps onto questions in Themes Two and Four.

Now the limit, which decides what the result is worth. Its documentation describes probing a model and claims no coverage of agents or tool use. A clean run says something real about the model layer and nothing about whether your tool allowlist holds, whether an approval screen shows literal arguments, or whether a ceiling is enforced in code. File it against the model-layer questions and leave the rest unanswered.

Two platform controls are worth a direct look while you are in Theme Four, because they changed recently in at least one shipping agent. Claude Code's [security documentation](https://code.claude.com/docs/en/security) describes managed MCP configuration, which lets an organisation restrict which servers a session may load at all, and a configuration-change hook that can audit or block settings edits made during a session. The second one closes a gap this list would otherwise miss: a reviewed configuration that a session can rewrite after review is not a reviewed configuration. The same page notes that a project's checked-in server file does not show every server a session can load, since other scopes, connectors and plugins add their own, so answer question thirteen against what actually loads.

## The Weakest Evidence on the Page Is the Scanner Run

Most teams reach for a scanner first and the questionnaire second, because a tool run feels like proof and a list of answers feels like paperwork. That ranking is backwards, and the sources above are why. A scanner tests the model layer. The UK NCSC's position is that complete mitigation of injection may never arrive, so a passing probe set is a snapshot against known phrasings rather than a property of your system. Meta's constraint on how many sensitive traits a session may combine is an architectural decision: no scan can tell you whether you accepted the third trait by accident. And the questions that decide incident size, the ones about a distinct principal, a hard ceiling, an approval screen showing literal arguments and a switch that works in minutes, are all answered with configuration and diffs, which no probe can discover.

So rank the evidence: a merged configuration change outranks a green test, which outranks a scanner report, which outranks an assurance in a meeting. Teams that invert it find out at an incident review, holding a clean probe run and no answer on what the agent was permitted to do.

This holds only until a scanner drives your real tool layer, against a staging tenant with real credentials, and reports which actions actually completed rather than which strings the model emitted; at that point it becomes primary evidence and the questionnaire becomes the secondary artifact. That is a different class of tool from a model prober, and the position is worth re-testing against the tooling each year rather than held on principle.

## Where an Independent Review Belongs

This list is a starting point, not a security review, and certainly not a legal or compliance assessment. An agent that touches regulated records, moves funds or operates on production infrastructure needs a qualified reviewer from outside the build team before launch, and its compliance mapping needs the people who own that mapping.

Re-run the questions whenever a tool, a data feed, a prompt or a model version changes. Most agent incidents trace back to a modification that skipped the scrutiny the system got on its first day.

## FAQ

### Who needs to be in the room to answer these questions?

The engineer who built the agent, the person who owns the systems it touches, and a reviewer with no stake in the launch date. The third role matters most, because the disagreements are the useful output.

### What counts as evidence for closing an item?

Something a second person can inspect: a merged config change, a test in CI, a log query that returns the expected rows, or a denied call recorded when a limit fired. A decision reached in a meeting is not evidence.

### Can a security platform answer any of this for us?

Tooling can answer the inventory and telemetry questions, and it can enforce some call-level limits. It cannot decide which actions are irreversible in your business or who is allowed to approve them, so the authority questions stay yours.

### Does a small internal agent really need the whole list?

Run all twenty, but expect most answers to be cheap. An agent with no private data and no ability to act will fail only a few items. The list is there to tell those agents apart from the ones that can move money.


---
Source: https://agenticcyber.co/blog/agentic-ai-security-checklist-pre-deployment