The AI Agent Security Checklist: 10 Things to Verify Before You Deploy

Before You Ship: Why a Security Checklist Matters

Deploying an AI agent is not like deploying a static website. Agents act autonomously, call external tools, read and write data, chain to other agents, and make decisions — often without a human in the loop. One misconfigured permission, one unvalidated input, one unaudited integration can cascade into a breach, a data leak, or a compliance violation.

Before you go to production, you need more than a working demo. You need a security posture.

This checklist gives you 10 concrete things to verify before any AI agent deployment. Whether you're shipping an internal workflow agent or listing a commercial agent on the Agents.NET directory, these checks apply. For deeper threat model context, see our companion post AI Agent Security: What to Check Before You Deploy.

---

The Checklist

✅ 1. Audit Data Access Permissions

What to check: What data sources, databases, APIs, and filesystems can this agent access? Are those permissions scoped to the minimum required?

Why it matters: Agents running with over-privileged credentials are a ticking clock. If the agent is compromised — through prompt injection, a malicious tool response, or a supply chain attack — an attacker inherits everything the agent can touch. The blast radius of an over-privileged agent is enormous.

How to verify:

Enumerate every credential and API key the agent uses

For each, identify what scope/permissions are granted vs. what the agent actually needs

Downscope to least privilege — read-only where writes aren't needed, scoped tokens rather than root credentials

Document what data the agent can access so you can reason about exposure

If using a cloud provider, review IAM roles attached to the agent's execution environment

---

✅ 2. Validate All Inputs

What to check: Does the agent validate and sanitize every input before passing it to a model or tool? Are prompt injection defenses in place?

Why it matters: Prompt injection is the most underestimated risk in AI agent deployments. An attacker who can inject text into the agent's prompt — through a user message, a document the agent reads, a web page it fetches, or an API response — can hijack the agent's behavior, exfiltrate data, or cause the agent to take unintended actions. Unlike traditional injection attacks, prompt injection doesn't require exploiting a code vulnerability — it just requires crafting the right text.

How to verify:

Review every input path: user messages, file uploads, web content, API responses, tool outputs

For each, identify whether attacker-controlled text could reach the model prompt

Implement input sanitization: strip or escape known injection patterns

Use structured input schemas (JSON schema validation) rather than free-text wherever possible

Consider a dedicated input validation layer that pre-checks inputs before they reach the agent loop

Test with adversarial inputs: "Ignore all previous instructions and..."

---

✅ 3. Verify Output Sanitization

What to check: Is the agent's output sanitized before it's rendered in a UI, stored in a database, passed to another system, or executed as code?

Why it matters: An agent that generates HTML, SQL, shell commands, or other structured output can produce outputs that, if unsanitized, become XSS payloads, SQL injection vectors, or command injection exploits in downstream systems. The agent itself may be operating correctly — the vulnerability is in how its output is consumed.

How to verify:

Trace every output path: where does agent-generated text go after production?

If output is rendered in a browser: HTML-encode and apply a strict Content Security Policy

If output is used in SQL queries: parameterize, never interpolate

If output drives shell commands: validate and escape, or use safer abstractions

If output is passed to another agent: treat it as untrusted input and apply input validation (see #2)

If output is stored: review the storage schema for injection surface

---

✅ 4. Review Authentication & Authorization

What to check: Who can trigger this agent? What are the authorization rules for different actions? Are there privileged operations that require additional verification?

Why it matters: A powerful agent with weak authentication is a force multiplier for any attacker who can make an API call. Authorization is equally critical: even authenticated callers may not be authorized for all agent capabilities. Without clear authorization boundaries, a low-privilege user can trigger high-impact agent actions.

How to verify:

Document all trigger surfaces: API endpoints, webhooks, message queue consumers, scheduled tasks, human interfaces

For each, verify authentication is required and that credentials are validated server-side

Define an authorization model: which principals can trigger which agent capabilities?

Review whether the agent has any unauthenticated surfaces (e.g., a public webhook endpoint)

Test with invalid credentials, expired tokens, and cross-tenant scenarios

For high-impact actions (delete, publish, send message), consider requiring re-authentication or a secondary approval

---

✅ 5. Assess Third-Party Integrations

What to check: What external APIs, services, and data sources does the agent depend on? What's the supply chain risk if one of them is compromised?

Why it matters: Every third-party integration is a trust boundary. A compromised upstream API can feed malicious data to your agent — data the agent will process with full trust. In multi-agent architectures, a compromised tool provider can become a vector for attacking every agent that uses that tool. Supply chain attacks are increasingly common and agents dramatically expand the attack surface compared to traditional software.

How to verify:

Enumerate all third-party dependencies: APIs, SDKs, npm/pip packages, model providers, tool servers

For each, assess: what data is shared? what permissions does it have? what happens if it's compromised?

Pin dependency versions and verify checksums

Review the security posture of model providers (SOC 2, pen testing, data handling policies)

Implement defense-in-depth: don't assume third-party responses are safe — apply input validation (see #2) to all external data

Monitor for dependency updates and security advisories

---

✅ 6. Test Failure and Fallback Modes

What to check: What happens when a tool fails, an API is unavailable, the model returns an unexpected response, or the agent hits an error state? Are failure modes safe?

Why it matters: Security isn't just about preventing attacks — it's about safe failure. An agent that fails open (continuing with partial data, proceeding despite errors, ignoring failed authorization checks) is a security risk, not just a reliability risk. Attackers can deliberately induce failure states to exploit unsafe fallback behavior.

How to verify:

Identify all failure modes: tool timeouts, API errors, model refusals, schema validation failures, context window overruns

For each, verify the failure behavior: does the agent fail safely (abort, alert, escalate to human) or fail open?

Test deliberately: kill dependencies and observe agent behavior

Ensure error messages don't leak sensitive information (stack traces, internal paths, credential fragments)

Implement circuit breakers for external dependencies

Review escalation paths: when does a failed agent create a human-reviewable incident?

Pair this checklist with our AI agent testing guide for a complete quality and security coverage plan.

---

✅ 7. Establish Rate Limits and Quotas

What to check: Are there per-user, per-session, and per-API rate limits? Are there cost quotas to prevent runaway spending? Is there abuse detection?

Why it matters: An agent without rate limits is a denial-of-wallet waiting to happen. Whether through deliberate abuse, accidental infinite loops, or a burst of legitimate traffic that exceeds budget, uncontrolled agent invocations can generate thousands of dollars in LLM API costs and downstream API fees in minutes. Rate limits also reduce the impact of credential theft — a stolen API key is much less valuable if it can only trigger a limited number of agent runs.

How to verify:

Confirm rate limits exist at the API/trigger layer (requests per minute per user/session)

Confirm hard cost quotas at the LLM provider level (max daily spend, max tokens per request)

Review whether the agent has a max step limit to prevent infinite loops

Implement alerting for anomalous usage patterns (sudden spike in invocations, a single user hitting limits repeatedly)

Test the rate limiting implementation: verify it can't be bypassed by changing headers, user identifiers, or request formats

Review what happens when limits are hit: does the agent fail gracefully?

---

✅ 8. Enable Audit Logging

What to check: Is there a complete, tamper-resistant audit log of all agent actions? Does it capture who called the agent, when, with what inputs, what tools were called, and what data was accessed or modified?

Why it matters: Audit logs are the foundation of incident response. When something goes wrong — a data leak, an unauthorized action, a compliance question — you need to be able to reconstruct exactly what happened. Without logs, you're flying blind. With incomplete logs (e.g., logging the final output but not the tool calls), you can't answer basic questions about what the agent actually did.

How to verify:

Enumerate what is currently logged: what events, what fields, what level of detail?

Verify that logs capture: caller identity, timestamps, full prompt/input (or hash), all tool calls and their arguments, all tool responses, model outputs, any data read or written

Verify logs are stored in a tamper-resistant location (separate from the agent's own write access)

Review log retention policy: is it sufficient for your compliance requirements?

Test log completeness: run a known agent flow and verify you can reconstruct it from logs alone

If subject to SOC 2, HIPAA, or GDPR: verify log fields meet audit trail requirements

---

✅ 9. Review Data Retention and Privacy

What to check: What data does the agent collect, store, and process? How long is it retained? Who has access? Does it meet GDPR, SOC 2, CCPA, or other applicable privacy requirements?

Why it matters: AI agents frequently process sensitive data — user inputs, documents, PII, business data. That data flows through LLM APIs (where it may be used for training), tool providers (where it may be logged), and your own infrastructure (where it must be managed per applicable law). Privacy compliance isn't optional — and the consequences of a GDPR violation or a data breach involving PII are severe.

How to verify:

Document all data flows: what data enters the agent, where does it go (model provider, tools, logs, databases), what is retained?

Review your LLM provider's data processing agreement — opt out of training on production data if available

Identify any PII in inputs or outputs and verify it's handled per your privacy policy

Verify retention periods are defined and enforced (automated deletion of logs/sessions after N days)

For GDPR: verify you have a lawful basis for processing, can respond to data subject access requests, and can delete user data on request

For SOC 2: verify audit logs, access controls, and data handling meet Trust Services Criteria

Review whether agent-generated outputs could constitute a privacy risk (e.g., outputs that reconstruct or infer PII)

---

✅ 10. Validate Multi-Agent Trust Boundaries

What to check: In chained or orchestrated agent workflows, does each agent verify the identity and authorization of its caller? Are trust assumptions explicit and validated?

Why it matters: Multi-agent architectures introduce a new attack surface: agent-to-agent trust. If Agent B blindly executes instructions from Agent A because "it's another agent," a compromised Agent A becomes a vector for attacking Agent B — and everything Agent B can access. Prompt injection in multi-agent chains is particularly dangerous: an attacker who compromises early-stage agent can manipulate downstream agents through crafted messages.

How to verify:

For every agent-to-agent call, document: who is the caller, how is caller identity verified, what is the caller authorized to request?

Verify that agents don't blindly trust "system" or "assistant" role messages from upstream agents

Implement caller authentication between agents: signed requests, short-lived tokens, or a trust broker

Apply the same input validation (see #2) to messages received from other agents as you would to user inputs

Test with adversarial orchestrator scenarios: can a compromised upstream agent cause downstream agents to take unauthorized actions?

Review whether your orchestration layer has a security model or relies purely on implicit trust

---

Deploy With Confidence

Security isn't a feature you add after launch — it's a property you verify before every deploy. Run through this checklist every time you ship a new agent or make a significant change to an existing one.

If you're evaluating agents built by third parties, the same checklist applies: ask vendors to demonstrate how they've addressed each item. Verified agents in the Agents.NET directory go through an automated security review process — Publisher Pro includes verified agent badges that signal to enterprise buyers that baseline security requirements have been met. See Publisher Pro pricing.

For a broader threat model beyond this checklist, see our companion post AI Agent Security: What to Check Before You Deploy. And to make sure your agent is well-tested as well as well-secured, pair this with our AI agent testing frameworks guide.

Ship secure. Ship verified.