reçus d'exécution d'un agent de l'IA

Une approbation dit qu'un agent d'IA peut agir. Un reçu d'exécution relie cette approbation à la demande exacte envoyée et au résultat observé par la suite.

Maetra utilise le même hachage canonique dans toute la proposition, la décision signée, l'autorisation d'exécution, les tentatives du fournisseur et les preuves d'effet. Si l'un de ces liens manque, le cycle de vie est marqué incomplet.

Autoriser l'exécution exacte#

Appeler POST /v1/executions/authorize immédiatement avant l'effet secondaire externe. Le critère d'évaluation consomme une capacité approuvée une fois et rejette une charge utile modifiée, un mauvais espace de travail ou un exécuteur testamentaire, une approbation expirée ou révoquée, un résumé des politiques modifié ou un rejouage.

{
  "decision_token": "eyJ…",
  "action_envelope": {
    "schema": "maetra.govern.action-envelope.v1",
    "workspaceId": "workspace_123",
    "agent": { "id": "agent_42", "name": "Treasury agent" },
    "action": "transfer_funds",
    "target": { "provider": "payments-provider", "id": "acct_9931" },
    "payload": { "amount": 5000, "currency": "USD" },
    "taskAuthorization": { "taskId": "task_42", "externalActionId": "pay_001" },
    "runtime": { "toolName": "payments.transfer", "toolVersion": "3.4.1" },
    "executorAudience": "payments-worker"
  },
  "idempotency_key": "transfer-2026-08-11-001",
  "provider": "payments-provider",
  "operation": "transfers.create",
  "request": { "amount": 5000, "currency": "USD", "to": "acct_9931" }
}

La réponse est signée et comprend le hachage d'action, le résumé des politiques, l'identité de l'exécuteur API-key, le hachage de demande en aval et les délais de preuve. L'autorisation d'exécution échoue lorsque l'enveloppe omet l'agent, la cible, l'autorisation de tâche ou le modèle/l'outil en version nécessaire au replay.

Préserver les relevés et les résultats du fournisseur#

Ajouter chaque tentative avec POST /v1/executions/{id}/attemptsC'est vrai. Chaque tentative signée conserve son numéro de réessayer, les hachages de requête et de réponse, le statut du fournisseur et l'ID de transaction, la classe d'erreur et les timestamps.

Vérifier ce qui s'est passé#

Ajouter l'état observé avec POST /v1/executions/{id}/effectsC'est vrai. Les preuves peuvent être signées par un fournisseur, lues à partir d'un registre, attestées par du matériel, appuyées par des enjeux, liées à Task Guard ou autodéclarées. La preuve autodéclarée demeure non vérifiée plutôt que présentée comme une preuve indépendante. Le fournisseur, le grand livre, le matériel et les résultats soutenus par les enjeux ne sont vérifiés qu'après qu'un vérificateur indépendant configuré retourne un reçu signé lié à la preuve exacte.

Étudier les lacunes#

• GET /v1/executions/{id} reconstruit le cycle de vie complet.
• GET /v1/executions/incomplete trouve des preuves d'exécution ou d'effet en retard.
• Lorsqu'un fournisseur d'ancrage indépendant est configuré, GET /v1/audit/anchors/latest retourne son dernier reçu, son horodatage de confiance et ses vérifications d'intégrité locales. D'ici là, le paramètre retourne 404 au lieu de présenter un enregistrement local comme preuve de tiers.

Utilisation govern:checkpoints:write autoriser ou annexer des éléments de preuve et govern:checkpoints:read pour enquêter sur les reçus.