API security best practices for AI agents: the boundaries that actually hold in production

How do you secure APIs when the caller is an AI agent making thousands of tool calls a day on behalf of hundreds of different users? The answer isn't a longer WAF ruleset or a stricter rate limit. It's a rethink of where the security boundary sits, whose identity the call carries, and what the runtime is allowed to enforce.

Our view: API security for agents is not an API problem. It's a runtime problem dressed up as one. The API contract still matters — auth, scopes, rate limits, input validation — but the interesting failures happen one layer up, in the code that decides which tool to call, whose token to use, and what to do when the model asks for something it shouldn't. Get that layer wrong and it doesn't matter how well your API is hardened.

This piece walks through five things: why the old threat model breaks under agent traffic, how to think about identity and delegated auth, where rate limiting and abuse controls need to move, how to validate what agents send you, and what observability looks like when the caller is a probabilistic system. It closes on the runtime boundary — the layer most teams are still missing.

Why the old API security threat model breaks

The traditional API threat model assumes the caller is a piece of software written by a human, deployed once, and behaving deterministically. The security review asks: who owns the client credentials, what scopes did they request, and are they behaving within their rate limit? If those three answers are clean, the API is safe.

Agents break every assumption in that model. The client isn't deterministic — it's a foundation model deciding, at runtime, which tools to invoke based on natural-language input. The credential isn't tied to one client — a single agent process might act on behalf of hundreds of end users in a single hour. The rate limit isn't a proxy for abuse — an agent legitimately doing its job can burn through a human-scale quota in seconds. And the input isn't structured — it's whatever the model decided to put in the parameters, which may or may not match your schema, and may or may not have been influenced by prompt injection somewhere upstream.

This matters because most API security tooling — Kong, Apigee, the WAF layer in front of your load balancer — was built for the old model. It still catches the old attacks. It just doesn't see the new ones. A prompt-injected agent making a legitimate-looking API call with a valid token is invisible to the gateway. The call has correct auth, correct schema, correct rate. The problem is upstream, in the reasoning that produced the call. And that's the part your API layer can't see.

OWASP's LLM Top 10 names most of these — prompt injection, improper output handling, excessive agency, supply chain — but the operational takeaway is more compressed: the security boundary has to move closer to where the tool actually executes. Not the gateway. Not the API endpoint. The runtime that receives the model's tool call and decides whether to forward it.

Identity is the first thing to get right

The single biggest mistake in agent API security is collapsing agent identity into user identity, or the reverse. Both fail. If your agent uses a service account, every action in your audit log is attributed to "the agent," not to the human whose request triggered it. Your compliance team can't answer "who deleted this record." If your agent uses the end user's raw credentials, every tool call runs with the user's full permissions — including permissions the agent has no business exercising, like changing the user's password or exporting their entire account.

The pattern that actually holds is delegated auth with per-user tokens, scoped narrowly. The user authenticates once. The agent runtime holds a short-lived token derived from that session — usually via OAuth 2.1 with PKCE — and every tool call the agent makes carries that user's identity through to the API. The API enforces permissions as if the user made the call directly. The audit trail records the human, the agent, and the tool separately.

We've written the setup mechanics elsewhere: OAuth for AI agents covers the flow, and agent identity vs user identity covers the boundary. What matters for this piece is the principle: every tool call executes as the authenticated user, never a shared service account. If your architecture doesn't hold to that, no amount of API hardening will close the audit gap security review is about to open.

A related mistake: static API keys for agents. They're convenient, they work in demos, and they will fail every enterprise security review. A single leaked key exposes the entire tenant. Rotation is manual. Scoping is per-key, not per-call. In production, treat static keys as a smell — acceptable for internal tooling behind a VPN, not acceptable for anything customer-facing.

Rate limiting has to move to per-user, per-tool

Agent traffic doesn't look like human traffic. A human clicks a button; an agent might invoke six tools in parallel to answer one question. If you rate-limit at the API-key level — the pattern most SaaS APIs still use — the agent will either hit the limit constantly (bad UX) or you'll raise the limit so high it stops functioning as an abuse control (bad security).

The fix is to move the enforcement surface. Rate limits should be applied per-user per-tool, not per-API-key. The agent runtime is the natural place to do this, because it's the only layer that sees both which user is acting and which tool is being called. The API can still enforce a coarser tenant-level ceiling as a safety net, but the fine-grained control lives one layer up.

This matters more than it sounds. Consider a customer-support agent calling a refund_order tool. If a prompt injection convinces the agent to issue refunds in a loop, an API-key rate limit won't stop it — the limit is dimensioned for the whole tenant. A per-user-per-tool limit of "three refunds per user per minute" catches the abuse without breaking normal operation. The technical guide on rate limiting best practices has the algorithm choices; the point here is architectural.
‍

The second column isn't wrong; it's just insufficient. Keep the gateway limits. Add the runtime limits. Alert when either fires.

Input validation is where prompt injection meets your database

Every parameter an agent sends to a tool started life as text the model generated. That text may have been influenced by a document the user uploaded, an email the agent read, or a webpage it browsed. Any of those upstream sources could contain instructions the model shouldn't follow — the prompt injection problem. And unlike SQL injection, you can't sanitise it away, because the payload isn't in a known escape sequence. It's in the semantics.

Three layers of defence, in order of how much they actually help:

Schema validation at the tool boundary. Every tool takes structured parameters. Validate them ruthlessly. If a tool expects an integer, reject anything else — don't coerce. If it expects an enum, reject unknown values. If it expects a UUID that belongs to the current user, verify ownership before executing. This is table stakes and it's where most teams stop; it's necessary but not sufficient.

Semantic authorisation before execution. Some tool calls need more than schema validation — they need policy. "Delete all records in project X" might pass schema validation and pass the user's permission check, but still be an action that should require a confirmation step. Build a policy layer that classifies tool calls by blast radius and applies different rules — dry-run first, require human confirmation, or limit scope — based on the classification. This is where the concept from AI agent guardrails lands operationally.

Output filtering on what tools return. If a tool returns data that contains untrusted content — customer emails, ticket bodies, uploaded documents — treat the return value as tainted. Don't let it silently become the next prompt without a boundary. This is where improper output handling lives in the OWASP list (renamed from insecure output handling in the 2025 refresh).

A note on tools that write. Read-only tools have a smaller blast radius by definition. Write tools — anything that mutates state, sends messages, spends money — deserve stricter treatment. Idempotency keys, confirmation steps for high-risk actions, and audit logging that captures the full parameter payload aren't optional. API idempotency for AI agents covers the mechanics.

Observability is the difference between an incident and a mystery

When an agent misbehaves, the question you'll be asked is: which tool did it call, with what parameters, on whose behalf, and what did the API return? If your logs answer "the agent made an API call" you've lost. The trace has to be end-to-end: user session, agent turn, tool call, API request, database mutation. Each layer contributes its part; the runtime is what stitches them together.

What to capture at minimum:

• User identity on every tool call, not just the initial session.
• Tool name and version so you can attribute behaviour to the tool definition the agent saw at that moment.
• Full parameter payload (with PII handling per your policy). Truncated payloads make incident review impossible.
• Model provider and model version — behaviour changes between model versions, and you'll want to correlate.
• Outcome — success, error class, and for write tools, the resulting entity ID.
• Prompt-injection signals — if you're running any classifier on inputs or outputs, log its verdict alongside the call.

This isn't just for post-incident. It's how you spot patterns. A specific tool with a rising error rate, or a specific user whose agent traffic suddenly looks anomalous, are both signals you want to catch before the security team asks about them. AI agent observability goes deeper on the tooling; the point for security is that observability is the compensating control for the fact that you can't fully predict what the model will do.

Retention matters too. If your SOC 2 auditor asks for six months of tool-call logs and you have three days of Datadog, the security posture you thought you had isn't the one you can prove. Design retention to match your compliance commitments, not your log volume budget.

How Pontil fits

Every pattern in this article — delegated auth on every call, per-user rate limits, semantic authorisation, end-to-end trace — is a runtime concern, not an API concern. You can build all of it in-house, and some teams will. But the shape of the work is the same across every SaaS product with an agent project: the same delegated-auth flow, the same per-user rate limits, the same audit-trail stitching.

Pontil is a Tools-as-a-Service platform. Our runtime executes every tool call as the authenticated user, with per-user rate limits, structured audit logging, and schema enforcement built in — so the security boundary sits at the tools layer, where agents actually act, rather than in the API gateway they've already passed through. We generate connectors from your existing APIs and keep them current as those APIs change. If your agent project is stalling on the compliance and security review — not the model, not the framework — that's the layer we work on. The piece on why agent projects stall covers the pattern in more detail.

What does agent-era API security actually look like a year from now?

The honest answer is that the category is still forming. OWASP has a top-10 list. The NIST AI Risk Management Framework has a set of principles. Foundation model providers like Anthropic and OpenAI are publishing safety research faster than any of it gets standardised. What we don't yet have is a settled set of controls that a security auditor can check off. That will come, and probably faster than most teams expect.

What's already clear: the boundary moves. The API gateway keeps doing its job — TLS, coarse rate limits, WAF rules for the attacks that still look like attacks. But the security controls that matter for agents live one layer up, at the tools runtime. That's where identity resolves to a real user, where per-tool policy fires, where the audit trail gets stitched together, and where the compensating controls for probabilistic clients actually work.

The question worth sitting with, if you're building on your own product: which layer of your stack today can answer "which user, which tool, which parameters, which outcome" for every action an agent took last week? If the answer is "we'd have to correlate three systems and estimate," you've found the layer that needs building.