Agent Governance Foundation

Not Every Agent Speaks MCP or A2A — the HTTP Gateway Covers the Rest

Agent Governance Foundation
restauthorizationarchitecturegateway

We've written about authorizing MCP tool calls and A2A delegations — both real protocols an agent can speak, with a fixed vocabulary of methods AGF can reason about. Most agent deployments we see also do something much less structured: call a plain REST API directly. An internal billing microservice, a third-party SaaS with its own REST or GraphQL surface, an admin API that predates any of this agent tooling — none of it speaks MCP or A2A, and none of it is going to be rewritten to.

That's a real gap, not a smaller version of the same one. A REST API has no "agent" concept at all. It was built for a human with a session, or a service with an API key — not for an autonomous caller whose authority should be delegated, scoped, and revocable per-action.

Where the gap shows up

Point an agent at a REST API today and you get one of two outcomes:

  • A shared API key, scoped to whatever the key's owner can do, with no way to tell which agent, acting on whose delegated authority, made a given call. Revoking one agent means rotating the key for everyone.
  • Nothing at all, if the API sits on an internal network the agent already has access to — the API trusts network position as authorization, which was already a stretch for human operators and is worse for an autonomous one.

Neither gives you what MCP and A2A gateways already provide: a real per-call decision, backed by a delegation chain, trust score, and policy — with a signed artifact proving what was allowed and why.

How the Gateway works

Register your downstream REST API with AGF, and the HTTP Gateway fronts it as a wildcard reverse proxy — no MCP/A2A-style envelope required, because there isn't one to wrap around arbitrary REST traffic.

  1. You point AGF at your API's base URL (target_url) and register the audience your delegation tokens should carry.
  2. Callers hit the gateway URL with the same path, method, headers, and body they'd send your API directly — GET /http/{gateway_id}/invoices/123 instead of GET https://api.acme.com/invoices/123.
  3. Safe methods — GET, HEAD, OPTIONS — pass straight through once your credentials check out, since HTTP itself defines these as side-effect-free.
  4. Unsafe methods — POST, PUT, PATCH, DELETE — get a real decision first: policy, trust score, and risk, exactly like every other AGF integration. action.type is the HTTP verb; action.resource is the request path.
  5. Only on ALLOW does the request forward to your API, byte-for-byte — any content type, not just JSON. Errors come back as real HTTP status codes (403 for a denied action, 401 for a missing delegation chain, 502/504 for upstream problems) rather than an invented envelope, since a REST client already knows how to handle those.

Where we are today

The HTTP Gateway is live — see the integration guide for exact request shapes. Two scope limits worth knowing before you rely on it: classification is purely verb-based today, with no way to override a specific route's behavior (a GET that happens to trigger a side effect on your API, unfortunately not unheard of in the wild, will still pass through unchecked); and action.resource is the raw request path with no template normalization, so /invoices/123 and /invoices/456 are different resource strings to write a policy against, rather than a single /invoices/* pattern. Both are real limitations, not oversights — documented candidates for a v2, not silently decided to be fine forever.

Related

All posts