# Apply policy to outbound calls > Route your managed agent's outbound calls through the gateway to apply OPA policy and trust checks to every external request it makes. Apply OPA policy and trust checks to your managed agent’s outbound calls by routing them through the gateway. A Transit Point is a surface element that registers an outbound route on the gateway. When your managed agent sends a request to the Transit Point URL, the gateway forwards it to the configured destination and applies any attached controls before it leaves. For the full routing model, see [Surface routing model](/products/affinidi-trust-fabric/agent-gateway/concepts/surface-routing-model.md). Without a Transit Point, outbound calls from the managed agent bypass the gateway entirely. They carry no policy gate and no access controls, regardless of what is configured on the inbound surface. You have no visibility into what the agent called, when, or whether it succeeded. Add a Transit Point when: - Your managed agent makes outbound calls to external services while handling inbound requests. - You want OPA policy or trust-registry checks applied to those outbound calls. - The destination requires credentials that you want the gateway to inject, so the agent does not hold secrets directly. - You want outbound call traffic to appear in the gateway’s OTEL traces alongside inbound calls. You do not need a Transit Point if your agent only receives calls and makes no outbound requests. This guide covers A2A and MCP surfaces. The only differences are the template you select in Step 1 and the palette element you drag in Step 3. ## Prerequisites - You are logged in to the Trust Gateway dashboard. - You have permission to create and edit surfaces. - At least one outbound listener is configured on the gateway. Transit Points are registered on the outbound listener, which is on a separate port from the inbound listener. Without an outbound listener, Transit Points cannot serve traffic. - You have the URL of the external destination the managed agent will call through the gateway. This must be a URL the gateway can reach from the outbound listener. - The managed agent runs as an external service with its own inbound URL. The managed agent target endpoint (where the gateway forwards inbound traffic) and the Transit Point destination (where the managed agent sends outbound calls) are two different things. Do not point the managed agent target at any URL on this gateway. - If you plan to set target authentication on a Transit Point, the secret must already exist in the gateway secrets store. ## Steps Create a surface If you already have a surface to add Transit Points to, skip to Step 2. - Open Surfaces in the dashboard. - Select Add Surface. - In Start a new surface, select the starter template that matches your protocol. - For an A2A surface, select an A2A starter template. - For an MCP surface, select an MCP starter template. The template selection sets the surface protocol. There is no separate protocol picker. - Optionally update the surface name in the Surface panel on the right. The name is auto-generated from the template and does not need to change unless you want something specific. The canvas opens with two elements created automatically. - Access Point: the inbound entry point where callers reach the managed agent. - Managed Agent: the upstream destination where the gateway forwards inbound traffic. Elements with animated red outlines still require configuration. Configure the core elements Complete the required configuration for the Access Point and Managed Agent before adding Transit Points. ### Access Point - Select the Access Point node on the canvas. - In the Listener section, set the following fields. - Listen Address (Host:Port): select the inbound listener address from the dropdown. - Channel Prefix: select the path prefix for this gateway (for example, /agents). - Custom Path: the auto-generated two-word path is ready to use as-is, or type your own path segment. The full composed route is shown above the section as the Channel Route. - For A2A surfaces, optionally complete the A2A Extensions section if required by the managed agent. ### Managed Agent - Select the Managed Agent node on the canvas. - Set Target Endpoint to the external URL of the managed agent service (for example, https://my-agent.example.com/api). This is where the gateway forwards inbound traffic. Do not create a routing loop Do not set the managed agent target endpoint to a URL on this gateway, including a Transit Point URL on the same gateway. If you do, inbound requests arrive at the gateway’s inbound listener, which has no route for Transit Point paths and returns a 404. Keep the managed agent target pointed at an external service. Add a Transit Point - Open the element palette on the left side of the canvas. - In the Transit Points palette category, drag the element that matches your surface protocol onto the canvas. - For A2A surfaces, drag Transit Point (A2A). - For MCP surfaces, drag Transit Point (MCP). The canvas places it at the egress edge of the surface. You can add multiple Transit Points on the same surface. Each one becomes a separate outbound route with its own configuration. Configure the Transit Point Select the Transit Point node to open its config panel. ### 4.1 Set the outbound listener Under Listener URL in the config panel, set the following fields. - Listen Address (Host:Port): select the outbound listener address from the dropdown. This must be the outbound listener, which runs on a separate port from the inbound listener. Your managed agent sends outbound requests to this address. - Channel Prefix: select the path prefix for the outbound listener. - Custom Path: the auto-generated two-word path is ready to use as-is, or type your own path segment. The composed URL is shown above the section as the Listener URL. When no custom path is set, the gateway registers the Transit Point at: ```text https:///outgoing// ``` When a custom path is set, the gateway registers the Transit Point at exactly the composed path (no alias is appended). For example, if the channel prefix is /routes and the custom path is /blitz/organic, the Transit Point URL is: ```text https:///routes/blitz/organic ``` The managed agent must call this exact URL. Do not append the alias. Caution The path must not contain .. segments. Two Transit Points on the same surface cannot share the same composed path. ### 4.2 Set the name Set Name to a descriptive label for this Transit Point. The gateway derives the routing alias from the name automatically. The alias is shown as a read-only hint below the name field. The alias must be URL-safe: lowercase letters, digits, and hyphens only, starting with a letter, maximum 63 characters. It appears in the outbound URL path and in metrics labels. Keep names descriptive so the alias is meaningful in logs and dashboards. ### 4.3 Set the destination In the Destination section, choose the endpoint type. Direct URL: type the full HTTPS target URL (for example, https://partner-agent.example.com/a2a). Use this for any publicly reachable HTTP or A2A endpoint. Via Gateway Connection: select a connected gateway from the dropdown, then select one of its published surfaces. The gateway constructs a fabric:// endpoint internally and routes traffic through the Gateway-to-Gateway fabric. This option is not covered in this guide. See [Connect gateways](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/connections/connect-gateways.md) for that flow. For A2A and AP2 Transit Points, an Agent Card section is also shown. By default, the gateway fetches the destination’s agent card from /.well-known/agent-card.json at the destination origin. Select Override Agent Card Location and enter a custom path if the destination serves its agent card at a different path. ### 4.4 Set target authentication (optional) If the external destination requires credentials, configure Target Authentication. Select a method from the dropdown. - Bearer Token: injects a Bearer value into the Authorization header. Enter the secret reference from the secrets store. - API Key Header: injects the secret into a named header. Enter the header name and the secret reference. - Custom Header: inject the secret into any header with a configurable format. Use {value} as the placeholder for the secret value in the header format field. When a method is selected, also choose the Fallback when secret missing behaviour. Reject (502) stops the request if the secret is unavailable. Passthrough forwards the request without the credential. Note OAuth Client Credentials is not yet supported. Selecting it in the dropdown has no effect and the selection is dropped on save. ### 4.5 Set the transit token requirement The Security section contains a Require transit token toggle. When enabled (the default), every outbound call to this Transit Point must carry the X-Transit-Token header issued by the gateway during the inbound pipeline. See [Surface routing model: the transit token](/products/affinidi-trust-fabric/agent-gateway/concepts/surface-routing-model.md#the-transit-token) for how it works. In your managed agent code, read the header from the inbound request and attach it unchanged to the outbound call: ```js app.post('/your-agent-path', async (req, res) => { const transitToken = req.headers['x-transit-token']; // ... process the request ... const result = await fetch(' - ', { method: 'POST', headers: { 'Content-Type': 'application/json', 'X-Transit-Token': transitToken // pass through unchanged }, body: JSON.stringify(a2aMessage) }); }); ``` Disable this toggle only during development or in deployments where the managed agent cannot carry the token. Apply policy and access controls Routing calls through a Transit Point makes them visible in the gateway’s OTEL traces automatically. Use the controls below to add explicit policy gates and trust checks scoped to this destination. Drop them onto the Transit Point node or its connecting edges from the palette. Controls attached to a Transit Point are scoped to that Transit Point only and do not affect the inbound pipeline. ### Policy A Policy element on a Transit Point runs an OPA Rego evaluation before the request is forwarded to the Transit Point destination. - From the Security & Policy palette category, drag Policy onto the Transit Point node or its edge. - Select a policy definition from the dropdown in the config panel. To also evaluate a policy on the response coming back from the Transit Point destination, drop a second Policy element on the response edge of the Transit Point. ### Networking A Networking element on a Transit Point sets per-hop resilience settings: request timeout, retry behaviour, and circuit-breaker threshold. - From the Enhancements palette category, drag Networking onto the Transit Point. - In the config panel, configure the settings relevant to this destination. - Timeout: set the request timeout and, optionally, the connect and idle timeouts. - Retry: set the maximum retry attempts, backoff parameters, and which HTTP status codes trigger a retry. - Circuit breaker: set the failure threshold and recovery timeout. ### Rate Limit A Rate Limit element caps the number of outbound calls through this Transit Point per time window. - From the Enhancements palette category, drag Rate Limit onto the Transit Point. - Set Request limit and Time window (seconds) in the config panel. ### Trust Registry A Trust Registry element on a Transit Point runs a trust-registry check against the destination before forwarding the request. - From the Security & Policy palette category, drag Trust Registry onto the Transit Point edge. - Select the trust registry action and configure the check parameters. ### Metadata A Metadata element injects fixed key-value pairs into requests or responses passing through the Transit Point. - From the Enhancements palette category, drag Metadata onto the Transit Point or its edge. - Add key-value entries and select the injection target: header, extension, or body. Save the surface Save the surface by selecting Save or pressing Cmd+S (macOS) / Ctrl+S (Windows/Linux). The gateway applies the new configuration immediately through hot reload. ## Confirm Use the Elements tab in the surface editor to check whether all elements are fully configured. A complete element shows no warning indicator. Elements shown with an amber or red state still require input. To inspect the full JSON of the surface, open the Config tab. Each configured Transit Point appears as an entry in transit.points[]. Confirm the following for each entry. - The alias field is non-empty and starts with a lowercase letter. - The target_endpoint field contains a valid external URL. - The listen_address field matches a configured outbound listener address on this gateway. To test the outbound route, configure the managed agent to send A2A requests to the Transit Point listener URL. Find the exact URL in the dashboard: open the Transit Point config panel. The Listener URL banner at the top of the listener section shows the complete URL (host, port, and path) exactly as the managed agent should call it. This is the authoritative value. Do not construct the URL manually. The URL pattern for reference: Default (no custom path): ```text https:///outgoing// ``` Custom path (Channel Prefix + Custom Path): ```text https://// ``` The managed agent must include the X-Transit-Token header on outbound calls unless Require transit token was disabled. ### Confirm the Transit Point route is registered To confirm the outbound route is active without a managed agent, call the Transit Point URL directly. Get the URL: open the Transit Point config panel in the dashboard. The Listener URL banner shows the complete URL: host, port, and path. Copy it from there. The body below uses A2A format. For MCP surfaces, replace the body with an MCP request such as {"jsonrpc":"2.0","method":"initialize","id":1,"params":{"protocolVersion":"2024-11-05","clientInfo":{"name":"test","version":"1.0"},"capabilities":{}}}. ```bash curl -k -X POST " - " \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","method":"message/send","id":"test-tp","params":{"message":{"role":"user","messageId":"msg-001","parts":[{"kind":"text","text":"test"}]}}}' ``` The -k flag disables TLS certificate verification. Use this for local testing only. Remove it in production. Expected responses: - 401 with a transit token error → the route is registered and working. In production, the managed agent must include the X-Transit-Token header it received from the gateway’s inbound forwarded request. - 404 No route configured for path: ... → the Transit Point route is not found. Check that the URL is the Listener URL value from the dashboard (not the inbound listener URL), and that the surface was saved. Do not call the Transit Point URL using the inbound listener address. Transit Point routes are only available on the outbound listener. ## Troubleshooting | Symptom | Likely cause | Fix | | The Transit Point node has a red border after filling all fields. | The Listen Address (Host:Port) selection is not a configured outbound listener on this gateway. | Select a valid outbound listener from the Listen Address (Host:Port) dropdown in the Listener URL section. | | Gateway returns 404 No route configured for path: ... on an inbound request. | The managed agent target endpoint points back at this gateway (routing loop). The inbound listener has no route for Transit Point paths. | Set the managed agent Target Endpoint to an external service URL, not a URL on this gateway. | | Outbound calls from the managed agent return 404. | The managed agent is sending to the inbound listener port instead of the outbound listener port, or it is appending the alias to a custom listen_path. | Confirm the managed agent is calling the URL shown in the Listener URL section of the Transit Point config. When a custom path is set, the Transit Point is at exactly that path. Do not append the alias. | | Managed agent target endpoint set to the Transit Point URL returns 404 on inbound calls. | The managed agent target and the Transit Point are on separate listeners. The inbound listener does not serve Transit Point routes. | The managed agent target must be an external service URL. The Transit Point URL is for the managed agent to call outbound, not for the inbound pipeline to forward to. | | The alias field shows an error on save. | The name was slugified into a string that starts with a digit, or the resulting alias is empty. | Edit the name so it starts with a word beginning with a letter. The alias updates automatically. | | Two Transit Points on the same surface produce a duplicate path error. | Both Transit Points resolved to the same alias, or both have the same composed path. | Rename one Transit Point so the aliases differ, or change the custom path on one. | | Outbound requests are rejected with a transit token error. | The managed agent is not sending the required X-Transit-Token header. | Ensure the managed agent includes the transit token issued by the gateway’s inbound response, or disable Require transit token in the Security section during development. | | The Via Gateway Connection dropdown shows no surfaces for the selected gateway. | No A2A surfaces are published on the remote gateway. | On the remote gateway, confirm the target surface is active and uses the A2A protocol. | ## Next steps - [Surface routing model](/products/affinidi-trust-fabric/agent-gateway/concepts/surface-routing-model.md): understand how Access Point, Target, Transit Point, and Listener relate to each other. - [Apply OPA policies to your gateway and surfaces](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/policies/apply-opa-policies.md): apply OPA policies at gateway and surface level. - [Agent validation via a trust registry](/products/affinidi-trust-fabric/agent-gateway/how-to-guides/connections/agent-validation-via-trust-registry.md): combine agent identity, OPA policies, and trust-registry checks across inbound and outbound flows.