Kong alternatives when agent calls leave the gateway

Your API gateway logs every request that hits the public API. The agent then calls Stripe from its own process, with a key in memory. Kong never sees that request. The refund still happens.

This post separates an ingress gateway from the outbound call an agent makes, and names what to put on the outbound side.

What Kong prices and what it sits in front of

On the Kong pricing page, Konnect Plus lists a dedicated cloud gateway control plane at $500 a month, bandwidth at $0.15 per GB, a serverless gateway control plane at $25 a month, and a hybrid control plane at $200 a month. Plus includes 1 million requests a month, then $200 per extra million. Enterprise is volume pricing. Fully self-hosted Gateway Enterprise is custom.

Kong AI Gateway is built for traffic you route through Kong. That includes LLM proxying, MCP tool catalogs, and agent-to-agent routes. The 3.14 release describes Kong on the path of agent-to-agent calls, with auth, rate limits, and logs. AI Gateway 2.0 bundles MCP servers so one route can hide tools the caller is not allowed to see.

Those controls apply to the request that enters the route. A library call from the agent process to a provider does not enter that route unless you force it to.

Where an ingress gateway still wins

Keep Kong when you publish APIs to other teams or customers and you need one front door.

Rate limits, authentication, and a catalog of MCP tools belong there. Two agents can hit one bundled route and see different tools. That is the right control for "who may discover this tool." API gateway alternatives for agent traffic compares that class of product.

You also want Kong when the expensive traffic is the model itself. The model cost docs price input tokens, output tokens, and cache so a spend policy can fire on the LLM bill.

What leaves through the side door

The agent is the client. The provider is the destination. If the code uses the provider SDK, the packet goes to the provider. Your ingress logs stay quiet.

That is the call that needs an allowlist, a schema check, and a credential the model cannot read. Swytchcode runs that path. You swy get a bundle, swy add the methods you accept, and policies.json can block on the arguments before the request is sent. A block exits with code 6 and does not reach the provider.

On the October 2026 pricing page, Free is 100 live commands a month. Business is $149 a month for 1,000,000. Allow and deny are on every plan. Approval starts on Business. Kong Plus request pricing and Swytchcode live-command pricing are different meters. One counts traffic through the gateway. The other counts a call that went to a provider. Credential brokering is why the provider key should not be in the prompt even if Kong authenticates the inbound API.

A concrete split helps. The public chat API your customers call should enter Kong, with auth and a rate limit. The agent's refund to the payment provider should not be assumed present in that access log. If you later put a Kong route in front of the payment host, you will see the HTTP request, and you will pay the gateway meter for it. You still need something that knows the method id and the amount field. A gateway plugin can rate limit the route. It will not, unless you write that plugin against this body, tell you the amount crossed a cap you keep in git. Teams that already run Kong should keep it. Teams that only needed the outbound check should not stand up a control plane to get a block message.

Check the outbound call

Follow this step to install the CLI. Use one of these.

npm install -g swytchcode

irm https://cli.swytchcode.com/install.ps1 | iex

curl -fsSL https://cli.swytchcode.com/install.sh | sh

Confirm the install, then start the project.

swy --version
swy init

Search the registry for the provider the agent calls directly, then add only those IDs.

swy search <provider>
swy get <name from search>
swy list methods
swy add <canonical_id from swy list methods>

Connect the provider. There is no .env file in this project. Swytchcode keeps credentials in its own local store and reads them when a call runs. The ID in the dry run is the one you copied from swy list methods.

swy auth connect <provider>
swy exec <canonical_id> --dry-run
swy policy validate

Keep Kong on the routes you publish. Put the provider call the agent makes on its own on an allowlist, and read a dry run before you send it. A route you did not create will not show that call.

Related reading

• Policy as code. Argument checks for the call the gateway never saw.
• Log every API call an agent makes. Gateway access logs and provider call logs are different files.
• MCP gateways and execution layers. A tool catalog and the call itself are separate layers.
• Human approval. Hold a write even after the route is open.

FAQ

Does Kong AI Gateway see every call my agent makes?

It sees calls you send through a Kong route. That includes LLM proxy traffic, MCP traffic, and agent-to-agent routes you configure. A direct provider SDK call does not show up there.

What does Konnect Plus charge for AI gateway requests?

The pricing page lists 1 million requests a month included on Plus, then $200 per additional million. A dedicated cloud gateway control plane is $500 a month on that column, and bandwidth is $0.15 per GB. Enterprise is custom.

Should outbound agent calls be forced back through Kong?

Only if you want Kong's route policy on that hop and you accept the extra network path. Many provider calls are simpler as a direct request with a local allowlist. Do not assume the ingress log covers them either way.

Can an MCP ACL replace a policy on the provider body?

An MCP ACL can hide a tool so the model never sees it. It does not, by itself, read the body of a provider call that bypasses Kong. If the tool is visible and the model sends a bad amount, you still need a check on that amount.