Skip to main content

DVARA 1.3.0 — The A2A Governance Plane

· 5 min read
DVARA Team
DVARA Team

DVARA 1.3.0 is available today. This release adds a third governance plane: agent-to-agent. Alongside the LLM gateway and the MCP Proxy, DVARA now sits in front of A2A traffic and governs every hop one agent makes to another — authenticating the caller, checking policy, scanning for PII, and writing a tamper-evident audit record — behind its own dedicated proxy.

Everything below ships in every install. There is no feature paywall — the same governance core across all three planes. 1.3.0 is a drop-in upgrade from 1.2.x.

Govern the hop, not the orchestration​

An agent calling another agent is a delegation: agent A asks agent B to do something on a user's behalf. Left ungoverned, that hop is invisible — no identity on the caller, no policy on what may be delegated, no scan of what data crosses, no record that it happened.

DVARA's A2A plane governs exactly one hop at a time. A request comes in for agent B, the plane runs the full governance chain, forwards it to B, and returns B's reply. It makes no onward call and runs no agent loop — orchestration stays where it belongs, in your framework. DVARA is the checkpoint each hop passes through, not the conductor.

The plane is fully independent of the LLM and MCP planes — its own proxy (dvara-a2a-gateway, port 8075), its own governance engines, its own audit chain. It ships as an opt-in component, off by default, so existing three-plane deployments are untouched until you turn it on.

What a governed hop checks​

Every A2A hop runs through a chain of operator-controlled checks:

  • Caller identity — the calling agent presents a DVARA API key, resolved to a tenant. No anonymous hops.
  • Registered peers — agent B must be a peer you registered, with its endpoint, auth scheme, and credentials under your control. Callers reference agents by id, never by raw URL.
  • A2A policy — an operator-authored policy DSL decides whether A may call B, or a given skill on B. Versioned, with lifecycle and rollback, like the LLM and MCP policy engines — but its own rules, in its own store.
  • PII — the outbound message is scanned; PII is redacted in flight or the hop is blocked, per your action.
  • Loop detection — runaway delegation chains are detected and the session killed before they spiral.
  • Human approval — hops matching a tenant's rules (by skill or by target agent) pause on a durable, cross-pod approval gate; a reviewer approves or denies from the Console or the tenant Portal, and the paused hop releases on whichever pod is holding it.

Governed across the full A2A surface​

1.3.0 governs the whole protocol surface, not just the basic send:

  • message:send — the governed synchronous hop.
  • message:stream — streaming hops with in-flight PII enforcement over the SSE events.
  • tasks:get · list · cancel · resubscribe — the task lifecycle, with PII-scanned task reads.
  • pushNotificationConfig CRUD — push-webhook config, with the tenant-supplied callback URL SSRF-validated before it's ever forwarded.
  • Agent Card discovery — /.well-known/agent-card.json, served through DVARA with a per-tenant skills allow-list so you advertise only the skills you intend to expose.

A separate plane means a separate record​

The A2A plane writes its own tamper-evident, HMAC hash-chained audit trail — every hop intent and result, every policy denial, PII action, loop kill, and approval decision — plus per-hop metering. Because it uses the same signing primitive as the LLM and MCP chains, that A2A trail folds straight into what you already run: it exports to Splunk, CloudWatch, and Kafka alongside the rest, and it shows up in the SOC 2, HIPAA, GDPR, and India RBI/SEBI compliance reports.

A note on scope. In 1.3.0, DVARA authenticates the caller, enforces the agents and policy you registered, and records every delegation tamper-evidently — including on-behalf-of tokens, which are forwarded to the peer for it to enforce. Cryptographic verification of the authority to delegate — signed, portable delegation with scope attenuation — is the next step on the roadmap, not a claim we make today.

Console review — pagination, navigation, and sessions​

1.3.0 also lands a Console review sweep:

  • Server-side pagination across the high-volume views — token usage, audit (both the shared and the A2A chains), MCP tool calls, the cost dashboard, and the agent-session viewer — so large installs page instead of loading everything.
  • A reorganized navigation grouped into task-oriented sections, with the audit viewer and the approval queue unified behind a plane selector so LLM, MCP, and A2A share one surface.
  • A longer, verified session — the Console session lifetime is now four hours, backed by durable JDBC-stored sessions, ending the frequent re-logins.

Upgrade​

1.3.0 is a drop-in upgrade over 1.2.x. Pull the 1.3.0 images (or the oci://ghcr.io/dvarahq/charts/dvara:1.3.0 chart), keep your existing license and configuration, and roll — the A2A schema migrations apply automatically on first boot.

The A2A plane is opt-in. Turn it on by enabling the dvara-a2a-gateway component (chart) or adding the service (Compose); leave it off and nothing changes. See the A2A Governance Plane docs for the full surface — the governance chain, the agent registry, and the documented limits.

If you are new to DVARA: it is self-managed, activated by a signed license key, with bring-your-own-key credentials so provider keys and request data never leave your perimeter. Start with a 30-day, all-features trial license — every feature unlocked, including native MCP and the A2A plane, no credit card. Get the trial or, for production licensing or a managed deployment in your region, talk to us. The release is live now.