Overview

What Agent Gateway is, how it governs AI agent interactions, and how to adopt it progressively with identity, policy, and observability controls.

Agent Gateway runtime architecture

CallerAgents, apps, orchestratorsIdentity verified at entryCaller context attachedinboundAgent GatewayProtocol-aware interception and controlA2A · MCP · AP2 · x402IdentityPolicyTrustPayOPA policy enforcement:decisions stay explicit and attributable.DID + VC support:identity propagates across orgs.outboundManaged agentTool hosts, policies, routed servicesAttribute every interactionAuditable runtime pathTOPOLOGY PATTERNSAgentGatewayMCP ProxyREST APIAgentGatewayGatewayAgentCONTROL PLANEAgent SurfacesDrag-and-drop composition and JSON workflowsAuthenticationmTLS, API keys, JWT and DID AuthOpenTelemetryObservabilityEventsNotificationsSAML SSOEnterprise auth login CallerAgents, apps, orchestratorsIdentity verified at entryCaller context attachedinboundAgent GatewayProtocol-aware interception and controlA2A · MCP · AP2 · x402IdentityPolicyTrustPayOPA policy enforcement:decisions stay explicit and attributable.DID + VC support:identity propagates across orgs.outboundManaged agentTool hosts, policies, routed servicesAttribute every interactionAuditable runtime pathTOPOLOGY PATTERNSAgentGatewayMCP ProxyREST APIAgentGatewayGatewayAgentCONTROL PLANEAgent SurfacesDrag-and-drop composition and JSON workflowsAuthenticationmTLS, API keys, JWT and DID AuthOpenTelemetryObservabilityEmailNotificationsSAML SSOEnterprise auth login

What is Agent Gateway?

Agent Gateway is part of the Affinidi Trust Fabric suite. It is an intercepting network proxy purpose-built for AI agents, sitting between callers and managed agents to enforce identity verification, policy evaluation, trust checks, and payment controls on both inbound and outbound traffic.

As organisations scale from pilot agents to multi-team and cross-organisation ecosystems, governance complexity grows quickly. Agent Gateway gives you one control point to answer core runtime questions: who is calling, what they can do, and whether every interaction is attributable and auditable.

Agent Gateway adds AI-native capabilities alongside traditional controls such as metadata handling, validation, key management, and traffic shaping:

  • Protocol-aware handling for A2A, MCP, AP2, and x402.
  • Decentralised identity support with DIDs and verifiable credentials.
  • OPA policy enforcement.
  • Tooling to expose legacy REST services as governed MCP servers.

Connection topologies

Three patterns govern how agents and gateways connect. The pattern you choose depends on whether agent calls cross organisational boundaries and whether identity must be resolved against a shared registry at runtime.

One organisation, one gateway. The Agent Caller routes all requests through Agent Gateway, which enforces identity and policy before forwarding to any downstream service, whether internal or third-party.

  • The Agent Caller has one entry point: Agent Gateway.
  • Agent Gateway can sit in front of any service: MCP tools, external APIs, or other AI agents.
  • Agent Stream and Agent Pay are optional ATF components that integrate under the same policy controls when needed.
governforwardManaged Agentsoptional ATF componentsAgent CallerAgent GatewayMCP ToolsExternal APIAgent Streamcoming soonAgent Paycoming soonCallerATF componentManaged Agent

An agent in Org A calls a resource hosted behind Org B's gateway. The request is forwarded with the caller's identity attached. Org B's gateway evaluates its own policies before allowing access.

  • Caller identity from Org A travels with the forwarded request.
  • Org B's gateway independently evaluates its own access policies.
  • Services behind Org B's gateway can include any managed service: MCP tools, external APIs, or ATF components.
Org AOrg Bcross-boundaryforwarded requestAgent CallerAgent GatewayAgent GatewayServicesCallerAgent GatewayServices

Both gateways resolve the caller's identity against a shared Trust Registry before the request proceeds. Neither gateway needs to exchange credentials directly. The registry is the mutual trust anchor.

  • Identity is resolved at runtime, not pre-configured between organisations.
  • The Trust Registry acts as a neutral third party that both gateways query independently.
  • Services behind Org B's gateway can be any managed service. The trust pattern is service-agnostic.
Trust RegistryTrust checkTrust checkOrg AOrg Bforwarded requestAgent CallerAgent GatewayAgent GatewayServicesrequest pathTrust check (e.g. identity lookup)

The browser-based control plane is built around Agent Surfaces, with drag-and-drop composition for caller context, identity, policy, and routing, and JSON configuration for developer workflows. Enterprise integrations include OpenTelemetry, Prometheus, webhooks, email and Slack notifications, and SAML-based SSO. The gateway deploys as a managed Affinidi appliance or on your own infrastructure.

See how it works →

Understand how it works

Start simple: point your calling agent at an Agent Surface Access Point URL instead of the downstream endpoint. Traffic now flows through the gateway without changing agent or backend code. Once that path is live, you can progressively add identity, policy, trust, and traffic controls.

If agent A currently calls MCP server B directly, you only change A’s target URL to the gateway listener. The gateway forwards the request to B, so behaviour stays the same while you gain a protocol-aware control point in the middle.

Typical adoption flow:

Front the dependency with an Agent Surface Access Point.
Change only the caller target URL from downstream B to the gateway listener.
Confirm pass-through behaviour, then progressively add controls such as API-key injection, policy checks, and traffic shaping.
Extend to cross-organisation traffic by connecting multiple gateways through DIDComm with a Mediator.

Key capabilities

Every agent needs a verified identity, a defined operational scope, and interactions that are observable and attributable, without rebuilding those controls in each agent or deployment. The capabilities below are how Agent Gateway delivers that, behind a single configuration layer.

Agent identity

Derives a deterministic W3C DID from every unique agent configuration without prior registration or key management.

Access control

Evaluates OPA Rego policies per request. Allow or deny based on agent identity, JWT claims, or payload content.

Observability

Emits metrics to Prometheus, logs to cloud providers such as AWS CloudWatch, and traces, metrics, and logs via OpenTelemetry, all simultaneously, with a correlation ID on every request.

MCP support

Expose REST APIs as MCP servers, inject custom metadata, and stream requests over JSON-RPC 2.0 and SSE.

Traffic management

Shapes traffic with mirroring, retry logic, circuit breaker protection, rate limiting, timeouts, URL rewriting, and TLS support.

Gateway federation

Connects gateway instances via DIDComm v2.1 tunnels. No VPN or shared network infrastructure required.

Who uses it

Agent Gateway is designed for organisations moving from AI experimentation into production. At this stage, the challenge shifts from building agents to operating them safely and at scale.

RoleChallenge and what the gateway addresses
Platform and engineering teamsEach team building its own agent integration creates duplicated credentials, inconsistent access control, and per-team logging gaps. The gateway provides a shared control layer for connectivity, policy, and observability.
Security and identity teamsTracking authority and enforcing least-privilege access becomes difficult as agents act on behalf of users. The gateway links agent actions to user or system context, with every interaction logged and auditable.
Data and compliance teamsProducing an accurate audit record of what agents accessed, under which credentials, and under which policy is hard without a control layer. The gateway logs each request with identity, policy decision, and outcome.
Product and digital transformationMoving from prototype to production stalls on inconsistent integrations, unclear credential handling, and limited observability. The gateway provides a structured path to enterprise connectivity with enforcement and monitoring built in.
Ecosystem and partnership teamsGoverning agents across organisational boundaries requires verifiable trust between parties, not just internal policy. The gateway enables policy-driven, identity-aware interactions between agents in different domains.

Find your use case

The scenarios below show how gateway capabilities map to specific operational problems.

Get started

The tutorial builds a running surface, adds identity and access control, and connects chosen resources. It takes approximately 15 minutes.

Make your agent enterprise-ready

Add agent identity, scope management, and trust delegation to a running surface. Identity derivation, OPA access control, and trust registry verification work together: configure all three for auditable, verifiable A2A workflows.

Build an ecosystem of agents

Publish portable agent identities, connect gateway instances across organisational boundaries, and govern agents at ecosystem scale through trust registries.

Frequently asked questions

Detailed answers to common questions about protocols, identity, access control, federation, configuration, and deployment are on the FAQ page.