API Security for AI Agents Checklist

This checklist is for API owners, platform engineers, and AppSec teams connecting AI agents to internal or third-party APIs through tool calling, plugins, or MCP servers. Agents are API clients that are fast, persistent, and steerable by whatever content they read. That makes long-standing API weaknesses easier to exploit and adds new ones.

It draws on the OWASP API Security Top 10 (2023) and the OWASP Top 10 for LLM Applications; relevant IDs are noted in brackets.

How to use this checklist

1. Run it for each agent integration, covering every API or tool that agent can call.
2. Treat any failed item under authorization or prompt injection as a blocker for production.
3. Re-run it when the agent gains a new tool or the API adds endpoints.

Inventory

• □ List every API, tool, plugin, and MCP server each agent can reach [API9 Improper Inventory Management].
• □ Mark each operation as read-only or state-changing.

Authentication and authorization

• □ Agents use dedicated credentials, never shared user tokens or personal API keys.
• □ OAuth scopes are minimal, with read and write separated.
• □ Agents acting for a user are bounded by that user's permissions, and the API checks authorization server-side on every object [API1 Broken Object Level Authorization]. Agents will happily iterate through IDs.
• □ Administrative functions are unreachable with agent credentials [API5 Broken Function Level Authorization].
• □ Responses return only the fields the agent needs [API3 Broken Object Property Level Authorization].
• □ Tokens are short-lived and revoked when the agent session ends.

Prompt injection and output handling

• □ Treat everything the agent reads as untrusted, including web pages, emails, documents, and API responses [LLM01 Prompt Injection].
• □ Validate tool-call parameters against strict schemas on the server, not through instructions in the prompt.
• □ Require human confirmation for irreversible or high-impact operations [LLM06 Excessive Agency].
• □ Never pass model output straight into shells, SQL, or code evaluation [LLM05 Improper Output Handling].
• □ Restrict which URLs the agent can fetch [API7 Server Side Request Forgery] and block data exfiltration through rendered links or images.

Abuse and resource controls

• □ Apply rate limits and quotas per agent identity [API4 Unrestricted Resource Consumption, LLM10 Unbounded Consumption].
• □ Protect sensitive business flows from automated abuse [API6].
• □ Add circuit breakers that stop an agent stuck in a tool-call loop.
• □ Validate data returned by third-party APIs before the agent acts on it [API10 Unsafe Consumption of APIs].

Logging and monitoring

• □ Log every tool call with the agent identity, delegating user, parameters, and result.
• □ Alert on anomalies: new endpoints, volume spikes, authorization failures, and ID enumeration patterns.

Common pitfalls

• Using the system prompt as a security boundary. Instructions can be overridden; server-side checks cannot.
• A broad admin key "just for the demo" that ends up in production.
• Client-side authorization, which an agent (or an attacker steering it) simply bypasses.
• No per-agent attribution, so you cannot tell which agent made a damaging call.