Glossary

Canonical terms used throughout the Agent Gateway documentation.

The Agent Gateway is an intercepting proxy for AI agents. It handles inbound and outbound traffic on their behalf, and applies identity, policy, trust, and payment controls around that traffic. Also referred to as the Affinidi Agent Gateway (AG).

This glossary provides clear, consistent terminology to help you get started quickly.

Routing model

TermMeaning
Agent Surface (surface)The core configuration and runtime unit for one managed agent. A surface has one Access Point, one Target, and zero or more Transit Points. Surfaces ->
Surface VariantA named variation on a base surface selected by a route-level alias, without creating a separate surface record.
Access Point (AP)The inbound face of a surface where callers reach the managed agent. Owns source authentication and inbound rate limits.
TargetThe managed-agent side of a surface. Inbound traffic from the Access Point is forwarded to the Target. Exactly one Target exists per surface.
Transit Point (TP)An agent-initiated outbound route attached to a surface. Each TP has its own listener, endpoint, credentials, policy, and optional payment settings.
ListenerA configured network endpoint used by Access Points or Transit Points. One listener can serve many of them.
InboundExternal caller -> Access Point -> Target.
OutboundManaged agent -> Transit Point listener -> Transit Point target endpoint.

Use Target only for the managed-agent side of a surface. A Transit Point also has a destination endpoint, but that endpoint is not the surface Target.

Protocols and endpoints

TermMeaning
Surface protocol (agent protocol)The protocol spoken at both the Access Point and the Target. Inbound traffic is not protocol-translated.
Transit protocolThe protocol used by one Transit Point. It may differ from the surface protocol.
A2AAgent-to-Agent protocol for direct agent traffic. A2A protocol ->
AP2Agent Payments Protocol, an A2A-family protocol with payment-oriented credential exchange. AP2 protocol ->
MCPModel Context Protocol for tool-oriented interactions. MCP protocol ->
DIDCommDIDComm messaging protocol; also used as transport for fabric routing. DIDComm ->
HTTP endpointAn external HTTP target reached over the network.
Fabric endpointA Gateway-to-Gateway target resolved through another gateway in the same fabric.
MCP proxy endpointA target routed through a configured MCP proxy backend.
FabricThe DIDComm-based appliance set participating through Connection Points.
Connection PointA DIDComm endpoint used by another appliance to establish and use a connection with this appliance. Gateways ->
G2GGateway-to-Gateway traffic routed through the fabric. Gateways ->
ElicitationAn MCP protocol interaction (elicitation/create) in which the gateway interrupts a tool call to prompt the user for additional input, for example OAuth consent. The gateway holds the request open until the client responds, then resumes automatically. Requires the MCP client to advertise the elicitation capability during initialize.

Identity

TermMeaning
Source authentication (source auth)Verification that the inbound caller is who they claim to be, configured per Access Point.
Authenticated identityRuntime result of source auth for one inbound request: the authenticated principal plus auth metadata.
Credential extractionThe configured place source auth reads a presented credential.
Identity resolutionRule for deriving a caller agent DID from an authenticated inbound request.
Identity slotOne DID-extraction position on a surface: inbound, protected, or external.
Managed identityRule deriving an agent DID for the managed agent from payload or credential binding. Surface-level managed identity defines the base DID; TP-level overrides can refine outbound behavior.
Agent DIDThe decentralized identifier representing an agent in gateway identity flows.
Identity injectionRules deciding whether forwarded calls include proof of the resolved agent DID.
Verifiable Presentation (VP)Signed credential bundle attached when identity injection is enabled.
Delegation vaultThe per-caller credential store that isolates OAuth tokens and secrets by caller. Each vault entry is keyed by (agent_did, user_identity_hash, provider_id). The managed agent never receives raw caller tokens. Caller context binding →
Workload BindingTransit-Point-scoped VP attestation that binds caller context to outbound Gateway-to-Gateway (fabric://) requests. Configured on individual Transit Points; only meaningful in G2G topologies. Workload Binding →

Policy

Gateway-level OPA runs before surface-level or transit-level OPA, and a gateway deny is final.

TermMeaning
OPAThe embedded Rego policy engine used by the gateway. OPA policies ->
Gateway-level policy (gateway OPA)OPA policy attached to a Gateway record and evaluated as the first policy gate.
Surface-level policy (surface OPA)OPA policy attached to a surface or transit flow and evaluated after gateway OPA.
Policy referenceA pointer from a surface field to a stored OPA policy definition.
Policy definitionStored Rego source plus metadata reusable by many surfaces or gateways.
MCP tool policyTool-oriented OPA entry on an MCP target naming a tool and pointing to a stored policy definition.

Payment and outbound mechanics

TermMeaning
x402HTTP 402 payments protocol for blockchain-settled access. x402 protocol ->
MPPMachine Payments Protocol, an HTTP payment-authentication scheme using challenge and authorization headers.
Payment policyPer-Target configuration declaring how a caller pays before upstream is reached. Transit Points also model payment policy.
FacilitatorComponent verifying and settling an x402 payment.
SettlementStep that finalizes or records a verified x402 payment.
Auto-payAutomatic fulfillment of an upstream payment challenge up to a configured cap.
Transit token modeHow caller context is carried across transit calls.
Transit tokenShort-lived token injected on inbound surface traffic and echoed when the managed agent calls a Transit Point. Carries caller context and allowed Transit Points.