Every handoff is another authorization boundary. Govern the hop where one agent delegates to another.
As your agents delegate work to other agents, each handoff creates a boundary someone has to answer for: who asked, what they were allowed to ask for, what data crossed, and what came back. The DVARA A2A Gateway sits on that hop — identity, authorization, inspection and approval before the work is delegated, and a record of what happened afterwards.
A2A governance is licensed and has no free tier — see pricing.
What happens when one agent hands work to another?
An agent asking another agent to act on a user's behalf is a delegation, and left ungoverned it is the one call in the chain nobody instruments: no identity on the caller, no rule about what may be delegated, no inspection of what crosses, no record it happened. A2A governance is control over exactly that hop — and the boundary is deliberate. DVARA governs one hop and returns the peer's reply. It makes no onward call and runs no agent loop, so orchestration stays with your framework and each delegation stays a discrete, checkable event.
How does DVARA know who is calling, and who it is calling?
The caller authenticates to DVARA, and the target has to be an agent you registered. Neither end is taken on trust from the request itself.
The calling agent presents a DVARA API key, which resolves to a workspace and principal before anything else runs. A hop with no identity is rejected rather than treated as anonymous.
DVARA forwards only to peers you registered — endpoint, auth scheme, credential reference, and an optional skills allow-list, scoped per workspace. An agent that is not in your workspace’s registry cannot be reached through the gateway.
In stored mode DVARA presents the peer’s own credential and the caller never holds it. In delegated mode the caller passes an on-behalf-of token so the peer enforces the end user’s permissions — in that mode the caller does hold a credential. Five schemes are supported: API key, bearer, OAuth2, OpenID Connect, and mutual TLS.
A peer’s Agent Card can be JWS-signed, and DVARA verifies it at discovery against an operator-pinned key, surfacing the trust state on the card, the registry entry, and the audit event. A pinned-key mismatch is refused; you can also require a verified card, and otherwise verification is fail-soft.
What decides whether a delegation is allowed?
A policy answering one question per hop — may this source invoke this skill on this target — plus what the caller is allowed to see, who has to sign off, and how far a chain may run before it is stopped.
May this source agent invoke this skill on this target? Rules match on all three, are versioned and workspace-scoped, and support dry-run and rollback. They are default-allow and first-match-wins, so a narrow denial has to be written above a broad allow.
Each peer’s Agent Card is served through the gateway with the workspace’s skills allow-list applied, so a caller sees the subset it may invoke rather than everything the peer can do. Cards are cached and refreshed on a TTL.
Name target agents or skill patterns and a matching hop pauses before it is forwarded — nothing reaches the peer while it waits. The decision is durable and resolves on whichever pod holds the hop. Unresolved hops fall to your default action, which is deny.
A→B→A cycles, repetition and rate are watched per session. On detection the session is killed and the hop is rejected with a 429, so later hops in that session are blocked too. This differs from the MCP plane, where ending the session is opt-in.
What happens to the data crossing the boundary?
The outbound message is inspected before the peer is contacted, and the reply before it reaches the caller. What each does is your workspace's setting, and the response path has one documented limit worth knowing.
Each text part of the outbound message runs through your workspace’s PII setting: redact rewrites the text that is forwarded, block rejects the hop so the data never reaches the peer, log records the detection.
The peer’s reply is scanned on the way back, and blocking returns an error rather than leaking the content. Redaction of structured response bodies is a documented follow-up, so treat block as the control on the response path.
A streaming hop runs the same checks before the peer is contacted, and a rejection arrives as a single error event with no call made. The peer’s streamed events are then enforced as they pass: redacted, or the stream terminated on a block.
A workspace-supplied push-notification webhook is checked before the config reaches the peer, and a URL pointing at loopback, private, link-local or cloud-metadata space is rejected and never forwarded. The same egress guard applies to registered agent endpoints.
What is left behind after a hop?
Two records per hop on a chain of its own — written before the handoff and after the result, so an interrupted call still leaves a trace.
An intent record is written before the hop is forwarded, so an interrupted call still leaves a trace, and a result or denial record closes it out. Denials name what stopped the hop — policy, PII, a loop, or a killed session.
A2A records are HMAC-signed and hash-chained in their own store, separate from the LLM and MCP chain, so insertion, deletion or alteration is detectable and the two streams stay independently auditable.
Because the store is separate, A2A events do not appear in the shared audit viewer — they have their own, in both the console and the workspace portal. Worth knowing before someone looks in the wrong place and concludes a hop went unrecorded.
The A2A chain is forwarded to the same SIEM exporters as its own stream, and every generated compliance report carries an A2A section — hop volume, policy denials, PII actions, loop detections — plus a check that verifies the A2A chain’s integrity.
What happens between the two agents?
Six stages, and where a stage sits is the point: everything through step three runs before the peer is contacted, so a hop that fails one of them is never delegated. Only the last two see a reply.
- 1
The calling agent sends the hop to DVARA
A message or task request goes to the gateway’s /a2a path rather than to the peer. The gateway resolves the caller’s key to a workspace and principal, and refuses a hop that carries no identity.
- 2
The target is resolved from your registry
The requested agent is looked up in that workspace’s registry, and the credential or on-behalf-of token for it is prepared. An intent record is written here — before anything is forwarded — so an interrupted hop still leaves a trace.
- 3
Policy, inspection, loops, approval
Policy decides whether this source may invoke this skill on this target. The outbound message is scanned for PII. Delegation loops are checked, and the session ends if one is found. A hop matching an approval rule pauses here until someone decides.
- 4
The hop reaches the peer
Only a hop that cleared every stage above is forwarded, with the right auth scheme injected. DVARA governs this one hop and makes no onward call — deciding who your agents call next stays with your framework.
- 5
The reply is inspected on the way back
The peer’s reply is scanned before it reaches the caller, and blocking returns an error rather than the content. A streamed reply is enforced event by event as it passes through.
- 6
The hop is closed out
A result or denial record and a per-hop metering row close the hop, hash-chained onto the A2A trail. Pass a session header and the hops in one delegation chain are correlated together.
Which A2A operations are governed, and what is not there yet?
Messages, streams, the task lifecycle, push-notification config and discovery all run the same workspace-scoped chain. Four things are documented follow-ups rather than shipped, and they are listed here rather than left for you to discover during a pilot.
Synchronous messages, streaming messages, the task lifecycle — get, list, cancel, resubscribe — push-notification config, and Agent Card discovery. Each runs the workspace-scoped chain and leaves its own audit record.
DVARA fetches and serves the peer’s public Agent Card. The authenticated extended card is a follow-up, so plan around the public card’s contents.
For stored-mode agents on those schemes, DVARA presents the credential you configured as a bearer token; acquiring one through the full grant flow is a follow-up. Per-agent client certificates for mutual TLS are also a follow-up — the connector’s default TLS context is used today.
A delegated hop leaves a tamper-evident record of who delegated to whom, with the token stored by fingerprint rather than in the clear. Signed, scope-attenuated delegation — proving authority to delegate — is planned rather than shipped.
How does the A2A Gateway fit with the rest of DVARA?
Three governed data planes and one control plane, deployed and scaled separately. Pass the same session header through all three and a model turn, its tool calls, and the work it delegated correlate to one session.
The governed data plane for model calls — the one your applications point an OpenAI SDK at.
The same governance model applied to an agent calling a tool, in server and tool terms rather than agent and skill.
This page. An opt-in plane with its own registry, its own policy engine and its own audit chain, so you turn it on when your agents start delegating without touching the other two.
The control plane. The agent registry, policies and the approval queue are managed here, and changes reach the fleet on the next config read rather than a restart.
Where do you see the work your agents handed each other?
In DVARA Flightdeck. Every governed hop appears as it happens, with the agent that called, the agent it delegated to, the skill it asked for, and the workspace and session the work belongs to.
How does DVARA compare on agentic governance?
Against the three alternatives that score strongest on agentic governance in the matrix behind how DVARA compares — chosen by score, not by how well DVARA does against them. Each row is checkable against that product's own public documentation.
| Capability | DVARA | Portkey | Kong AI | Databricks |
|---|---|---|---|---|
| Human approval gate (enforced at exec) | ✓ | ✓ | ∼ | — |
| Agent loop detection + kill switch | ✓ | — | — | — |
| Multi-agent session tracking | ✓ | ∼ | ∼ | ∼ |
| Full OTel trace: LLM turns + MCP calls | ✓ | ∼ | — | ∼ |
| Pricing model | Licensed, sized by request volume — no hard stop on overage | Subscription from $49/mo + per-request overage (source) | See their pricing | See their pricing |
Every column but ours describes what that vendor's public documentation said when we read it in June 2026 (pricing: August 2026) — a dash means we did not find the capability documented, not that the product cannot do it. Vendors ship continuously; check their docs before deciding. The DVARA column is a claim about our own code and is verified against the released tag. For the full matrix across ten alternatives, see how DVARA compares.
What do you need to run A2A governance?
A licence. It activates paths on the gateway you already run \u2014 there is nothing extra to deploy, and unlike the LLM plane there is no keyless tier of this one. See what a licence covers.
There is no keyless tier of this plane. It runs inside the gateway image you already pull — both images are public, so there is no separate image and no registry credential to request — and a valid licence key is what activates it.
A licence activates it; it is a path on the gateway you already run, not a service to deploy. Without a licence the /a2a paths are not registered at all — a request there answers 404, not a licence error. The LLM and MCP planes are unaffected either way.
The DVARA LLM Gateway and DVARA Flightdeck are public images you can run with no key and no account. A2A and MCP governance activate inside that same install rather than being a different product.
Common questions about A2A governance
What does A2A governance cover?
The hop where one of your agents delegates to another agent — the message or task it sends, and the reply that comes back. DVARA governs that one hop and returns the peer’s reply. It makes no onward call and runs no agent loop, so deciding who calls whom next stays with your framework. A hop your agent makes over its own direct connection to a peer is outside the path.
How does DVARA identify the calling and target agents?
The caller presents a DVARA API key that resolves to a workspace and principal, and a hop without one is rejected rather than treated as anonymous. The target is resolved from that workspace’s registry of peer agents, so a hop can only reach an agent you registered. To the peer, DVARA presents either that agent’s stored credential or an on-behalf-of token the caller supplied.
How are Agent Cards and allowed skills handled?
DVARA fetches the peer’s public Agent Card, caches it on a TTL, and serves it through the gateway with the workspace’s skills allow-list applied — so a caller sees only the skills it may invoke. Where a peer signs its card, DVARA verifies the signature against an operator-pinned key and surfaces the trust state; you can require a verified card, and otherwise verification is fail-soft. The authenticated extended card is a follow-up.
Can policies differ by workspace, agent, skill, or delegation?
Policies are workspace-scoped and match on the source agent, the target, and the requested skill. They are versioned with rollback and a dry-run validator, and changes reach the fleet within a poll interval rather than needing a restart. Note the default: rules are default-allow and first-match-wins, so a narrow denial has to sit above a broad allow.
Can sensitive handoffs require human approval?
Yes, for the target agents and skill patterns you name — nothing is delegated to the peer while a matched hop waits. The decision is durable and releases the hop on whichever pod is holding it, so a multi-replica deployment behaves like a single one. If nobody answers before the timeout, your default action applies, and that default is deny.
What happens to messages, streams, and results crossing the boundary?
The outbound message is scanned before it is forwarded, and your workspace setting decides the outcome: redact rewrites the text, block stops the hop, log records the detection. The reply is scanned on the way back, where blocking returns an error instead of the content — redaction of structured response bodies is a documented follow-up. Streamed events are enforced as they pass, with the stream terminated on a block.
How are A2A hops connected to model and MCP calls?
Pass an X-Session-Id header. The LLM Gateway, the MCP Gateway and the A2A Gateway all accept it, so a model turn, the tool calls under it, and the hops delegated out of it correlate to one session. Without the header a hop is still recorded and metered, just not grouped with the rest of the chain.
What limits runaway delegation?
Three detectors run per session: A→B→A cycles, repetition, and rate. On detection DVARA kills the session and rejects the hop with a 429, so subsequent hops in that session are blocked too. This is stricter than the MCP plane, where ending the session is something you opt into. Because DVARA makes no onward call itself, a chain can only grow by passing through the gateway again — which is where each new hop is counted.
How are credentials and webhook URLs handled?
A peer’s credential is held centrally by reference and injected by the gateway, so in stored mode the calling agent never holds it. In delegated mode the caller supplies its own token, which is recorded by fingerprint rather than in the clear. A workspace-supplied push-notification webhook is validated before the config reaches the peer — loopback, private, link-local and cloud-metadata addresses are rejected — and registered agent endpoints get the same check.
Which edition includes A2A governance?
It requires a licence and has no keyless tier. There is no separate image to pull — since 1.7.0 there is one artifact per app, and the plane is a set of paths on the gateway that a licence activates. Measured on an unlicensed install, /a2a answers 404 because the paths are never registered.
Put one delegation behind the gateway.
A2A governance is licensed and opt-in — you deploy it when your agents start handing work to each other. Talk through what that looks like on your traffic, or read how a hop is governed first.