A2A agents and approvals
The A2A plane activates only with a valid license — that is what the license gates. Everything else in DVARA (policy, PII, guardrails, audit, FinOps, routing, SSO) runs unlicensed in the Development posture.
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 workspace-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 workspace is never listed here, and an attempt to resolve one is rejected. Platform operators use the cross-workspace 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-workspace approvals).