Governing Google Vertex AI and Gemini agents over A2A

Google's agent ecosystem — Vertex AI to build them, Gemini to make them reason — comes with an architectural contribution: the Agent-to-Agent (A2A) protocol, designed so heterogeneous agents can discover each other and cooperate over JSON-RPC. An agent no longer just calls tools; it queries other agents.

That is exactly the shape the authority layer takes here. StructureClerk publishes an agent card (/.well-known/agent-card.json) and a native A2A endpoint: your Google agents need no special connector — they ask another agent for authorization, in their own protocol, before executing a sensitive action.

The integration scenario

Three paths, in order of naturalness for this ecosystem: A2A (agent-to-agent JSON-RPC, discovery via the agent card), MCP (the tooling standard, Streamable HTTP transport), and REST (a direct HTTP call from any pipeline). All three render the same decision, signed the same way.

1. 1

   Generate your organization's profile

   The free assessment (start here) establishes jurisdictions, sector and data categories. The decisions your agents receive are personalized by that profile.

2. 2

   Let agents discover the authority agent

   Point your agents at our public agent card — it declares the exposed skills, including the authority decision, and the available protocols. Over MCP, add the server and the authority_decide tool.

3. 3

   Query before acting

   Before the sensitive action, the agent sends the JSON-RPC request with the action's metadata — type, data categories, destination jurisdiction.

   curl -X POST https://structureclerk.ca/api/a2a \
     -H 'Content-Type: application/json' \
     -d '{"jsonrpc":"2.0","method":"authority/decide","params":{"agent":{"id":"vertex-data-agent","autonomy_level":3},"action":{"type":"export.customer_record","data_categories":["personal"],"destination_jurisdiction":"CN"},"context":{"jurisdictions":["FR"],"sector":"tech"}},"id":1}'

4. 4

   Route on the answer

   ALLOW: the agent proceeds. APPROVE: it requests human validation. DENY: it does not execute, and records the reason. ESCALATE: it notifies the owner. The evidence identifier follows the action through your logs.

The decision contract — jurisdiction changes the answer

POST https://structureclerk.ca/api/a2a
{
  "jsonrpc": "2.0",
  "method": "authority/decide",
  "params": {
    "agent": { "id": "vertex-data-agent", "autonomy_level": 3 },
    "action": {
      "type": "export.customer_record",
      "data_categories": ["personal"],
      "destination_jurisdiction": "CN"
    },
    "context": { "jurisdictions": ["FR"], "sector": "tech" }
  },
  "id": 1
}
// →
{
  "jsonrpc": "2.0",
  "result": {
    "decision": "DENY",
    "reason": "data_localisation_mandate",
    "confidence": 0.96,
    "evidence_id": "ev_77af…03bc"
  },
  "id": 1
}

The decision is advisory — StructureClerk decides, your infrastructure enforces. And it is jurisdictional by construction: the engine evaluates the action twice, without then with the jurisdictional rules, and the stricter outcome wins. A jurisdictional rule can never loosen a decision — only tighten it.

Evidence, agent to agent

Every decision leaves Ed25519-signed evidence, chained to the previous one — verifiable by anyone on our verification page, without an account. When an auditor asks how your autonomous agents are governed, the answer is not an internal document: it is a chain of evidence they check themselves.

This approach follows the direction of agent identity and authorization standards: the agent is identified, its authority is decided by a distinct layer, and the trace can be relied on by third parties. Identity says who the agent is; authority says what it may do.