AI agent security checklist

When this checklist applies

Apply it to any AI system that can take an action beyond producing text for a person to read: sending messages, modifying records or files, executing code, calling APIs, changing access, spending money, or publishing. That includes coding agents, customer-service agents, workflow automations with AI steps, and AI assistants with write-capable connectors.

There is also an interactive version of this checklist that runs entirely in your browser.

Inventory and ownership

• The agent is registered in the AI inventory before connection to company systems.
• A named business owner is accountable for its purpose and access.
• A technical owner is responsible for its configuration and credentials.
• Its purpose is documented in one or two sentences.
• Every tool, connector, and MCP server it can use is listed.

Identity and credentials

• The agent has its own identity — not an employee's personal login or token.
• Credentials are stored in a secrets manager and injected at runtime, never in prompts or code.
• Credentials are scoped to the minimum required resources and actions.
• Credentials are short-lived or rotated on a schedule.
• The agent's actions are distinguishable from human actions in downstream logs.

Least privilege

• Each capability maps to the documented purpose; unneeded capabilities are removed.
• Read-only access is used wherever writes are not required.
• Data access is scoped to specific folders, tables, or records, not entire systems.
• The agent cannot modify its own permissions or anyone else's.
• The agent cannot modify CI/CD pipelines, branch protections, or security settings.
• Production access is excluded, or granted just-in-time for specific tasks.

Human oversight

• Human approval is required for external communications (email, messages, posts).
• Human approval is required for deletions, or deletes are converted to recoverable soft-deletes.
• Human approval is required for financial transactions, with hard limits enforced in the payment system.
• Human approval is required for deployments and changes to production.
• Approval prompts show exactly what will happen, in plain language.
• Approvers are trained to reject unclear requests; bulk approval is discouraged.

Prompt-injection defenses

Any content the agent reads — web pages, emails, documents, tickets, code, API responses — may contain instructions. Design so that a successful injection cannot cause serious harm.

• Agents that read untrusted content are separated from agents that hold sensitive data or powerful tools.
• Outbound network destinations are restricted to an allow-list.
• Actions following retrieval of untrusted content require approval.
• The agent does not render or follow links and images that could exfiltrate data.
• System instructions are not treated as a security boundary; enforcement lives in permissions and approvals.

Limits and kill switch

• Rate limits cap actions per minute and per day.
• Spending and volume caps are enforced outside the agent.
• A tested procedure can disable the agent and revoke its credentials within minutes.
• The kill-switch procedure is documented in the incident response plan.

Logging and monitoring

• Every action is logged with initiator, tool, target, parameters (redacted), and outcome.
• Logs are sent to a central store and retained long enough for investigations.
• Alerts fire on unusual volume, new targets, failed approvals, or permission errors.
• Logs do not contain secrets or unnecessary sensitive data.

Vendor and model

• The model provider's data terms (retention, training use) are recorded.
• Required agreements (DPA, BAA) are in place for the data involved.
• Model or prompt changes are tested before release.
• Third-party MCP servers and plugins are reviewed like other third-party software.

Prioritizing the checklist

You will rarely implement every item on day one. Prioritize by combining two questions: what is the worst thing this agent could do with its current access, and how likely is it to encounter untrusted input? An internal agent that only reads a knowledge base is low priority. An agent that reads inbound email and can send email to anyone is high priority, because both the impact and the injection exposure are high.

Pre-launch review questions

Before an agent is connected to production systems, a reviewer who did not build it should be able to answer each of these in writing:

1. What is the worst realistic outcome if the agent follows a malicious instruction hidden in content it reads?
2. Which actions are irreversible, and does each one require human approval?
3. If the agent's credential leaked tomorrow, what could an attacker do with it, and how quickly could we revoke it?
4. Where would we look to reconstruct everything the agent did last Tuesday?
5. Who gets paged if the agent misbehaves at 2 a.m., and do they know how to stop it?
6. What changed since the last review — new tools, new data sources, a new model?

If any answer is "we don't know", the agent is not ready for production access. Record the answers with the review date; they become evidence for auditors and enterprise customers, and a baseline for the next review.