A2A agents and approvals

The A2A pages let your workspace govern the agent-to-agent hops your agents make — registering the peers they may delegate to, and resolving the approvals that pause sensitive hops. This is the tenant-scoped view of the A2A plane; everything here is filtered to your workspace.

:::note Roles

• Admin / developer — register and edit A2A agents, approve or deny hops.
• Viewer — read-only: see the registry, the pending queue, and the decision history, but cannot register agents or resolve approvals. :::

A2A agents

Open A2A → Agents. This is the registry of peer agents your workspace is allowed to reach — a hop can only target an agent registered here, and you only ever see your own workspace's agents.

Register a peer with its Agent ID (unique in your workspace), Endpoint URL, auth scheme and credential, auth mode (STORED or DELEGATED), and an optional skills allow-list that bounds what discovery advertises for it.

:::caution SSRF protection The endpoint URL is validated when you save it. It must be a public http/https endpoint — loopback, private, link-local, and cloud-metadata addresses (e.g. 127.0.0.1, 10.0.0.0/8, 169.254.169.254) are rejected. DVARA connects to this URL server-side on every hop, so this prevents a registered agent being used as a server-side request-forgery primitive. :::

Approvals

Open A2A → Approvals. When a hop matches your workspace's approval rules — by requested skill or by target agent — it pauses here until someone decides. Nothing is delegated to the peer until you approve.

Pending

Every hop awaiting a decision, with the caller, the target agent, the requested skill, and when it was raised. Approve releases the hop to the peer; Deny rejects it. The queue auto-refreshes, and a nav badge shows the pending count.

The decision is durable and cross-pod: it releases the paused hop on whichever gateway pod is holding it, so it does not matter which pod served your click.

History

The decision log for your workspace — every resolved hop with its action, who decided it, and when.

:::info Isolation You only ever see and resolve your own workspace's A2A approvals. A hop raised for another tenant is never listed here, and an attempt to resolve one is rejected. Platform operators use the cross-tenant Console A2A approval queue instead. :::

If a paused hop is not resolved before its timeout, your workspace's default action applies (deny, unless configured otherwise).

Where to go next

• A2A Governance Plane — what a governed hop is and what it checks.
• Console A2A Governance — the platform-operator view (registry, policies, hop audit, cross-tenant approvals).