StructureClerk

Gouverner les agents Google Vertex AI et Gemini par A2A

Google a proposé le protocole Agent-to-Agent pour que les agents se parlent entre eux. StructureClerk l'expose nativement : la couche d'autorité n'est pas un service externe à vos agents Google — c'est un agent qu'ils interrogent dans leur propre langue.

a2amcprestRead in English

L'écosystème d'agents de Google — Vertex AI pour les construire, Gemini pour les faire raisonner — s'accompagne d'une contribution d'architecture : le protocole Agent-to-Agent (A2A), pensé pour que des agents hétérogènes se découvrent et coopèrent en JSON-RPC. Un agent n'appelle plus seulement des outils ; il interroge d'autres agents.

C'est exactement la forme que prend la couche d'autorité ici. StructureClerk publie une carte d'agent (/.well-known/agent-card.json) et un endpoint A2A natif : vos agents Google n'ont pas besoin d'un connecteur particulier — ils demandent l'autorisation à un autre agent, dans leur propre protocole, avant d'exécuter une action sensible.

Le scénario d'intégration

Trois voies, par ordre de naturel pour cet écosystème : A2A (JSON-RPC d'agent à agent, découverte par la carte d'agent), MCP (le standard d'outillage, transport Streamable HTTP), et REST (l'appel HTTP direct depuis n'importe quel pipeline). Les trois rendent la même décision, signée de la même façon.

  1. 1

    Générez le profil de votre organisation

    L'évaluation gratuite (commencer ici) établit juridictions, secteur et catégories de données. Les décisions rendues à vos agents sont personnalisées par ce profil.

  2. 2

    Faites découvrir l'agent d'autorité

    Pointez vos agents vers notre carte d'agent publique — elle déclare les compétences exposées, dont la décision d'autorité, et les protocoles disponibles. En MCP, ajoutez le serveur et l'outil authority_decide.

  3. 3

    Interrogez avant d'agir

    Avant l'action sensible, l'agent envoie la requête JSON-RPC avec les métadonnées de l'action — type, catégories de données, juridiction de destination.

    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

    Routez selon la réponse

    ALLOW : l'agent poursuit. APPROVE : il sollicite une validation humaine. DENY : il n'exécute pas, et consigne la raison. ESCALATE : il notifie le responsable. L'identifiant de preuve suit l'action dans vos journaux.

Le contrat de décision — la juridiction change la réponse

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
}
Le même export, deux destinations : vers un pays sous mandat de localisation des données, la réponse est DENY — d'agent à agent.

La décision est consultative — StructureClerk décide, votre infrastructure applique. Et elle est juridictionnelle par construction : le moteur évalue l'action deux fois, sans puis avec les règles juridictionnelles, et la plus stricte gagne. Une règle de juridiction ne peut jamais assouplir une décision — seulement la resserrer.

DécisionEffet dans votre pipeline
ALLOWL'agent poursuit, la preuve est consignée
APPROVEL'agent sollicite une validation humaine
DENYL'agent n'exécute pas, la raison est journalisée
ESCALATELe responsable est notifié, l'action attend

La preuve, d'agent à agent

Chaque décision laisse une preuve signée Ed25519, chaînée à la précédente — vérifiable par n'importe qui sur notre page de vérification, sans compte. Quand un auditeur demande comment vos agents autonomes sont gouvernés, la réponse n'est pas un document interne : c'est une chaîne de preuves qu'il contrôle lui-même.

Cette approche s'inscrit dans la direction des standards d'identité et d'autorisation d'agents : l'agent est identifié, son autorité est décidée par une couche distincte, et la trace est opposable. L'identité dit qui est l'agent ; l'autorité dit ce qu'il peut faire.

+Pourquoi passer par A2A plutôt que par un appel REST ?

Les trois protocoles rendent la même décision — A2A est simplement la voie la plus naturelle quand vos agents parlent déjà JSON-RPC entre eux : la couche d'autorité devient un agent parmi les autres, découvrable par sa carte, sans connecteur spécifique. Si votre pipeline préfère un appel HTTP direct, l'endpoint REST est équivalent.

+Comment mes agents découvrent-ils la couche d'autorité ?

Par la carte d'agent publique, qui déclare les compétences exposées, les protocoles et les endpoints. C'est le mécanisme de découverte prévu par A2A : vos agents la lisent et savent quoi demander, et comment.

+Que se passe-t-il quand le moteur doute ?

Il ne devine pas : sous un seuil de confiance, la décision est ESCALATE — l'action attend un humain. Un moteur d'autorité qui devine serait pire que pas de moteur du tout ; le doute explicite fait partie du contrat.

+La décision tient-elle compte du pays de destination ?

Oui, c'est son cœur : le même export peut être permis vers une juridiction dotée d'un mécanisme de transfert reconnu et refusé vers une juridiction sous mandat de localisation. La règle juridictionnelle ne peut que resserrer la décision, jamais l'assouplir.

Commencez par le profil

C'est l'évaluation qui personnalise les décisions rendues à vos agents. Elle est gratuite, et ne demande que l'adresse de votre site.

Autres intégrations