Keep your API gateway for AI agents: where decisions about agent actions belong

What an API gateway for AI agents already does well

If your company exposes business APIs, it probably runs an API gateway in front of them already: Kong, Apigee, AWS API Gateway, or Envoy and Istio. It also runs an identity provider. When AI agents start calling those APIs, you don't need to rip either out. Often the best API gateway for AI agents is the one you already run.

An API gateway is infrastructure that sits in front of services and routes, authenticates and rate-limits the requests sent to them. Those jobs still matter for agents. Kong's Rate Limiting plugin limits how many HTTP requests can be made in a given period, and counts per consumer once an authentication plugin is set up. AWS API Gateway can call a Lambda authorizer that takes the caller's identity as input and returns an IAM policy that allows or denies the call.

To the gateway, an agent is just another client with a token. That is fine for routing and load. The gap is in what the gateway was built to decide.

The decision your gateway doesn't make

A gateway answers "may this client call this route?" An agent action raises a longer question: may this agent, acting for this person, do this operation, on this record, with these arguments?

Take a support agent with a refund tool. The route POST /refunds is open to the agent's client, so the gateway lets the call through. It can't see that:

• the amount is $4,500, and finance allows at most $2,000 per invoice per week;
• the invoice belongs to a different customer from the one on the case;
• the agent acts for a support rep, who shouldn't approve their own large refund.

Part of this is about inputs. AWS documents a Lambda authorizer's input as a bearer token, or a mix of headers, query string parameters, stage variables and context variables. A refund amount in the JSON body isn't on that list. The invoice record isn't in the request at all; it lives in the billing system.

OWASP's guidance on excessive agency is to implement authorization in downstream systems rather than let the model decide. That decision needs the arguments, the record and the acting-for relationship. See stopping a $4,500 refund for the full case, and AI agent authorization for the general model.

Three ways to add agent-action decisions without replacing the gateway

There are three places to add the decision. They differ in what they can see, and so in what they can enforce.

1. Behind the gateway, as the last hop. The gateway forwards agent traffic to a decision point directly in front of the service. Every request and every answer passes through it, so this is the only position with full coverage, including masking fields in the answer. The decision point can also hold the service credential, so agents never see it.
2. Inside an Envoy-based gateway, through ext_authz. Envoy or Istio asks an external service to decide each request before forwarding it. Masking the answer is the one gap, as the next section explains.
3. Beside the gateway. Nothing sits in the request path. A system here can find agents and manage their identities, but it can't stop, hold or change a call. It's a low-risk first step, not a control on actions.

Envoy ext_authz for AI agents: what it can and can't do

Envoy's external authorization filter, ext_authz, calls an external gRPC or HTTP service to decide whether each incoming request is authorized. If the service refuses, Envoy returns 403 Forbidden. Istio uses the same mechanism: an AuthorizationPolicy with the CUSTOM action delegates to an external authorizer that implements Envoy's ext_authz check API.

A decision service here can allow or deny on the operation, arguments and record, hold calls for human approval, track budgets and write receipts. It can't mask output, because Envoy proxies the answer itself. The authorizer decides before the request goes upstream, and the response comes back through Envoy, not through the authorizer.

Argument checks need the request body, which Envoy sends only when with_request_body is set:

http_filters:
- name: envoy.filters.http.ext_authz
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
    grpc_service:
      envoy_grpc:
        cluster_name: agent-authz
      timeout: 0.5s
    with_request_body:
      max_request_bytes: 65536
      allow_partial_message: false   # oversized bodies get 413, never a partial check
    failure_mode_allow: false        # authorizer unreachable: reject, don't wave through

So choose by what you need to enforce. If a service returns data an agent shouldn't see, that service needs the last hop. If the risk is in what agents send, ext_authz adds decisions with the smallest change. You can mix positions per service.

What your existing gateway must do

Two things, whichever position you choose.

Pass the agent's own token through. The decision point has to know which agent is calling and for whom. If the gateway swaps the agent's credential for its own service account, every request looks like the gateway, and per-agent rules become impossible. Forward the agent's token, or its client certificate, to the decision point. In Envoy, include_peer_certificate sends the peer's X.509 certificate to the authorization service. The decision point uses the token to identify the agent, never to call the service.

Network so agents can reach only the gateway path. If an agent can reach the billing API directly, every check above is optional. Put services where agents can't reach them, and accept calls only from the decision point. Network policies, security groups and private endpoints all do this.

Common mistakes when agents share your API gateway

Letting agents hold service keys. If the agent's environment holds the billing API key, the gateway is a suggestion. A manipulated agent, or anyone who reads its environment, can call the service directly. Keep service keys with the decision point and give agents only their own identity.

Checking only the route. "This client may call POST /refunds" is permission to try. Route scopes are a start, but the risk is in the amount, the record and the frequency. A decision that ignores the body and the record will approve the $4,500 refund.

Trusting headers the agent sets. Some setups carry identity in headers such as X-Agent-Id or X-On-Behalf-Of. If the agent can set them, a prompt-injected agent can claim to be another agent or to act for another person. Derive both from verified credentials, and strip incoming copies of those headers at the edge. In Envoy, an HTTP authorization service can set them on the upstream request through allowed_upstream_headers.

AI gateway vs API gateway

"AI gateway" usually names something else: a proxy for traffic from applications and agents to model providers, such as Cloudflare AI Gateway. Products in this category typically route one API to many model providers, fall back when a provider fails, cache and rate-limit requests, track token spend, and keep provider credentials in one place. Some also sit in front of MCP servers and filter which tools each caller can see.

Those features solve real problems: cost, provider choice, failover and which tools each agent can see. An AI gateway answers "which model, which tools, how much?" A tool-call decision answers "should this action happen, on this record, for this person?" Most agents need both, and neither replaces the API gateway in front of your services. For risks specific to tool servers, see MCP security.

Checklist: keep your gateway, add the decision

• List which agents call which services through your gateway today.
• Give every agent its own identity, and pass it to the decision point unchanged.
• Take service keys away from agents and let the decision point hold them.
• Put the decision behind the gateway for services that return sensitive data.
• Turn on with_request_body for Envoy or Istio routes where arguments matter.
• Set failure_mode_allow to false, and test what happens when the authorizer is down.
• Strip identity and acting-for headers that clients send.
• Block direct network paths from agents to services.
• Keep a receipt for every decision, including denials.

For how these controls fit together, see our practical guide to AI agent security.

Where AgentFort fits

AgentFort works with the gateway and identity provider you already run, and fits all three positions. Behind any gateway, such as Kong, Apigee or AWS API Gateway, as the last hop before the service, it has full coverage. Inside an Envoy-based gateway, such as Envoy or Istio, through ext_authz, it handles decisions, approvals, budgets, record checks and receipts, but not output masking. Beside the gateway, it runs AgentFort Discover and AgentFort Identity only. As the last hop, AgentFort calls the service with its own credential, scoped to that one operation. If its control plane is unreachable, AgentFort's gateway keeps the last signed rules for 60 seconds by default, then refuses every call. In our lab it added about 1 ms at the 95th percentile at 100 requests per second. See AgentFort Access or request a demo.