Skip to main content
Version: 1.9.0

A2A agents and approvals

Enterprise only

Not included in DVARA Open Source.

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.

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 audit​

Open A2A Audit to see your workspace's hop events. From 1.9.0 the Protocol column shows the A2A version and binding DVARA used to call the peer, such as 1.0 · JSONRPC. A hop refused before it was sent shows none. From 1.9.0 the Verified delegation column shows what a hop's signed delegation chain came to: "verified", with the chain's depth and how it narrowed from the first step to the last, or "refused: " and the check that failed, such as expired or bad-sig. A hop with no chain shows a dash.

A2A agents​

Open A2A → Agents in Flightdeck. 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.

To find an agent instead of typing its details, use the A2A catalog when your operator has turned it on.

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.

From 1.8.5 an active agent's endpoint must be https://, as the A2A specification requires; anything else is refused with A2A_ENDPOINT_NOT_HTTPS. An agent saved over http:// before 1.8.5 is marked Not HTTPS in the list, and the gateway sends it nothing until you move it to https:// or disable it.

From 1.8.4 the auth scheme defaults to From the Agent Card for a new agent: DVARA reads the peer's card and takes the one scheme it declares. If the card cannot be read or declares more than one kind, the save is refused and you choose. A scheme you choose is checked against the card, and a mismatch is shown as a warning, never a refusal. An agent ID your workspace already uses is refused on the form with A2A_AGENT_DUPLICATE, keeping what you typed, and a new ID that contains :: is refused with A2A_AGENT_ID_INVALID.

SSRF protection

The endpoint URL is validated when you save it. It must be a public 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 in Flightdeck. 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.

Isolation

You only 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 A2A approval queue.

If a paused hop is not resolved before its timeout, your workspace's default action applies (deny, unless configured otherwise). From 1.8.5, if the hop's session is killed while it waits, the approval is denied at once and the hop is refused with A2A_SESSION_KILLED.

A2A delegation​

A workspace admin sets the delegation guard on Agents → A2A Delegation: the mode, the cycle rule, the maximum depth and whether agents must send their chain. From 1.8.5 the page also sets:

  • Preset — standard (the default) or hardened. hardened requires the chain from agents, uses the agent cycle rule and always has a session hop budget (200 unless you set one). Mode and maximum depth still apply, so you can observe it first.
  • Max hops per session — the most hops one session may forward. Blank uses the gateway default, which is no limit unless your operator set one. 0 means no limit, except under hardened, which then uses 200. A hop past it is refused with 409.

From 1.9.0 the page has a Signed delegation chains section for callers that send a signed chain (X-Dvara-Delegated-Authorization: DvaraDeleg …). Every setting is off until you set it, and each only makes the check stricter:

  • Max chain lifetime (seconds) — refuse a chain with any link that lives longer than this, from 1 to 86400. It can only lower the gateway's limit (15 minutes unless your operator changed it), never raise it. A longer chain is refused with 403 a2a_delegation_expired.
  • Require a signed chain — refuse a hop whose delegation header holds a plain on-behalf-of bearer token, which the gateway cannot check, with 403 a2a_delegation_invalid and the reason unverified. A hop with no delegation header is not affected. An agent that signs in with the caller's own token (delegated mode) then has no token to use, so turn this on once your callers send signed chains.
  • Require workspace-bound chains (from 1.9.0) — accept only signed chains in version 2, which name this workspace in every step, so a chain made for another workspace can never be used here. A version 1 chain is refused with 403 a2a_delegation_invalid and the reason version-not-allowed, and nothing is sent to the agent. A hop with no chain, or with a bearer token, is not affected. Turn it on once every agent that sends chains into this workspace signs version 2.

Platform roles set the same fields in the workspace form. Every change is audited.

An agent that must start work of its own needs its key marked May start chains on the API Keys page. See Use the hardened preset.

A2A revocations​

From 1.9.0 a workspace admin can stop a signed delegation chain in this workspace before it expires, on Agents → A2A Revocations:

  • One block. Enter the block's jti, from the block_ids of the hop's A2A_DELEGATION_VERIFIED audit event. Other chains keep working.
  • One issuer. Enter the agent exactly as the chain names it, by its registry id or its workload identity. Every chain with a step that agent signed is refused.

Every gateway refuses such a chain within about 5 seconds, with 403 a2a_delegation_invalid and the reason revoked. A block revocation lasts 25 hours unless you choose a length; an issuer revocation lasts until you lift it. Add a reason: it is kept in the audit log with each revocation and each lift (A2A_DELEGATION_REVOKED, A2A_DELEGATION_REVOCATION_LIFTED).

The page shows only this workspace's revocations. Developers and viewers can see the list but cannot change it. Platform roles use the same rules for any workspace; see Withdraw a signed delegation chain.

Where to go next​