Skip to main content
Version: 1.8.0

A2A Governance

Enterprise only

Not included in DVARA Open Source.

The Agents section of the sidebar carries the Agent-to-Agent (A2A) surfaces alongside the MCP ones. Where Agents & MCP governs the tools your agents call, these pages govern the other agents your agents call — every agent-to-agent hop through the A2A plane.

The A2A plane is served by the gateway under /a2a, with its own governance engines and its own tamper-evident audit chain, fully separate from the MCP plane's. Its Platform-wide pages therefore live beside — not inside — the MCP pages.

Roles

The A2A Platform-wide pages are platform-scoped: owner and policy-admin can view and manage them. The approval queue is cross-workspace. See the role-access matrix.

A2A agents​

Open Agents → A2A Agents in the sidebar. This is the registry of peer agents your workspaces are allowed to reach — a hop can only target an agent that is registered here.

Agent list​

Lists every registered peer agent with its agent ID, workspace, endpoint URL, auth scheme, status pill, and actions. Use the Workspace dropdown to narrow the list; workspace-role callers see only their own workspace's agents.

From 1.8.5 an active agent whose endpoint is http:// carries a Not HTTPS badge. A2A requires HTTPS, so the gateway sends that agent nothing. Edit the endpoint to https://, or disable the agent. Flightdeck also names each such agent in a warning at startup.

Create / edit agent​

Click New Agent to register a peer with:

  • Agent ID — human-readable slug, unique per workspace (e.g. billing-agent, research-agent).
  • Workspace ID — the workspace this agent belongs to (required on create).
  • Endpoint URL — the peer agent's base URL (required). Validated at save — private, loopback, link-local, and cloud-metadata addresses are rejected (SSRF protection), the same as MCP servers. From 1.8.5 an active agent's endpoint must be https://; anything else is refused with A2A_ENDPOINT_NOT_HTTPS. A disabled or suspended agent may keep an http:// endpoint.
  • Auth scheme — how DVARA authenticates to the peer: From the Agent Card (from 1.8.4, the default for a new agent), API_KEY, HTTP (bearer), OAUTH2, OPENID_CONNECT, or MUTUAL_TLS. From the Agent Card reads the peer's card and takes the one kind of scheme it declares; if the card cannot be read, declares none, or declares more than one kind, the save is refused and you choose. A scheme you choose is compared with the card, and a mismatch is shown as a warning on the form and as a Card mismatch badge in the list. It never blocks the save or the hop. See how DVARA authenticates to the peer.
  • Credential Ref — the name of a credential stored in this agent's workspace. It cannot name a vault path, a platform credential, or another workspace's credential.
  • Auth mode — STORED (DVARA resolves the agent's own credential) or DELEGATED (on-behalf-of — DVARA forwards the caller's X-DVARA-Delegated-Authorization token so the peer enforces that end user's permissions; a DELEGATED agent called without the token is rejected with A2A_DELEGATED_TOKEN_REQUIRED).
  • Agent Card — optional JSON Agent Card cached for discovery.
  • Skills allow-list — the per-workspace list of skills that Agent Card discovery advertises for this agent. Empty = advertise all skills the peer publishes.
  • Status — ACTIVE, SUSPENDED, or DISABLED (edit only). A hop to a non-ACTIVE agent is rejected with A2A_AGENT_UNAVAILABLE.

An agent ID the workspace already uses, on create or on a rename, is refused with A2A_AGENT_DUPLICATE, naming the ID. From 1.8.4 the refusal shows on the form and the values you entered stay; before, it showed as an unexpected error. From 1.8.4 a new agent ID that contains :: is refused with A2A_AGENT_ID_INVALID; an existing agent keeps its ID.

Register the endpoint and authentication first, then fetch the Agent Card and review its advertised skills and trust result before sending a governed hop. After the first call, use the hop list to confirm policy, identity, approval, and delegation outcomes. This sequence distinguishes a discovery or trust problem from a runtime message failure.

A2A policies​

A2A policies decide which hops are allowed — which caller may reach which target agent or requested skill. They are a separate engine and a separate store from the LLM/MCP policies, authored in the A2A policy DSL with the same lifecycle you already know: Draft → Active → Archived, versioned, with rollback and a dry-run validator.

A2A policies have no dedicated page — manage them through Flightdeck GitOps export/import, where they appear under the a2a_policies section of the exported document. A malformed DSL is rejected at import with INVALID_A2A_POLICY_DSL; a denied hop returns A2A_POLICY_DENIED (403). Policy changes hot-reload across the fleet within one config-poll interval — no restart.

Hop audit​

Open Audit in the sidebar and select the A2A plane in the plane selector. The A2A plane writes to its own tamper-evident audit chain (separate from the shared LLM/MCP chain), so its events appear under their own tab.

Each row is one hop event — A2A_HOP_INTENT, A2A_HOP_RESULT, A2A_HOP_DENIED, A2A_DELEGATION_RECORDED, A2A_PII_DETECTED, A2A_LOOP_DETECTED, A2A_APPROVAL_* — carrying its caller, target agent, requested skill, policy decision, and workspace. Click a row to expand its signed envelope and confirm the chain is intact — any gap or altered payload breaks the tamper-evident chain and is visible here.

A2A Traffic​

Open A2A Traffic to list the hops themselves, with each hop's chain and depth. Filter by workspace, agent and skill. From 1.8.5 a hop that the delegation guard let through in observe mode, but would have refused, shows "would refuse: " and the reason (cycle, depth_exceeded or chain_required). The mark also shows on the hop detail and on the session and conversation timelines. Tick Would refuse only to list just those hops. A hop refused in enforce mode shows as refused, as before.

Because the A2A chain uses the same signing secret and algorithm as the shared chain, the same integrity verification applies, and A2A events flow into the SIEM exporters and the compliance reports alongside the rest.

Open an A2A session or conversation to follow its chronological hop timeline. Both detail pages provide a JSON export containing the workspace, identifier, and recorded hops. A2A → Analytics breaks activity down by error code, policy decision, authentication mode, and approval outcome. Pair that JSON with the matching audit export when an incident needs a portable evidence bundle.

Approval queue​

Open Approvals and select the A2A plane. Hops that match a workspace's approval rules (by requested skill or by target agent) pause on a durable, cross-pod gate until a reviewer decides — the A2A analogue of the MCP approval queue.

Pending tab​

Lists every A2A hop currently awaiting a decision, with caller, target agent, requested skill, workspace, and the time it was raised. Approve releases the paused hop; Deny rejects it with A2A_APPROVAL_DENIED (403). The decision is written to a durable, cross-pod store, so it releases the hop on whichever DVARA Gateway pod is holding it, within one poll interval — even if another pod serves Flightdeck.

History tab​

The decision log — every resolved A2A approval with its action, reviewer, and timestamp. Resolving emits A2A_APPROVAL_RESOLVED on the A2A own-chain, capturing the human actor.

The sidebar's Approvals entry carries a live count of pending A2A approvals so reviewers see new requests without polling the page.

A hop matching a rule that is not resolved before its timeout applies the workspace's default action (deny, safe by default). A resolve targeting an approval that already expired or was decided returns A2A_APPROVAL_NOT_FOUND (404). Workspace users resolve their own workspace's A2A approvals from the workspace approvals.

Where to go next​