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.

[!IMPORTANT]
Project status: Agent Gateway is under active development. Interfaces and stored
configuration may change between minor releases. Evaluate its security, privacy,
availability, and regulatory properties before production use.

Why use it

• 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.

How it works

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.

Moving parts

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.

What it looks like

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.

Quickstart

Deploy an appliance

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

Build from source

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.

What is in this repository

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.

Documentation

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.

Protocol status

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

Built on open standards

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.

Contributing and support

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.

License

Licensed under the Apache License 2.0. See LICENSE.