# 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 ## What is Agent Gateway? Agent Gateway is part of the [Affinidi Trust Fabric](https://www.affinidi.com/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. - Single gateway - Gateway to Gateway - Gateway to Gateway + Trust Registry 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. 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. 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. The browser-based control plane is built around [Agent Surfaces](/products/affinidi-trust-fabric/agent-gateway/concepts/surfaces.md), 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 →](/products/affinidi-trust-fabric/agent-gateway/concepts/architecture.md) ## 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. [ Start with an MCP surface → Front a downstream MCP server with an Access Point so your agent switches target URL only. ](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/setup/mcp-surface-starter.md) [ Architecture → Understand how listeners, forwarding, protocol-aware interception, and policy checkpoints fit together. ](/products/affinidi-trust-fabric/agent-gateway/concepts/architecture.md) [ Agent Surfaces → See how a surface becomes the single control point where you add API keys, policy, shaping, and routing. ](/products/affinidi-trust-fabric/agent-gateway/concepts/surfaces.md) [ Surface routing model → Learn how Access Points, Targets, Transit Points, and Listeners work together in one managed-agent surface. ](/products/affinidi-trust-fabric/agent-gateway/concepts/surface-routing-model.md) [ Gateway federation → Connect gateways across trust boundaries with DIDComm and Mediator-backed secure message routing. ](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/connections/connect-gateways.md) ## 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. | Role | Challenge and what the gateway addresses | | Platform and engineering teams | Each 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 teams | Tracking 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 teams | Producing 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 transformation | Moving 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 teams | Governing 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. [ Multi-client authentication → Isolate credentials per client and enforce route-level access control. ](/products/affinidi-trust-fabric/agent-gateway/concepts/use-cases/multi-client-authentication.md) [ Your telemetry, your control → Export telemetry to your preferred observability stack and boundaries. ](/products/affinidi-trust-fabric/agent-gateway/concepts/use-cases/telemetry-control.md) [ Deployment on your own terms → Run on-premises, hosted, or in restricted environments. ](/products/affinidi-trust-fabric/agent-gateway/concepts/use-cases/deployment-on-your-own-terms.md) [ Powering the MCP ecosystem → Enable tool discovery and interoperability across agent ecosystems. ](/products/affinidi-trust-fabric/agent-gateway/concepts/use-cases/powering-mcp-ecosystem.md) [ Private network connectivity → Keep service connectivity inside trusted internal networks. ](/products/affinidi-trust-fabric/agent-gateway/concepts/use-cases/private-network-connectivity.md) ## Get started The tutorial builds a running surface, adds identity and access control, and connects chosen resources. It takes approximately 15 minutes. [ Create your first surface → Create a surface, send a test request, and confirm traffic is flowing through the gateway. Takes approximately 5 minutes. ](/products/affinidi-trust-fabric/agent-gateway/get-started/create-first-surface.md) [ Set up an MCP proxy → If your primary use case is exposing tools to AI agents, start here. Convert a REST API into MCP tools and serve them on a standalone address or attach them to an MCP surface. ](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/setup/expose-a-rest-api-as-mcp-tools.md) ## 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. [ Enable agent identity → Assign a unique DID to every distinct agent configuration sending requests through the surface. ](/products/affinidi-trust-fabric/agent-gateway/get-started/secure-a-surface.md) [ Define scope rules with OPA → Write OPA Rego rules to allow or deny requests based on agent identity, JWT claims, or payload content. ](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/policies/apply-opa-policies.md) [ Secure a verifiable A2A workflow → Combine identity derivation, OPA access control, and trust registry verification on a single A2A surface. ](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/setup/a2a-surface-starter.md) [ Establish trust between participants → Verify participant identities and validate permissions against a trust registry before allowing communication to proceed. ](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/connections/agent-validation-via-trust-registry.md) ## Build an ecosystem of agents Publish portable agent identities, connect gateway instances across organisational boundaries, and govern agents at ecosystem scale through trust registries. [ Agent identity and DIDs → Understand how agent DIDs are derived, versioned, and verified for cross-organisation discoverability. ](/products/affinidi-trust-fabric/agent-gateway/concepts/identity.md) [ Connect two gateways → Establish a DIDComm tunnel between gateway instances and route traffic across organisational boundaries. ](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/connections/connect-gateways.md) [ Enable x402 agent payments → Gate any surface on x402 blockchain payment confirmation before forwarding requests to the backend. ](/products/affinidi-trust-fabric/agent-gateway/how-to-guides.md) ## Frequently asked questions Detailed answers to common questions about protocols, identity, access control, federation, configuration, and deployment are on the [FAQ page](/products/affinidi-trust-fabric/agent-gateway/faq.md).