# Frequently Asked Questions

> Common questions about protocols and integration, identity and trust, access control, federation and multi-hop routing, configuration, and deployment in Agent Gateway.
### Protocols & integration

        Beyond A2A/UCP/AP2/MCP, what other protocols or "OpenAI-style" APIs do you natively inspect/validate/route today, and what's on the roadmap?

Today, Agent Gateway natively inspects, validates, and routes MCP, A2A, UCP, and AP2 agent protocols. In addition, the gateway supports an MCP proxy feature that allows it to present an MCP server to callers and route those calls to a downstream REST API. This allows legacy systems to be exposed to agents through MCP while keeping a unified control point for policy evaluation, agent identity, and traffic shaping across those flows.

Architecturally, the gateway is designed for extensibility. New protocol families, richer streaming semantics, and deeper semantic or provenance checks can be added incrementally as the supported agent ecosystem expands.

        For each supported protocol (A2A, AP2, UCP, MCP), which features are fully supported (inspection, validation, transform, policy enforcement, observability), and which are partial?

A2A, AP2, UCP, and MCP are supported across the core gateway capabilities, including inspection, validation, routing, and policy enforcement. DIDComm v2.1 is also fully supported as the underlying fabric protocol for gateway-to-gateway communication, although this is abstracted from agents through the Agent Surface construct.

### Identity & trust

        How do you establish secure agent communication channels across organizational boundaries (identity verification, encryption, transitive trust)?

The gateway discovers the remote agent via its agent card, derives a DID from configured identity attributes, and wraps each message in DIDComm v2.1 authenticated encryption before routing it through a mediator. The receiving gateway resolves both the agent DID and the issuing gateway DID to validate the signature chain before forwarding. Binding modes include payload extraction, mTLS, API key, and OIDC/JWT claims.

[How cross-boundary identity works →](/products/affinidi-trust-fabric/agent-gateway/concepts/identity.md)

        How are agent DIDs created from a developer-defined schema, and what attributes/claims are typically encoded vs referenced?

The gateway derives a DID by hashing the identity fields you define in a schema, so any change to those fields produces a new DID while consistent values produce a consistent DID. Fields are extracted from A2A extension points or MCP _meta payloads. Alternatives include mTLS certificate identifiers, API key identifiers, and OIDC claims such as oid from Microsoft Entra ID.

[How identity is derived →](/products/affinidi-trust-fabric/agent-gateway/concepts/identity.md)

        Which DID methods are supported in practice for agent identities (for example, did:web, did:key, did:peer, did:webvh), and what are the trade-offs?

The gateway uses did:peer for gateway-to-gateway interactions and did:webvh for other identity use cases such as agent identity. did:webvh offers stronger temporal verifiability properties while maintaining the operational simplicity that enterprise customers expect.

Each DID method comes with different operational characteristics. For example, did:peer provides privacy-preserving identifiers suited for point-to-point trust, while did:webvh places more emphasis on global discoverability and structured hosting. The gateway is designed to evolve alongside your identity model, allowing you to adopt stronger methods over time without re-architecting your applications.

        What VC/VP issuance and verification capabilities exist today?

The gateway can act as both issuer and verifier using W3C Verifiable Credentials with JWT encoding and Ed25519 signatures. It creates a two-layer signature: a credential attesting to the agent’s derived identity, wrapped in a Verifiable Presentation signed with the agent’s own key. If you manage your own keys, supply a pre-signed VP and the gateway passes it through without injecting identity.

[Agent identity and DIDs →](/products/affinidi-trust-fabric/agent-gateway/concepts/identity.md)

### Access control

        How do you prevent policy gaps in multi-hop flows: what is enforced at each hop versus end-to-end, and how is identity propagated?

Each gateway injects a cryptographically signed Verifiable Presentation carrying the caller’s DID into the forwarded message. A downstream gateway independently validates the signature chain by resolving both the agent DID and the issuing gateway DID before forwarding. No hop relies on another gateway’s decision. Gateways can additionally call a trust registry over TRQP to confirm authorisation end to end.

[How cross-gateway identity and trust work →](/products/affinidi-trust-fabric/agent-gateway/concepts/identity.md)

        What is the evaluation context available to OPA policies (method/path/headers/body/identity/claims), and can policies call external data sources?

Policies can be applied to traffic flowing through an Agent Surface simply by dropping a policy element onto an edge in the Surface. The policy has access to metadata extracted by other elements in the pipeline, as well as metadata defined globally by the gateway itself.

Examples of policy context are:

```rego
package surface.policy

default allow = false

allow if {
  input.agent.trust_verification == true
}
```

Policies are defined separately from how they are configured for use, ensuring a clear separation of concerns between the policy creator and the policy enforcer. Policies are stored on the gateway and compiled at startup to ensure high performance.

### Federation & multi-hop routing

        What are the prerequisites and steps to set up multi-hop Gateway-to-Gateway routing using DIDComm v2.1 and connection points?

Each gateway needs a DIDComm v2.1 mediator and an active self-gateway record. One gateway publishes a connection point with a pre-shared secret that is shared out of band with the peer. The peer imports it via the OOB invitation workflow, the initiating gateway approves, and once active you configure a surface target to use Gateway Connection, which resolves to a fabric:// route.

[Connect two gateways →](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/connections/connect-gateways.md)

        What are the recommended reference architectures for internal network to DMZ to cloud multi-hop deployments with DIDComm mediators?

The standard baseline is a three-tier topology: an internal zone gateway enforcing HTTP/HTTPS policies, an optional DMZ gateway for perimeter controls, and a cloud-hosted DIDComm v2.1 mediator for encrypted relay. Gateways connect to the mediator via outbound WebSocket, so no inbound firewall ports are required. Agent identity propagates via Verifiable Presentations at each zone boundary, with each gateway enforcing independent policies.

### Configuration & routing

        What management roles exist (Admin/PowerUser/User) and can roles be customised?

The gateway provides three predefined roles:

- Admin: full access including user management, config changes, and policy edits.

- PowerUser: can view config, metrics, and logs, manage channels, and reload config, but cannot modify policies or users.

- Viewer: read-only access to dashboard, metrics, and logs.

Roles are customisable by the administrator using a configuration matrix that maps the gateway scope to a role. When users register in passkey mode, the administrator assigns them to one of these roles, and the user inherits that role’s permissions. When using SSO/SAML mode, the assertion must contain the role name to assign the user to, and the gateway applies that mapping automatically.

        How do Agent Surface listeners handle dynamic path matching and multi-channel routing, and what are best practices for segmentation by environment/tenant/use case? How do you test, version, and promote configurations (dev/test/prod)?

Listeners follow the structure scheme://host/route/custom/path, where route is a pre-configured namespace that separates workloads. Use separate surfaces when policy, secrets, or audit requirements differ across tenants or environments. Use variants (appending $aliasName to the URI) to test and promote configuration changes without creating new surfaces.

[Surfaces →](/products/affinidi-trust-fabric/agent-gateway/concepts/surfaces.md) [Variants reference →](/products/affinidi-trust-fabric/agent-gateway/reference/surfaces/variants.md)

        What are the supported channel targets (HTTP upstream)?

Supported targets include:

- HTTP/HTTPS upstream: for example http://backend-service:8080.

- Gateway-local MCP proxy: points to a downstream REST API.

- Affinidi Trust Fabric protocol: for gateway-to-gateway routing.

These target types let you front an in-place agent or API directly, route traffic to a remote gateway across the trust fabric, or convert an existing REST API into governed MCP tools without changing the backend itself. [Target reference →](/products/affinidi-trust-fabric/agent-gateway/reference/surfaces/target.md)

        Which secret backends are supported (for example, cloud options), and how are placeholders referenced/resolved at runtime?

Secrets are stored on the local filesystem, encrypted at rest. An aws selector for AWS Secrets Manager exists in the config model, but the filesystem-backed store is the active runtime path. Reference secrets by identifier rather than raw value in configurations, and configure log redaction rules to mask tokens, API keys, and other sensitive values before they reach any output stream.

[Secrets reference →](/products/affinidi-trust-fabric/agent-gateway/reference/authentication/secrets.md)

### Deployment & observability

        What standard metrics are emitted? Which backends are supported and what is available via OpenTelemetry?

We primarily capture Agent Surface-level spans so you can view throughput and latency for agent interactions. Standard metrics include:

- request latency (p50/p90/p99)

- success/failure counts

- timeout counts

- bytes sent/received

- active connections

- circuit breaker state

- rate limit hits

- system metrics such as CPU and memory

Prometheus/Grafana and AWS CloudWatch integrations are available. We emit via OpenTelemetry (OTEL), including spans between gateway connections. The gateway is not intended for long-term data retention: the dashboard is a point-in-time view and truncates based on time and log-size settings. For long-term storage, use your telemetry pipeline (for example Prometheus, CloudWatch, or an OTEL collector) with the retention rules you define.

        What deployment modes are supported, and what are the operational differences?

There are two primary modes: fully managed as an appliance in the enterprise’s locus of control, hosted by Affinidi; and local deployment running on your own infrastructure. In local mode, the gateway is deployed as a Docker container. Custom configurations are available for large enterprises; contact Affinidi to discuss your requirements.