Skip to main content
Version: Latest (1.4.x dev)

A2A Governance

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 a separate, opt-in plane on port 8075 with its own governance engines and its own tamper-evident audit chain. Its Console pages therefore live beside — not inside — the MCP pages.

:::note Roles The A2A Console pages are platform-scoped: owner and policy-admin can view and manage them. The approval queue is cross-tenant. See the role-access matrix. :::

A2A agents​

Open Agents → A2A Agents in the sidebar. This is the registry of peer agents your tenants 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, tenant, endpoint URL, auth scheme, status pill, and actions. Use the Tenant dropdown to narrow the list; tenant-role callers see only their own tenant's agents.

Create / edit agent​

Click New Agent to register a peer with:

  • Agent ID — human-readable slug, unique per tenant (e.g. billing-agent, research-agent).
  • Tenant ID — the tenant 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.
  • Auth scheme — how DVARA authenticates to the peer: API_KEY, HTTP (bearer), OAUTH2, OPENID_CONNECT, or MUTUAL_TLS.
  • Credential Ref — vault path / secret reference for the peer credential (optional).
  • 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-tenant 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.

Duplicate agent IDs within a tenant are rejected with A2A_AGENT_DUPLICATE (409).

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 are managed through the Automation API under /v1/admin/a2a/policies (create, update, status, versions, rollback, dry-run). A malformed DSL is rejected at write time 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, tenant, and its position in the HMAC hash chain. Click a row to expand the signed envelope and verify chain continuity: each event's previous_hash links to the prior event's HMAC, and the sequence number is strictly monotonic. A gap or an altered payload breaks the chain and is visible here.

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.

Approval queue​

Open Approvals and select the A2A plane. Hops that match a tenant'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, tenant, and the time it was raised. Approve releases the paused hop; Deny rejects it with A2A_APPROVAL_DENIED (403). The decision is written to the durable a2a_approvals store, so it releases the hop on whichever a2a-proxy pod is holding it, within one poll interval — even if that pod is not the one serving the Console.

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 tenant's default action (deny, safe by default). A resolve targeting an approval that already expired or was decided returns A2A_APPROVAL_NOT_FOUND (404). Tenant users resolve their own workspace's A2A approvals from the Tenant Portal.

Where to go next​

Last updated on