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).