Affinidi Trust Fabric - Agent Gateway

The control layer for agentic AI.

Agent Gateway is an intercepting proxy for AI agents. It sits between callers and the agents it manages, and applies identity verification, policy evaluation, trust-registry lookups, and payment controls to traffic in both directions.

It is protocol-aware rather than a generic network proxy: it speaks A2A, MCP, and DIDComm natively, so it can read and act on agent traffic instead of just forwarding it.

Agent Gateway is part of the Affinidi Trust Fabric, alongside Agent Stream, which governs the calls agents make to model providers.

• No changes to your agent code. Point the caller at the gateway's URL instead of the destination. Controls that answer the caller, such as a payment challenge or a consent prompt, need the caller to handle that response.
• One place to enforce access. Identity, policy, and rate limits live in the gateway rather than being rebuilt in every agent and every backend.
• Agent identity that survives a trust boundary. Agents get verifiable decentralised identifiers, so a partner organisation can check who is calling and what vouches for them.
• Credentials stay out of agents. The gateway can inject API keys and tokens on the way out, so an agent does not need to hold the credential for the service it calls.
• Visibility into what agents actually did. Every request produces metrics and logs, and traces when OpenTelemetry is configured. A policy denial is logged with its reason and the policy version that made it.
• Evidence for an auditor. When enabled, an audit log records policy decisions, trust checks, and delegated credential use, each policy decision tied to the exact policy version that made it. On Transit Point calls, policy decisions also travel inside a presentation signed by the gateway.
• Payment controls for metered services. x402 and MPP settlement, so an agent can pay for what it calls under limits you set.

docs/CAPABILITIES.md describes every capability in detail.

Say agent A calls MCP server B. Without the gateway, A needs its own network path to B, which for a SaaS product or a public MCP server means direct internet access, and A holds whatever credential B requires.

With the gateway, A calls a listener on the gateway instead, and the gateway forwards to B. A only needs to reach the gateway. With nothing else configured, the gateway forwards the traffic, which now passes through a point you control. Neither A nor B needs a code change.

From there you add controls without touching either side: inject the credential for B, require a policy to pass, check a trust registry, rate limit, or record the exchange.

Two gateways can also be connected, so a call can cross an organisational boundary and the agent's identity still means something on the other side. That path runs over DIDComm v2.1 through a mediator.

flowchart LR
    Caller([Caller]) --> AP[Access Point]
    AP --> Target[Target]
    Target --> Agent([Managed agent])
    Agent --> TP[Transit Point]
    TP --> Service([External service])
    Target -. DIDComm fabric .-> Peer([Peer Gateway])

An Agent Surface is the configuration and runtime unit for one managed agent. Its Access Point receives inbound traffic, its Target identifies the managed agent's endpoint, and optional Transit Points control the traffic that agent initiates. A fabric:// Target routes to another gateway, with each gateway keeping its own trust boundary.

Everything is configured and watched from a web dashboard served by the gateway itself.

Each surface is built on a canvas by dragging in elements such as caller context, identity, policy, and credential delegation. The same surface can be edited as JSON, and we plan to provide a CLI and SDK for automating it.

Follow the hosted Agent Gateway Quickstart to deploy an appliance, create your first surface, add access controls, and monitor traffic.

The primary local path uses macOS with Homebrew. Install Git, Rust 1.95.0 or newer, Node.js with npm, and a WebAuthn-capable browser and authenticator, then run:

git clone https://github.com/affinidi-ai/agent-gateway.git
cd agent-gateway
make install-deps
make run-debug

Complete passkey registration in the browser window opened by the run script. It uses the WebAuthn origin generated in envs/local/config/gateway.json. Then check the local HTTPS backend:

curl -k https://localhost:8443/api/v1/health
curl -k https://localhost:8443/api/v1/alive

docs/development/GETTING_STARTED.md covers the full source-build path, including Linux setup, expected responses, reset, and troubleshooting.

One Rust binary, agent-gateway, built from src/, plus a React dashboard served from the same process and built from www/default/. About 270,000 lines of Rust across 54 top-level modules. No database and no sidecar: state lives in an in-memory cache backed by JSON files on disk.

ARCHITECTURE.md maps the system to the source tree.

Everything needed to understand and build this repository is in it. The hosted documentation adds procedures for deploying and operating an appliance. Where the two differ, repository documentation describes this source revision exactly.

Use the hosted protocol documentation for integration guidance. docs/PROTOCOLS.md records the exact limitations and compatibility behaviour of this source revision.

Agent Gateway uses open standards so that identity and trust work across organisational and cloud boundaries, not only inside one deployment.

The Affinidi technology stack adheres to open standards from the W3C, the Decentralized Identity Foundation, the Linux Foundation, and the EU Digital Identity (EUDI) programme. Affinidi has also donated open-source implementations to some of these bodies, among them didwebvh-rs, the did:webvh library Agent Gateway itself uses, now hosted by the Decentralized Identity Foundation.

Contributions are welcome. Read CONTRIBUTING.md for the discuss-first workflow, required checks, tests, and changelog fragments. Participation is governed by the Code of Conduct.

For usage questions, use the Affinidi support form. For reproducible technical problems or feature requests, search or open a GitHub issue.

To report a security vulnerability, follow the private disclosure process in SECURITY.md.

Licensed under the Apache License 2.0. See LICENSE.