Autorisiere die Wirkung, nicht nur den Zugriff auf das Werkzeug.
Zugriffskontrolle begrenzt, was Software erreichen kann. Execution Authorization begrenzt die exakte Wirkung, die sie verursachen darf. Action Proof ist das Protokoll, das die überprüfbare Kette erzeugt: ein signierter Einmal-Grant für eine kanonische Operation, durchgesetzt an einem Punkt, den du kontrollierst, und abgeschlossen mit Evidenz, die jeder offline prüfen kann.
Kryptografischer Beweis der Autorisierung. Signierte Evidenz des Ausführungsergebnisses. Ein Execution Grant belegt, was autorisiert wurde; ein Action Receipt bewahrt signierte Evidenz des Ergebnisses, das der enrollte Guardian feststellen konnte.
Cloud autorisiert, Ihr Guardian führt aus
Mandantenbezogene Schlüssel, Zugangsdaten mit geringsten Rechten
Signierte Belege, offline überprüfbar
POST https://mcp.securestamp.online/mcp
Authorization: Bearer ss_live_...
{ "jsonrpc":"2.0", "id":1, "method":"tools/list" }Zugriff ist keine Befugnis zu handeln
Zugriff auf den Zahlungsdienstleister ist nicht dasselbe wie die Autorisierung für eine bestimmte Rückerstattung.
Zugriff
Agent darf die Rückerstattungs-APIs des Zahlungsdienstleisters aufrufen
Execution Authorization
refund.create charge ch_89172 amount USD 1.427,00 destination original_payment_method maxUses 1 expires 14:02 UTC
Ressourcenautorisierung beantwortet, worauf ein Principal zugreifen darf. Execution Authorization beantwortet, welche transaktionsspezifische Wirkung er verursachen darf. Fine-grained Zugriff lässt die Transaktion selbst weiterhin undefiniert: welche Ressource, welcher Betrag, welches Ziel, wie oft.
Drei Schritte
Definieren
Welche exakte Wirkung wird angefordert? Der Guardian — nicht das Modell — liest den Provider-Zustand und normalisiert ihn zu einer kanonischen Operation mit expliziten Parametern.
Autorisieren
Binde diese Wirkung an einen signierten Einmal-Execution-Grant innerhalb deiner Richtlinie, auf der Autorität, die das Protokoll für diese Operation verlangt.
Verifizieren
Führe an einem Punkt aus, den du kontrollierst, und bewahre ein signiertes Action Receipt, das sich offline nachrechnen lässt.
read_message_request
Gibt zurück, was eine Nachricht verlangt — nur aus Signalen. Nachrichteninhalte verlassen das Gerät nie.
analyze_message_intent
Bildet abstrakte Signale auf sensible Handlungsabsichten ab. Nur Signale, kein Rohtext.
verify_counterparty
Prüft, ob ein Absender oder eine Gegenpartei mit dem Mandantenregister übereinstimmt.
get_safe_next_step
Berechnet den sichersten nächsten Schritt aus deklarierten Registerfakten.
authorize_action
Liefert ein Action Verdict, einen Safe Next Step und einen Beleg vor einer sensiblen Aktion.
create_action_challenge
Erstellt eine manuelle Vier-Augen-Rückfrage an eine bekannte Gegenpartei.
issue_action_receipt
Stellt einen signierten Action Receipt für bereits berechnete Fakten aus.
get_source_envelope
Ruft das auf dem Gerät signierte Envelope ab, das ein Mensch tatsächlich gesehen und freigegeben hat.
request_execution_grant
Fordert einen einmalig verwendbaren Grant für genau einen Effekt an. Liefert ein HOLD, bis die erforderliche menschliche oder Quorum-Autorität zustimmt.
get_execution_status
Meldet den Stand einer Ausführung, einschließlich Ergebnissen, die tatsächlich noch unbestimmt sind.
Ausführungsschicht
Der Grant ist keine Erlaubnis zum Improvisieren
Ein Execution Grant ist an ein Wirkungs-Digest und an die geltende Richtlinienversion gebunden, läuft ab und lässt sich genau einmal verwenden. Dein Guardian liest den Provider-Zustand unmittelbar vor der Mutation erneut, beansprucht den Grant gegen sein eigenes Ledger und signiert das Ergebnis — auch mehrdeutige Ergebnisse. Ein wiedereingespielter Grant erreicht nie einen Provider.
- Grants sind Einmal-Grants und an genau ein Wirkungs-Digest gebunden. maxUses ist immer 1.
- Die erforderliche Autorität legt das Protokoll fest; ein Aufrufer kann sie nicht herabstufen.
- Jede Vergabe von Privilegien verlangt M-von-N-Quorum, und wer anfragt, kann die eigene Anfrage nie genehmigen.
- Quorum-Profile sind signierte Richtlinien-Snapshots, keine Autoritätswerte: Der Beweis beruht auf dem Threshold, der Approver-Liste und dem Policy-Hash.
- Ergebnisse sind succeeded, failed_no_effect oder indeterminate — Mehrdeutigkeit wird nie aufgerundet.
- Proof Bundles verifizieren offline, ohne Rückruf an SecureStamp.
Parabel 3
Der Agent hält inne, bevor er ein Konto ändert
Ein Workflow erhält die Anfrage eines Lieferanten, die Bankverbindung zu ändern. Statt das Konto zu aktualisieren, ruft er authorize_action über den Remote-MCP-Guard mit einem Hash und abstrakten Signalen auf. SecureStamp antwortet mit needs_confirmation und einem Safe Next Step: die Gegenpartei rückfragen. Nichts wird ausgeführt, bevor ein Mensch antwortet.
Der Agent erkennt eine sensible Aktion
Er identifiziert eine Änderung der Bankverbindung und sendet nur strukturierte Signale plus einen sourceMessageHash.
SecureStamp prüft Tenant-Fakten
Der API-Key begrenzt die Abfrage auf einen Owner-Graph, deklarierte Richtlinien und registrierte Instruktionen.
Der Agent erhält ein Verdict
Die Antwort ist ein Entscheidungsdatensatz mit Safe Next Step und receiptId, keine Erlaubnis auszuführen.
Menschen oder Gegenparteien bestätigen
Falls nötig, öffnet create_action_challenge einen manuellen Bestätigungspfad, bevor die Operation fortfährt.
Lokale Autorisierungs-Obergrenze
Cloud-Autorisierung ist notwendig, für sich allein aber nie hinreichend.
Ein Grant wird nur dann zur Ausführung, wenn er auch zu der Richtlinie passt, die deine Organisation signiert und neben dem Guardian installiert hat. Diese Richtlinie ist deny-only: Sie fixiert Tenant, Gateway, Operationen, Adapter-Manifeste, akzeptierte Autoritäten und Richtlinienversionen, Ressourcen, Parameter, monetäre Limits, Nebenläufigkeit und Netzwerkziele. Der Produktivmodus weigert sich, ohne sie zu starten.
effektive Berechtigung =
Cloud-Grant
∩ signierte lokale Richtlinie
∩ Adapter-Einschränkungen
∩ Kill SwitchesSecureStamp Cloud kann eine Autorisierung enger machen. Sie kann sie nicht weiter machen, als deine Organisation es lokal erlaubt hat.
Verträge
Was der Verifizierer nachrechnet
ExecutionGrantV1Das Autorisierungs-Artefakt. Trägt das Wirkungs-Digest, die Autorität, die Richtlinienversion (apol_v1:) und den Ablauf. maxUses ist 1.
ActionReceiptV2 / V3Das Evidenz-Artefakt. V3 ergänzt die Richtlinienversion und das Digest der signierten lokalen Richtlinie (gpol_v1:), die die Ausführung begrenzt hat. V2 bleibt byte-kompatibel für die Historie.
ActionProofBundleV1 / V2Alles, was ein Dritter braucht, um die Kette nachzurechnen. V2 ergänzt die signierte lokale Richtlinie und den Assurance-Deskriptor des Connectors.
AdapterManifestV1Ein in sich geschlossener, unveränderlicher Deskriptor genau einer Connector-Operation. Der Verifizierer prüft das Manifest im Bundle, statt es neu zu erzeugen, sodass neue Operationen alte Beweise nie entwerten.
Ein Receipt offline verifizieren
Der Verifizierer ist ein eigenes veröffentlichtes Paket ohne Netzwerkzugriff, und er erscheint vor den Artefakten, die er verifiziert. Receipts lassen sich offline verifizieren, ohne SecureStamp zu kontaktieren, und die Verifikation hängt nicht von einem laufenden SecureStamp-Dienst ab.
npx --package @securestamp/action-proof-verify action-proof-verify bundle.json
Grenzen der Evidenz
Ein Action Receipt belegt, was durch einen enrollten Guardian lief, und das Ergebnis, das dieser Guardian feststellen konnte. Es belegt nicht, dass außerhalb von SecureStamp keine Aktion stattfand, und begründet auch kein rechtliches Eigentum am Provider-Konto. Die Evidenzgrenze ist der enrollte Ausführungspfad.