Ausführungsquittungen von KI-Agenten

Eine Genehmigung besagt, dass ein KI-Agent handeln kann. Ein Ausführungsbeleg verbindet diese Genehmigung mit der genauen gesendeten Anforderung und dem danach beobachteten Ergebnis.

Maetra verwendet den gleichen kanonischen Action-Hash für den Vorschlag, die unterzeichnete Entscheidung, die Ausführungsautorisierung, die Anbieterversuche und den Effektbeweis. Wenn einer dieser Links fehlt, wird der Lebenszyklus als unvollständig markiert.

Autorisieren Sie die genaue Ausführung#

Anruf POST /v1/executions/authorize unmittelbar vor der äußeren Nebenwirkung. Der Endpunkt verbraucht einmal eine genehmigte Fähigkeit und lehnt eine geänderte Nutzlast, einen falschen Arbeitsbereich oder einen Executor ab, abgelaufene oder widerrufene Genehmigung, geänderte Richtlinienverdauung oder Wiederholung.

{
  "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" }
}

Die Antwort ist signiert und umfasst den Action Hash, Policy Digest, Executor API-Key Identity, Downstream Request Hash und Evidenz-Fristen. Die Ausführungsautorisierung schlägt fehl, wenn der Umschlag die für die Wiederholung erforderliche Agent-, Ziel-, Aufgabenautorisierung oder versionierte Modell-/Tool-Laufzeit auslässt.

Retries und Provider-Ergebnisse bewahren#

Jeden Versuch mit POST /v1/executions/{id}/attempts. Jeder signierte Versuch behält seine Retry-Nummer, Anfrage- und Antwort-Hashes, den Provider-Status und die Transaktions-ID, die Fehlerklasse und die Zeitstempel.

Überprüfen Sie, was passiert ist#

Beobachteter Zustand mit POST /v1/executions/{id}/effects. Evidenz kann vom Anbieter signiert, aus einem Ledger gelesen, Hardware-beglaubigt, Stake-backed, mit Task Guard verknüpft oder selbst gemeldet markiert werden. Selbstberichtete Beweise bleiben nicht verifiziert, anstatt als unabhängige Beweise präsentiert zu werden. Provider-, Ledger-, Hardware- und Stake-Backed-Ergebnisse werden erst verifiziert, nachdem ein konfigurierter unabhängiger Verifikator eine signierte Quittung zurückgegeben hat, die an die genauen Beweise gebunden ist.

Untersuchung von Lücken#

• GET /v1/executions/{id} rekonstruiert den gesamten Lebenszyklus.
• GET /v1/executions/incomplete findet überfällige Ausführung oder Wirkung Beweise.
• Wenn ein unabhängiger Ankeranbieter konfiguriert ist, GET /v1/audit/anchors/latest gibt die letzte Quittung, den vertrauenswürdigen Zeitstempel und die lokalen Integritätsprüfungen zurück. Bis dahin kehrt der Endpunkt zurück 404 anstatt einen lokalen Datensatz als Beweis von Drittanbietern vorzulegen.

Verwendung govern:checkpoints:write Beweismittel zu genehmigen oder beizufügen und govern:checkpoints:read Quittungen zu untersuchen.