Absorb vs API gateways
A gateway is the correct place for routing, rate limiting, TLS termination and client identity. It is not where you decide that a given agent may call a narrow subset of your operations and receive a subset of each response. Absorb performs that function behind the gateway.
Side by side
| API gateway | Absorb | |
|---|---|---|
| Model of the world | Routes, consumers and plugins | Operations, tools and a policy per agent |
| What it decides | Whether a request may pass and, in gateways that speak MCP, which tools a key may call | Which operations exist for a given agent, and which fields each response returns |
| Response body | Forwarded, with optional transformation | Filtered field by field against the policy, capped in size |
| Agent protocol | HTTP, with MCP support in newer releases of Kong, Tyk and Azure API Management | MCP over streamable HTTP, SSE and stdio, for Claude, Cursor and custom agents |
| Tool descriptions | Where the gateway generates tools, taken from the specification as written | Generated from the specification and linted to support accurate tool selection |
| Approvals | Not a standard gateway feature | Hold a write for Slack, ServiceNow or the administrative queue, then execute it once |
| Identity to the upstream | Typically a shared service account | The calling agent's own identity through standards-based token exchange |
| Audit | Access logs at request level | One record per tool call with decision, fields removed and drift |
| Where it runs | At the network edge | Alongside the API as a sidecar, or as a route behind the gateway |
Several gateways now speak MCP. Tyk can generate MCP tools from an OpenAPI 3 specification and restrict which tools each key may call, and Kong and Azure API Management route MCP traffic through their own policies. What Absorb adds is covered below: a response contract derived from the specification, a document security can review, and approvals on writes.
The two are complementary
Most organizations retain the gateway at the front. It authenticates the caller, applies rate limits and terminates TLS, then routes agent traffic to Absorb, which governs what agents may do. We ship configuration for Kong, Apigee and MuleSoft, plus a Kubernetes sidecar and a Helm chart.
- The gateway governs the network. Absorb governs the contract.
- Existing routes for human and application traffic are unaffected.
- Agent traffic receives its own path, policy and audit trail.
What a gateway plugin does not provide
A reviewable contract
Security signs off on a single policy and a generated report rather than on every route and an assortment of plugin configurations.
Field-level filtering
Response transformation plugins operate on paths maintained by hand. Absorb derives the response shape from the specification, so undocumented fields are removed by default.
Output designed for agents
Tool names, descriptions and argument schemas that support accurate selection, linted for duplicates and missing descriptions.
Questions
Do we have to put Absorb behind our gateway?
No. It also runs as a sidecar in the same pod as the API, or as a standalone service. A gateway is the usual choice when agent traffic originates outside the cluster.
What does the gateway have to preserve?
The authorization and session headers, no buffering on the SSE endpoint, a read timeout longer than your authorization window, and the DELETE method on the MCP path. The supplied configurations set each of these.
Can the gateway do the authentication instead?
It can authenticate the caller. Absorb still establishes which agent is calling, either through its own tokens or through OIDC from your identity provider.
Other comparisons
Absorb vs OpenAPI-to-MCP wrappers
Publishing an entire specification as tools, against compiling a policy into a defined allowlist.
Absorb vs building it yourself
A wrapper per service and its maintenance cost, against one policy per API.
Absorb vs MCP gateways
Governing the MCP servers you already run, against compiling a governed server from your own API.
Compile your own API and assess the result
Send a specification. We will show the tools it produces, the operations it withholds, and the document your security function would review.