Access Point

Field reference for the Access Point panel settings and canvas elements: the inbound configuration of an Agent Surface.

The Access Point is the inbound listener node on an Agent Surface. It defines the URL callers use to reach the managed agent and controls routing at the surface entry point.

Every surface has exactly one Access Point. The gateway’s listen address and the Surface Prefix and Custom Path panel fields together form the Entry point URL, the URL callers use to reach the surface. The protocol is set at the surface level; see Protocol options.

Panel settings

Field	Type	Required	Default	Description
Name	string	No	“Access Point”	Friendly display name shown in the dashboard (for example in monitoring slice pickers). Has no effect on routing.
Listen Address (Host:Port)	dropdown	Yes	—	Gateway listener this Access Point binds to. Populated from the gateway’s configured inbound addresses. Hidden when the gateway has a single inbound address, as on Affinidi-hosted gateways, and the Access Point uses that address.
Surface Prefix	dropdown	Yes	—	Route namespace prefix. Populated from the gateway’s configured surface prefixes. Combined with Custom Path to form the full route.
Custom Path	string	Yes	Auto-generated	Path segment appended to the Surface Prefix. Must not contain `..` segments.
Entry point URL	string	Read-only	Derived	The full URL callers use to reach the surface, assembled from the Listen Address, Surface Prefix, and Custom Path. Shown in a banner at the top of the panel and at the top of the canvas, with a copy button. Its help icon reads “The URL used to access this gateway”.

A2A Protocol

The A2A Protocol section appears on A2A surfaces. It sets which A2A versions callers can use with the surface and how much of each request the gateway checks before forwarding it to the managed agent.

A caller declares its A2A version in the A2A-Version request header, and a request that omits that header counts as version 0.3. The gateway refuses a request for a version outside Supported versions with JSON-RPC error -32009, whose error data lists the versions the surface accepts.

Field	Type	Required	Default	Description
Supported versions	checkboxes: A2A 0.3, A2A 1.0	Yes, at least one	Both selected	The A2A versions callers may use with this surface. Shown locked when the Managed Agent targets an A2A proxy. See A2A proxy Targets.
Message validation	dropdown	Yes	JSON-RPC envelope	How much of each request the gateway checks before forwarding it. Options are listed in the table below.

Message validation	What the gateway checks
Off	Nothing. Requests are forwarded as they are, so a batch request or a request with a missing or invalid method name reaches surface policies with no method to match. Anyone who can edit the surface in the dashboard can choose Off. An access token that uses Advanced resource scoping can choose only the other two levels.
JSON-RPC envelope	The request is valid JSON, carries `"jsonrpc": "2.0"`, and has a string `method`. Batch requests are refused. A request that fails is answered with JSON-RPC error `-32700` for invalid JSON or `-32600` for a missing or invalid `jsonrpc` or `method` field.
Envelope + A2A fields	The JSON-RPC envelope, plus the request fields A2A defines, such as the message ID, the role, and at least one message part. The method name picks the rules: `message/send` is checked against A2A 0.3 and `SendMessage` against A2A 1.0, whatever `A2A-Version` header the caller sends. The gateway refuses a request that breaks its version’s field rules, such as role `user` on `SendMessage`, with JSON-RPC error `-32602` naming the field.

Request shape checks

With the default, JSON-RPC envelope, the gateway forwards a well-formed JSON-RPC request even when its A2A fields are malformed, and your agent decides how to answer it. To have the gateway refuse such requests before they reach the agent, set Message validation to Envelope + A2A fields.

When the Managed Agent routes through a Gateway Connection (fabric://), the sending gateway applies the surface’s supported versions and message validation before the request crosses Fabric.

A2A proxy Targets

When the Managed Agent’s Endpoint Type is via A2A Proxy, the gateway fixes the surface’s A2A versions, and the Supported versions checkboxes are shown locked in every variant.

A surface created with an A2A proxy Target, or whose Target changes to an A2A proxy, accepts A2A 1.0 only. Its callers send A2A-Version: 1.0.
A surface that already targeted an A2A proxy before the appliance was upgraded to 1.0.0 can keep accepting A2A 0.3 alongside 1.0, so its existing callers keep working. The locked checkboxes show which versions it accepts, and the panel notes when it keeps 0.3.
An A2A proxy Target always checks the JSON-RPC envelope, so Message validation is shown locked at JSON-RPC envelope.
In a variant that points the Target at a URL, Message validation stays editable and applies to that variant’s Target.

The A2A proxy answers SendMessage with an A2A 1.0 reply and message/send with an A2A 0.3 reply. See A2A Proxy.

A2A surfaces only

Field	Type	Required	Default	Description
Primary extension URI	string	No	None	Primary A2A extension URI used for dashboard display and metrics grouping.
Supported extensions	string, comma-separated	No	`[]`	A2A extension URIs advertised in the agent card.
Override Agent Card Location	toggle	No	Off	When on, overrides the default agent card path.
Agent Card Location	string	No	`.well-known/agent-card.json`	Custom agent card path relative to the managed agent base URL. Shown only when Override Agent Card Location is on.

Canvas elements

These canvas elements add capabilities at the inbound pipeline stage, before a request reaches the managed agent. Each one attaches to a specific edge, either the Caller → Access Point edge (before the request reaches the Access Point) or the Access Point → Managed Agent edge itself. The Behaviour column below states each element’s actual edge; see the linked reference page for the full placement detail.

Element	Reference	Behaviour at this position
Policy	OPA policies: Policy element	Attaches to the Caller → Access Point edge as the inbound policy variant. Evaluated before the request reaches the Managed Agent.
Rate Limit	Networking elements: Rate Limit	Attaches to the Caller → Access Point edge. Inbound request cap applied at the surface entry point.
Caller Context	Caller Context reference	Attaches to the Caller → Access Point edge. Authentication method selection and per-method credential extraction configuration.
Identity	Identity element reference	Attaches to the Caller → Access Point edge for inbound caller identity, or to the Access Point → Caller response edge for protected agent identity (the managed agent’s own DID, extracted from its reply). See the linked reference for the full slot list.
Trust Check	Trust elements reference	Attaches to the Access Point → Managed Agent edge as the caller leg. Per-element TRQP verification on the caller leg. Results appear as `input.trust_check_results.caller` in OPA evaluation.
Extension Validation	Protocol extensions reference	Attaches to the Access Point → Managed Agent request edge. Schema validation applied to inbound request payloads. A2A surfaces only.
Metadata Extraction	Metadata elements reference	Attaches to the Access Point → Managed Agent request edge on A2A surfaces. Header-to-metadata mapping at the access point boundary. Disabled on MCP surfaces, where the header mapping editor does not appear.

Surface reference: Top-level surface fields, protocol options, and gateway DID injection settings.
Managed Agent reference: Upstream endpoint and authentication fields.
Control which A2A versions and messages a surface accepts: Set the A2A Protocol section for a surface’s callers.
Caller Context reference: Authentication method options and per-method credential extraction configuration.
Trust elements reference: Full field reference for Trust Check elements, query parameters, template syntax, and result wire shape.

Was this page helpful?

Glad to hear it. Thanks for letting us know.

Sorry to hear that. Thanks for letting us know.