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
| Term | Meaning |
|---|---|
| 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 Variant | A 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. |
| Target | The 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. |
| Listener | A configured network endpoint used by Access Points or Transit Points. One listener can serve many of them. |
| Entry point URL | The full URL other agents use to reach a surface: listen address + surface prefix + custom path. Shown at the top of the Access Point settings panel and in a banner on the surface canvas. |
| Inbound | External caller -> Access Point -> Target. |
| Outbound | Managed 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
| Term | Meaning |
|---|---|
| Surface protocol (agent protocol) | The protocol spoken at both the Access Point and the Target. Inbound traffic is not protocol-translated. |
| Transit protocol | The protocol used by one Transit Point. It may differ from the surface protocol. |
| A2A | Agent-to-Agent protocol for direct agent traffic. A2A protocol -> |
| MCP | Model Context Protocol for tool-oriented interactions. MCP protocol -> |
| DIDComm | DIDComm messaging protocol; also used as transport for fabric routing. DIDComm -> |
| HTTP endpoint | An external HTTP target reached over the network. |
| Fabric endpoint | A Gateway-to-Gateway target resolved through another gateway in the same fabric. |
| MCP proxy endpoint | A target routed through a configured MCP proxy backend. |
| Proxy | A pre-configured reverse proxy backend registered under Proxies in the sidebar. MCP proxies and A2A proxies are separate types. A Managed Agent can select a proxy as its endpoint type instead of a direct URL. |
| Fabric | The DIDComm-based appliance set participating through Connection Points. |
| Fabric exposure | The setting on a Remote gateway’s Publishing tab, under Fabric Exposure, that decides which local surfaces that peer can reach over Fabric: No surfaces, Selected surfaces, or All surfaces. A newly paired gateway starts with No surfaces. |
| Connection Point | A DIDComm endpoint used by another appliance to establish and use a connection with this appliance. Gateways -> |
| G2G | Gateway-to-Gateway traffic routed through the fabric. Gateways -> |
| Message validation | An Access Point setting on A2A surfaces that sets how much of each request the gateway checks before forwarding it: Off, JSON-RPC envelope (the default), or Envelope + A2A fields. |
| Elicitation | An 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
| Term | Meaning |
|---|---|
| Source authentication (source auth) | Verification that the inbound caller is who they claim to be, configured per Access Point. |
| Authenticated identity | Runtime result of source auth for one inbound request: the authenticated principal plus auth metadata. |
| Credential extraction | The configured place source auth reads a presented credential. |
| Identity resolution | Rule for deriving a caller agent DID from an authenticated inbound request. |
| Identity slot | One DID-extraction position on a surface: inbound, protected, or external. |
| Managed identity | Rule 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 DID | The decentralized identifier representing an agent in gateway identity flows. |
| Identity origin | Where an identity on the Identities page comes from, shown as a badge: Managed Agent for an identity the gateway manages for one of its surfaces, or External Caller for an identity presented by a caller outside the gateway. |
| Identity injection | Rules deciding whether forwarded calls include proof of the resolved agent DID. |
| Verifiable Presentation (VP) | Signed credential bundle attached when identity injection is enabled. |
| Caller Context | Canvas element that extracts and validates the inbound caller’s authentication credential (JWT bearer, API key, DID Auth, or mTLS). Configures how source auth is performed on the inbound edge. Corresponds to the Source authentication concept. |
| Credential Delegation | Canvas element placed on an outbound edge (MA → TP or MA → External). Configures per-caller OAuth token injection: the gateway fetches or elicits a stored OAuth token for each caller and injects it on the forwarded request. Relies on the delegation vault. |
| Secrets | Named API key credentials stored in the gateway’s Secrets store. Used by the API Key (secret store) source auth method on a Caller Context element. |
| Delegation vault | The 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 Binding | VP attestation that binds caller context to an outbound edge. Can be placed on a Managed Agent → Transit Point edge (G2G topologies) or a Managed Agent → External edge (plain HTTP targets). Workload Binding → |
Dashboard access
| Term | Meaning |
|---|---|
| Personal access token (PAT) | A long-lived bearer credential that automation uses to call the management API in place of an interactive session. Created on the Access Tokens (PAT) tab of the Secrets page. A token acts as the user who created it, and its scopes can only narrow that user’s role. Access tokens -> |
Canvas elements
Enhancement and configuration elements available in the surface builder palette. All are optional unless stated otherwise.
| Element | What it does |
|---|---|
| Networking | Timeout, retry, circuit breaker, and traffic mirroring settings for a surface edge. |
| Rate Limit | Per-route or per-caller request rate limiting. Configured on the Access Point or Transit Point edge. |
| MCP Tool Gating | Regex- and condition-based allow/deny firewall over MCP tool names, applied to both tools/list and tools/call on an MCP Transit Point. |
| Metadata Extraction | Maps request headers into protocol metadata fields before downstream controls (identity, policy) run. |
| Metadata Injection | Injects custom headers, protocol extensions, or body fields into requests or responses. |
| Extension Rules | Allows, strips, or rejects A2A protocol extension URIs on requests passing through the surface. |
| Extension Validation | Requires specific A2A protocol extensions to be present on inbound requests. |
| Transit Settings | Shared settings applied to every Transit Point on a surface, such as shared auth or timeout defaults. |
| Remote Channel | References a surface on the remote gateway in a G2G transit configuration. Used alongside the GW hop node. |
| Payment | Configures an x402 paywall or MPP payment gate on the Access Point or a Transit Point. |
| Trust Check | Runs a TRQP recognition or authorisation query against a connected trust registry, on the caller leg or the target leg. |
| Trust Recorder | Writes agent-registration records into one or more connected trust registries. |
Policy
Gateway-level OPA runs before surface-level or transit-level OPA, and a gateway deny is final.
| Term | Meaning |
|---|---|
| OPA | The 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 reference | A pointer from a surface field to a stored OPA policy definition. |
| Policy definition | Stored Rego source plus metadata reusable by many surfaces or gateways. |
| MCP tool policy | Tool-oriented OPA entry on an MCP target naming a tool and pointing to a stored policy definition. |
Payment and outbound mechanics
| Term | Meaning |
|---|---|
| x402 | HTTP 402 payments protocol for blockchain-settled access. x402 protocol -> |
| MPP | Machine Payments Protocol, an HTTP payment-authentication scheme using challenge and authorization headers. |
| Payment policy | Per-Target configuration declaring how a caller pays before upstream is reached. Transit Points also model payment policy. |
| Facilitator | Component verifying and settling an x402 payment. |
| Settlement | Step that finalizes or records a verified x402 payment. |
| Auto-pay | Automatic fulfillment of an upstream payment challenge up to a configured cap. |
| Transit token mode | How caller context is carried across transit calls. |
| Transit token | Short-lived token injected on inbound surface traffic and echoed when the managed agent calls a Transit Point. Carries caller context and allowed Transit Points. |
Monitoring
| Term | Meaning |
|---|---|
| Capture | Pipeline inspection mode available on the surface Monitoring tab. Streams individual requests through each processing stage and shows the exact payload at each step: inbound from caller, outbound to target, inbound response, and outbound result to caller. Useful for diagnosing identity injection, policy evaluation, and routing issues. |
| Channel logs | Per-surface log stream shown at the bottom of the surface Monitoring tab. Scoped to one surface with no additional filtering required. |
| Rule Accepts | Monitoring series counting requests that passed OPA policy evaluation and were forwarded to the target. |
| Rule Denies | Monitoring series counting requests denied by the surface OPA policy. |
| Gateway Faults | Monitoring series counting upstream errors unrelated to policy, such as backend timeouts or unreachable targets. |
Was this page helpful?
Glad to hear it. Thanks for letting us know.
Sorry to hear that. Thanks for letting us know.