A2A Gateway
Overview
A2A (Agent2Agent) is an open protocol that lets AI agents from different providers exchange tasks over a standard interface. In Apinizer, A2A is a first-class API proxy type — you create an A2A Gateway the same way you'd create a REST, SOAP, or LLM Gateway, and configure its behavior on its Routing tab. An A2A Gateway works in one of two directions (the Routing Mode setting):
- Expose an agent from Apinizer (this page calls it Expose Agent) — the proxy publishes itself as an A2A agent, backed directly by its own LLM configuration
- Forward to an external agent (this page calls it Passthrough) — the proxy forwards tasks through to an external A2A agent, applying skill filtering and agent-card rewriting along the way
The A2A Gateway menu item takes you to a card-based list of your A2A Gateways, the same layout used for LLM Gateways — open a card to reach that proxy's routing, policies, and trace/traffic/analytics/tasks tabs.
Coming from an older release? A2A used to be configured on a separate "Inbound Agent" screen with its own authentication settings, reachable at a dedicated path. That model has been replaced entirely — see Migrating from the Previous Model. New to agent-to-agent concepts? See AI Fundamentals for a primer.
Quick Start
Create a new A2A Gateway the same way you'd create any other API proxy: give it a name and a single client-facing path.
Open the proxy's Routing tab and set Routing Mode to Expose an agent from Apinizer or Forward to an external agent.
For Expose Agent, choose the LLM target in the LLM sections of the same Routing tab (required before you can save) and describe the agent's skills there. For Passthrough, add one or more external agents directly on the tab (endpoint and authentication) and, optionally, restrict which of their discovered skills are advertised.
Attach any of Apinizer's regular authentication policies (API Key, JWT, OAuth2, ...) to the proxy — the same way you would on any other proxy type.
Deploy the proxy. Its client path becomes the single endpoint A2A clients connect to, for both discovery and task submission.
Point an A2A client at the proxy's path — it fetches the agent card from the standard discovery path, then sends tasks over that same path.
Modes
Expose Agent
Selected as Expose an agent from Apinizer. An Expose Agent proxy is the agent — there's no separate backend proxy reference to configure. Its LLM backend is the proxy's own AI Routing configuration, and the five guardrail policies — Personal Data Masking, Prompt Protection, Data-Loss Protection (DLP), Off-Topic Protection, and Retry-Storm (Loop) Protection — apply to A2A traffic the same way they do on a regular LLM Gateway. LLM-Gateway-only policies (Semantic Cache, Token Rate Limit, Prompt Decorator, Prompt Templates, RAG Injection, Context-Integrity Protection) are not available here, even in Expose Agent mode — see Guardrail Policies below.
Passthrough
Selected as Forward to an external agent. Forwards tasks to an external agent, defined directly on the proxy's Routing tab — rewriting the fetched agent card (hostname, advertised authentication scheme, and skill list) before handing it to the caller.
Once an agent's endpoint is saved, Apinizer fetches and previews its agent card automatically.
Leave it empty to advertise every discovered skill, or restrict which ones this proxy exposes.
Each agent is probed periodically and reports Healthy, Down, or Unknown status with its last response time.
Discovery and task calls reach only public https addresses unless you turn on Allow private-network egress — see Security and Governance.
A2A Agents Are Configured Inline
There's no standalone "A2A connection" screen to visit first — an external agent is defined at the exact place it's used:
- On a Passthrough proxy's Routing tab, where it can be one of several aggregated agents for discovery (see Multi-Target Aggregation).
- Inside the A2A Call (LLM) / A2A Call (Fixed) policy, as a single agent a model delegates a sub-task to as part of any LLM Gateway's own tool-call loop — no A2A Gateway required for that path at all.
Each definition carries its own endpoint, authentication (see Outbound Authentication), discovered skill catalog, health status, and approved-catalog fingerprint. Nothing is shared by reference between proxies or policies.
The endpoint you enter is the address tasks are sent to — enter the agent's task base URL, not its card URL. The agent card is looked for at that address first, and if the card isn't served there, at the standard discovery path below it (.../.well-known/agent-card.json). Entering a card URL directly (.../.well-known/agent-card.json) works for card discovery but breaks task sending, because tasks are POSTed to the same configured URL.
Applying a Backend Agent: Apply to List → Save → deploy
You add or edit a backend agent in the drawer that opens from the right of the row. The drawer's Apply to List button writes the change to the table only — nothing reaches the server at that step. To persist it you must press the Save button at the bottom of the tab; while unsaved changes exist a warning sits at the top of the tab, and it clears only once the save succeeds. The order is: Apply to List → Save → deploy. Skip the middle step and the table shows the new agent while the gateway keeps serving the old configuration.
The gateway always serves the last deployed configuration. Saving the Routing tab does not by itself change what callers see; backend agents, the published skill catalog and the routing mode reach clients only after you redeploy the proxy to that environment. When saved-but-undeployed changes exist, a warning banner naming the affected environments appears at the top of the Routing tab, and the deploy button at the top of the page switches to Redeploy so both indicators agree.
Outbound Agent Call
When you want to send a task from Apinizer to an external A2A agent, the component that actually delivers it is the A2A Call (LLM) policy, attached to an LLM Gateway's response flow. As with Passthrough mode, the target agent is defined inline, on the policy's own screen. For a fixed, admin-chosen skill dispatch that runs on the request or error flow instead — see A2A Call (Fixed) below.
Attach the A2A Call (LLM) policy to an LLM Gateway's response flow.
In the A2A Agent (Inline) section, enter the endpoint, authentication, and mTLS settings if required.
The Discover / Reparse Skills button connects to the agent, fetches its agent card, and confirms its skill list — it runs before you save, so there's no separate "test connection" step.
Leave it empty to allow every discovered skill; to restrict, pick from the Allowed Skills list.
This agent definition is subject to the same SSRF protection as Passthrough mode (see Security and Governance). The policy screen's A2A Connection field is kept for backward compatibility: it's disabled once an inline agent is defined, and only one of the two is ever used at runtime.
This policy can also be added and updated through the APIops REST API — see API Reference: Policies.
A2A Call (Fixed)
The A2A Call (Fixed) policy dispatches a task to a fixed, admin-chosen skill on an external A2A agent, independently of the model. Unlike A2A Call (LLM), it does not wait for the model to produce a tool call — it runs in the request flow or the error flow of any proxy type.
| Field | Description |
|---|---|
| Target Skill | The skill to invoke, selected from the agent's discovered skill list. A skill not in the catalog is rejected fail-closed. |
| Message Template | The message body sent to the agent. ${VARIABLE_NAME} environment variables are resolved first; #{...} context variables next. |
| Wait Mode | Fire and Forget (default) — dispatches asynchronously without blocking the flow. Sync to Variable — waits for the result and writes it to the named output variable. |
| Output Variable Name | Required only when Wait Mode is Sync to Variable. |
| Call Timeout (ms) | Per-send HTTP timeout. Default: 30 000 ms. |
| Task Wait Timeout (ms) | Total polling budget for the async task wait loop. Default: 60 000 ms. |
Failure behavior. Two failure categories apply:
- Configuration problems — inline agent not configured, target skill blank or its environment variable unresolved, skill absent from the catalog, or the caller's identity denied by access rules — block the request with HTTP 500 / ERR-286.
- Dispatch failures — timeout, remote agent error, or a transport failure — are logged only and never block the request or error flow. In Sync to Variable mode the output variable stays empty; check it before using it downstream.
The agent result is written to the output variable without personal-data masking.
This policy can also be added and updated through the APIops REST API — see API Reference: Policies.
Outbound Authentication
An A2A agent row of a Passthrough proxy and the inline agent of the A2A Call policies use the same authentication schemes as an MCP server. See Backend Authentication for the schemes (None, Bearer, OAuth2 Client Credentials, mTLS, API Key (Header), Basic Authentication and OAuth2 Token Exchange), the token exchange rules and the Discover Auth button.
Differences for A2A:
- Discover Auth reads the agent card from the endpoint you entered, and then from its
/.well-known/agent-card.jsonaddress. It suggests the scheme from the security schemes of the card, and accepts both the flat form and the A2A 1.0 form. A note appears when the card cannot be read. - When a call with a token exchange token gets 401 or 403, the gateway does not try again.
- Discover / Reparse Skills and the health check cannot get an exchange token, because they carry no caller token. The card read is refused for that scheme.
Agent Card, Task Lifecycle, and Streaming
Agent Card
Every A2A Gateway publishes a self-describing agent card, unauthenticated, at the proxy's client path plus /.well-known/agent-card.json — required so a client can discover the agent before it has credentials. The card includes the agent's name, description, skills, and supported input/output modalities, plus the authentication the proxy requires, derived automatically from the proxy's own authentication policies (see Security Schemes in the Card) — an unauthenticated proxy's card advertises no scheme at all. There's no separate per-agent auth-mode selector anymore, and the card can never claim a scheme the gateway doesn't actually enforce. An authenticated client can also fetch the same card over the JSON-RPC channel.
In Passthrough mode the rewritten card's documentationUrl advertises this proxy's own full gateway address — the environment's access URL, the Apinizer root context, and the proxy's client path — rather than the backend agent's, so a client that follows it reaches the gateway. On an environment with no access URL configured the field is root-relative — the Apinizer root context plus the proxy path; where neither is configured it falls back to the proxy path on its own.
Security Schemes in the Card
The card describes the authentication chain of the proxy in the A2A 1.0 form. Each scheme keeps the older flat fields (type, scheme) that earlier cards already had, so a client that reads the old form sees what it saw before. A 1.0 client uses the new form.
| Authentication policy | Scheme in the card |
|---|---|
JWT or OAuth2 policy that uses a token from the Apinizer Credential authorization server (/credential/...) | An OAuth2 flow to the token endpoint of the Credential authorization server. The flow is always client credentials, because each consumer has its own grant. When the token URL is https, the scheme also names the metadata address (RFC 8414) of that server. |
JWT or OAuth2 policy that issues tokens from its own endpoint (/auth/..., managed by the policy) | An OAuth2 flow to that endpoint with the grant of the policy (this can be password). |
Policy that issues JWT tokens (the /jwt endpoint) | A bearer (JWT) scheme. The card names no RFC 8414 metadata address, because that metadata does not lead to this token format. |
| OpenID Connect policy with an https issuer (the provider mode included) | An OpenID Connect scheme with the discovery address of the issuer. |
| OpenID Connect policy without an https issuer | A bearer (JWT) scheme. There is no OAuth2 fallback. |
| Policy that does not accept a Bearer header | No token scheme. |
| JWT policy that only validates tokens from another issuer | A bearer (JWT) scheme. |
| Basic or Digest | An HTTP scheme (basic or digest). |
| API key | An API key scheme with the location and the name of the key. |
| Bearer API key | An HTTP bearer scheme. |
| mTLS | A mutual TLS scheme. |
- The chain is additive: every policy runs. The card holds one security requirement that names all schemes, on the card and on every skill.
- A policy that no A2A client can satisfy as it is does not appear in the card.
- In Passthrough mode the card of the backend agent is rewritten. The skills carry the requirements of the gateway, not the ones of the backend agent, because the client authenticates to the gateway.
Protected Resource Metadata
Every A2A Gateway also answers an unauthenticated GET at the proxy's client path plus /.well-known/oauth-protected-resource (RFC 9728). The document names the resource and the authorization server that issues the tokens, so a client can find where to get a token.
The gateway publishes the document only when all of these are true:
- At least one active authentication policy guards the proxy, and every one of them accepts a Bearer token from one authorization server (the Apinizer Credential authorization server, or one identity provider).
- The environment has an access URL.
- The issuer of that authorization server is an https address.
- The chain does not use JWT tokens of the Apinizer Credential authorization server. Its metadata leads to opaque tokens, so the gateway does not publish the document for this format.
In every other case the address answers 404 with no body. Examples: a policy that issues proxy key tokens, tokens from more than one authorization server, a JWT policy and an OAuth2 policy in the same chain, a policy that asks for a credential that is not a token, or a policy that does not verify the JWT signature locally.
This is discovery information only. The A2A Gateway has no sign-in profile, and the token check and the 401 answer work as before. The document is shown on the Discovery card of the Routing tab.
Client ID metadata documents (CIMD) and public-client registration are not part of this release. The gateway does not advertise them. A client registers with the authorization server that issues its tokens: with the identity provider, or with the Credential authorization server as a confidential client. A client_id in the form of an https URL is refused as an unregistered client (invalid_client).
Discovery Card
The Routing tab has a read-only Discovery card. It shows, for one environment of the proxy:
- the Agent card URL,
- the Protected resource metadata URL, or the reason why the gateway does not publish it,
- the Authorization server (the issuer, and whether it is the Apinizer Credential AS or an identity provider).
You cannot change anything on the card. It uses the same rules as the gateway, so "Not published" on the card means that the gateway answers 404.
Protocol Version
The only A2A protocol version Apinizer speaks is 1.0 (the field is kept for a future version expansion) — unlike MCP, there's no version to choose.
Task Submission and Lifecycle
A client starts a task with SendMessage. In Expose Agent mode Apinizer accepts it and returns a task ID immediately, then works it in the background; in Passthrough mode the backend agent creates and owns the task, and its answer — task ID included — is returned to the client unchanged.
| State | Meaning |
|---|---|
| Submitted | Received, processing not yet started |
| Working | Being processed |
| Completed | Finished successfully |
| Failed | Ended with an error |
| Canceled | Canceled before completion |
In Expose Agent mode, Apinizer's own agent only ever advances a task through submitted → working → completed / failed / canceled / rejected. The remaining two states (input-required, auth-required) are never produced by Apinizer's own agent — they can only be observed on external agents Apinizer talks to as an outbound client.
A client polls status with GetTask, lists a proxy's tasks with ListTasks, and can cancel an in-progress task with CancelTask — cancellation actually interrupts the task's processing on the worker, not just its recorded status.
When the gateway answers CancelTask from its own task records (Expose Agent mode, and the tasks that a Passthrough proxy tracks itself), a task that is already in a terminal state (completed, failed, canceled or rejected) gets the JSON-RPC error -32002 (TaskNotCancelableError) with the message "Task cannot be canceled: it is already in a terminal state or not cancelable.". It does not return the task as a successful result any more. A second CancelTask on a task that was canceled already gets the same error, and the task stays canceled. The same error returns when the task finishes or is canceled at the same moment as your call. If the cancel cannot be completed for another reason, the answer is a JSON-RPC internal error with the message "Task could not be canceled, try again.".
In Passthrough mode the backend agent owns the tasks it creates, so GetTask and CancelTask resolve in two steps: the proxy first looks for a task it tracks itself (a streaming relay is tracked by the gateway), and if the ID isn't one of those, the call is forwarded to the backend agent and its answer is returned as-is — including its own "task not found" if the ID is unknown there too. This is what lets a client poll the exact task ID a Passthrough SendMessage returned. Whether a given task ID may be read or canceled is decided by the backend agent, the same way it decides authorization for a delegated message. ListTasks and SubscribeToTask always answer from the gateway's own task records and are not forwarded; on a proxy that aggregates more than one agent, GetTask and CancelTask return an error rather than guessing which agent owns the task.
The gateway's own task records are automatically cleaned up some time after reaching a terminal state (completed/failed/canceled/rejected); active tasks are retained indefinitely. A task created by a non-streaming Passthrough call is retained for as long as its backend agent keeps it.
Streaming
A client can request streaming task updates with SendStreamingMessage, delivered over Server-Sent Events. If the connection drops, SubscribeToTask replays the task's stored history so the client can pick up from where it left off.
Push Notifications
For long-running tasks, a client can register a webhook with CreateTaskPushNotificationConfig — Apinizer calls it (with an authentication token) once the task reaches a terminal state, so the client doesn't have to keep a connection open or poll for the result.
Multi-Modality Task Parts
A task can carry parts beyond plain text — image and structured data parts are also supported.
Supported task part types are text, structured data, and image. Audio and video are not covered.
Multi-Target Aggregation
A Passthrough proxy can aggregate up to 10 agents on its Routing tab behind one endpoint, but only for discovery: their skills are merged into a single advertised agent card, with a colliding skill name resolved deterministically the same way MCP tool names are. Sending an actual task is different — the A2A protocol gives a message no field to say which agent it's meant for, so once more than one agent is configured, SendMessage returns an explicit error rather than guessing which agent should receive it. Configure more than one agent only if you want a combined skill catalog for discovery; keep exactly one agent if you intend to actually delegate tasks through the proxy.
Security and Governance
Authentication
Same model as MCP: whatever policy chain you attach to the proxy. The agent-card discovery endpoint and the protected resource metadata address are exempt from it by design.
Identity-Based Access Control (Passthrough discovery only)
In Passthrough mode, you can restrict which skills the proxy advertises to a given consumer or API client, role, or organization — a caller not covered by any rule sees no skills once at least one rule is configured. This narrows what appears in the agent card, not what a SendMessage call is allowed to do: the A2A wire message carries no per-call skill identifier, so — unlike MCP's per-tool-call enforcement — this can't gate an individual task at call time; actual authorization for a delegated message is up to the backend agent. In Expose Agent mode this setting isn't applied at all. You set the rules in the Identity Access Rules area of the Passthrough settings on the Routing tab, or through the API.
Limiting Task Volume
The A2A routing has no call quota of its own. Limit SendMessage volume for an identity (per consumer, API client, application or organization) in a Limit Plan. Protect the proxy against the total of all callers with the Quota or Throttling policy.
A callQuota value saved by an earlier version is ignored, and the next save of the routing removes it.
Catalog Drift Protection
The same mechanism as MCP, applied to an inline agent's advertised skill list instead of a tool catalog: a fingerprint is captured at the last approved discovery (an explicit Discover / Reparse Skills, or the first discovery at deploy — see Catalog Discovery at Deploy), a periodic health check compares the live card against it, and drift either logs and surfaces a warning (the default) or blocks task delegation through that agent until it's re-approved.
Catalog Discovery at Deploy
An inline agent of an A2A Call (LLM) or A2A Call (Fixed) policy that has no skill catalog and no approved fingerprint yet gets its first catalog when you deploy the proxy.
- On deploy, the Manager reads the agent card of the agent once, before the worker receives the proxy.
- All probes of one deploy run in parallel. One total time limit of 30 seconds applies to the whole deploy.
- A successful first result is saved as the skill catalog and becomes the approved baseline. Later changes are checked against it (see above).
- An agent that already has a catalog or an approved fingerprint is not probed again. A drift that was detected is not approved by a deploy.
- An agent that returns no skills, cannot be reached, or does not answer within 30 seconds does not stop the deploy. The deploy result shows a WARNING line for it, and its calls stay refused until a catalog is discovered. Use Discover / Reparse Skills and deploy again.
- An agent whose authentication scheme is OAuth2 token exchange is not probed at deploy. There is no caller token at deploy time, and the scheduled A2A health check skips it for the same reason. No WARNING line is written for it. Use Discover / Reparse Skills to get its skill catalog.
- The agents in the Routing tab of a Passthrough proxy are not probed at deploy.
Response Flow Only
The A2A Call (LLM) policy acts on the tool calls that the model returns. These calls exist only in the response. For this reason the proxy accepts this policy, and the MCP Call (LLM) policy, only in the response flow. The platform names them "A2A Agent Call" and "MCP Tool Call" in the error. A save that puts one of them in the request flow or the error flow is rejected with the message "MCP Tool Call and A2A Agent Call policies can be placed only in the response flow". The check covers proxy-level and method-level flows and policy groups, and it applies to every save path, including the APIops REST API and import. The platform does not move the policy to another flow for you. The A2A Call (Fixed) and MCP Call (Fixed) policies are not part of this check.
Token Passthrough
The same opt-in model as MCP: off everywhere by default. Forwarding the caller's own token to a backend agent requires explicitly enabling it on the agent's definition, optionally restricted to an allow-list of accepted audiences, with the agent's own credential resolution skipped once a forward succeeds.
Guardrail Policies
Five of Apinizer's Advanced Guardrails — Personal Data Masking, Prompt Protection, Data-Loss Protection (DLP), Off-Topic Protection, and Retry-Storm (Loop) Protection — can be attached to an A2A Gateway, in both Expose Agent and Passthrough mode, the same way as on any other proxy type. They run through the proxy's regular policy chain and scan the JSON-RPC message parts (params.message.parts[]) on the request side and the task/message result envelope on the response side. Two of these five — Prompt Protection and Off-Topic Protection — can additionally call out to an external LLM judge for a second opinion, the same way they do on an LLM Gateway. The remaining AI policy types (Semantic Cache, Token Rate Limit, Prompt Decorator, Prompt Templates, RAG Injection, Context-Integrity Protection) depend on an actual LLM invocation and are rejected if you try to attach them to an A2A Gateway; see Advanced Guardrails: MCP and A2A Gateways.
Egress Protection
Outbound A2A calls — agent-card fetch, task submission, health probes, and push-notification dispatch — accept only https and refuse every private or reserved address (loopback, link-local, cloud metadata, carrier-grade-NAT, multicast, RFC1918, IPv6 ULA) by default.
The Allow private-network egress setting on an agent definition lifts this for that agent. For push notifications the same protection is lifted by Allow cluster-internal push egress on the proxy's Routing tab. Only a system administrator can turn either one on. When one is on, no address class is blocked — loopback, link-local, the cloud metadata address 169.254.169.254, 100.64.0.0/10, 0.0.0.0/8, multicast, RFC1918 and IPv6 ULA are all reachable, and plain http is allowed. Turning it on also opens the cloud metadata address, so enable it only for trusted agents.
Push webhook URLs are sent by the calling client. With the push egress setting on, a caller can point a webhook at loopback or the metadata address, so enable it only if every client that can call the agent is trusted.
Even with it on, only http and https URLs are accepted, the URL must be valid, the host must resolve, and the connection is pinned to the resolved addresses (DNS rebinding defence).
This same protection is shared with MCP Gateway outbound calls.
Environment Variables in Configuration
Most of the text you type into an A2A Gateway's configuration accepts an environment variable reference in ${VARIABLE_NAME} form, resolved per environment when the proxy runs — so one configuration moves from test to production without being edited.
Fields that accept a variable:
| Where | Fields |
|---|---|
| Outbound agent call | Skill name, message template |
| Access rules | Allowed skill list, identity rule consumer/role/organization name, allow and deny lists |
| Token passthrough | Accepted audience list |
The message template additionally accepts #{...} context variables, evaluated per request after the environment variables have been substituted.
Resolution is fail-closed, exactly as on the MCP Gateway: an undefined variable leaves the text as written, which matches no real skill or audience, so the call is denied instead of falling through to an unintended match — and a caller cannot send the literal text ${VARIABLE_NAME} as a skill name to slip past an access rule.
Push notification settings are the one deliberate exception: the webhook address and its token come from the calling client at runtime, not from an operator, so they are always treated as literal text. Resolving them would let a caller ask the gateway to place one of its own environment values into a webhook it controls.
Logging and Analytics
Every A2A call is recorded in your traffic logs with the request's correlation ID, so a delegated task can be followed end to end; an inbound gateway request additionally records the task ID, context ID, and current task state. Full per-call detail for an outbound delegation — which agent it resolved to, skill, duration, and outcome — is captured in the request's trace execution detail rather than as flat log columns. These calls also appear in trace groups alongside the rest of a request's chain, and roll up into your usage reports.
An A2A Gateway's own detail page carries this same trace/traffic/analytics view under its Trace, Traffic, and Analytics tabs — plus a Tasks tab where you can browse in-flight and historical tasks without leaving the proxy. The tab lists the tasks the gateway itself tracks: every Expose Agent task, and a Passthrough task created by a streaming call. A task created by a non-streaming Passthrough call belongs to the backend agent, so it is visible in the traffic log but not in this tab — and a client's GetTask for it is answered by that agent (see Task Submission and Lifecycle).
Outbound Agent Calls: an Audit Trail Independent of Trace
Which outbound agent(s)/skill(s) a request tried to reach is also recorded on the main traffic log row itself, regardless of whether trace is on or off — unlike the rich per-call detail above, this record never disappears just because trace is disabled (the default). Every outbound agent call dispatched during the request is tracked through two fields:
- A deduplicated name list — since a skill name is an optional field in A2A, a call with no skill name falls back to the agent key instead (an empty list with a non-zero counter would be a broken audit trail). Repeated names within the same request are kept once, in first-seen order, comma-separated; capped at 256 characters, and a name is never cut mid-string — a name that would no longer fit is dropped whole and the truncation is marked with
,…(never a silent cut). - A raw call counter — the total number of outbound agent calls dispatched during the request, duplicates included; this stays accurate even when the name list above had to be capped.
This audit trail also includes agent calls that a guard or a quota rejected — its purpose is to answer "which agent was this trying to reach," not just to record the calls that succeeded; a rejected call is at least as interesting from a security standpoint as a successful one.
Elasticsearch and MongoDB traffic-log connectors carry these fields automatically. If your installation uses the SQL/JDBC traffic-log connector, see 2026.09.0 — Log Table Update Scripts.
Migrating from the Previous Model
- The separate A2A "Inbound Agent" screen is gone; A2A is now configured directly on an A2A Gateway's Routing tab.
- Per-agent authentication mode (None / API Key) no longer exists — authentication is whatever policy chain you attach to the proxy, the same as any other proxy type.
- The old dedicated inbound path is gone; clients must be repointed at the A2A Gateway's own client path.
- Existing inbound agent definitions aren't carried forward automatically — recreate them as an A2A Gateway. Task history for tasks that already ran is retained.
- Outbound A2A connections are no longer a standalone, shared resource. The connection screen is gone; an external agent is now defined inline, directly on a Passthrough proxy's Routing tab or inside the A2A Call (LLM) / A2A Call (Fixed) policy that uses it (see A2A Agents Are Configured Inline). This is auto-migrated on upgrade: any proxy or policy that referenced an outbound A2A connection under the old model gets that connection copied inline automatically — there's nothing to recreate. If the same connection was shared by more than one proxy or policy, each one ends up with its own independent copy (credential included) after the upgrade; keep that in mind when you next rotate the credential. Agent-card discovery, health probing, catalog drift protection, and token passthrough all still work the same way; they're just scoped to the agent's own definition instead of a shared record.