Autorisez l’effet, pas seulement l’accès à l’outil.
Le contrôle d’accès limite ce que le logiciel peut atteindre. Execution Authorization délimite l’effet exact qu’il peut causer. Action Proof est le protocole qui produit la chaîne vérifiable : un grant signé à usage unique pour une opération canonique, appliqué à un point que vous contrôlez, et clos par une preuve que n’importe qui peut vérifier hors ligne.
Preuve cryptographique de l’autorisation. Preuve signée du résultat de l’exécution. Un Execution Grant prouve ce qui a été autorisé ; un Action Receipt conserve la preuve signée du résultat que le Guardian enrôlé a pu établir.
Le cloud autorise, votre Guardian exécute
Clés par locataire, identifiants à moindre privilège
Reçus signés, vérifiables hors ligne
POST https://mcp.securestamp.online/mcp
Authorization: Bearer ss_live_...
{ "jsonrpc":"2.0", "id":1, "method":"tools/list" }L’accès n’est pas une autorisation d’agir
Avoir accès au prestataire de paiement n’est pas la même chose qu’être autorisé à effectuer un remboursement précis.
Accès
L’agent peut appeler les API de remboursement du prestataire de paiement
Execution Authorization
refund.create charge ch_89172 amount USD 1 427,00 destination original_payment_method maxUses 1 expires 14:02 UTC
L’autorisation de ressources répond à ce à quoi un principal peut accéder. Execution Authorization répond à l’effet, spécifique à une transaction, qu’il peut causer. Un accès fine-grained laisse la transaction elle-même indéfinie : quelle ressource, quel montant, quelle destination, combien de fois.
Trois étapes
Définir
Quel effet exact est demandé ? Le Guardian — pas le modèle — lit l’état du fournisseur et le normalise en une opération canonique avec des paramètres explicites.
Autoriser
Liez cet effet à un Execution Grant signé à usage unique à l’intérieur de votre politique, à l’autorité que le protocole exige pour cette opération.
Vérifier
Exécutez à un point que vous contrôlez et conservez un Action Receipt signé qui se recalcule hors ligne.
read_message_request
Renvoie ce qu'un message demande, à partir de signaux seulement. Le corps ne quitte jamais l'appareil.
analyze_message_intent
Fait correspondre des signaux abstraits à des intentions d'action sensible. Signaux seulement, jamais de texte brut.
verify_counterparty
Vérifie si un expéditeur ou une contrepartie correspond au registre du locataire.
get_safe_next_step
Calcule l'étape suivante la plus sûre à partir de faits déclarés au registre.
authorize_action
Renvoie un Action Verdict, un Safe Next Step et un reçu avant une action sensible.
create_action_challenge
Crée une contre-vérification manuelle à double contrôle auprès d'une contrepartie connue.
issue_action_receipt
Émet un Action Receipt signé pour des faits déjà calculés.
get_source_envelope
Récupère l'enveloppe signée sur l'appareil que la personne a réellement vue et approuvée.
request_execution_grant
Demande un grant à usage unique pour exécuter un effet exact. Renvoie un HOLD jusqu'à ce que l'autorité humaine ou le quorum requis approuve.
get_execution_status
Indique où en est une exécution, y compris les résultats réellement encore indéterminés.
Couche d'exécution
Le grant n'est pas une permission d'improviser
Un Execution Grant est lié à un digest d’effet et à la version de politique en vigueur, expire, et s’utilise exactement une fois. Votre Guardian relit l’état du fournisseur juste avant la mutation, réclame le grant contre son propre ledger et signe le résultat — y compris les résultats ambigus. Un grant rejoué n’atteint jamais un fournisseur.
- Les grants sont à usage unique et liés à un seul digest d’effet exact. maxUses vaut 1, toujours.
- L’autorité requise est fixée par le protocole ; un appelant ne peut pas la rétrograder.
- Tout octroi de privilège exige un quorum M-de-N, et le demandeur ne peut jamais approuver sa propre demande.
- Les profils de quorum sont des snapshots de politique signés, pas des valeurs d’autorité : la preuve repose sur le threshold, la liste des approbateurs et le hash de la politique.
- Les résultats sont succeeded, failed_no_effect ou indeterminate — l’ambiguïté n’est jamais arrondie vers le haut.
- Les proof bundles se vérifient hors ligne, sans rappel vers SecureStamp.
Parabole 3
L’agent s’arrête avant de modifier un compte
Un workflow reçoit une demande de changement de coordonnées bancaires d'un fournisseur. Au lieu de mettre à jour le compte, il appelle authorize_action via le MCP Guard distant avec une empreinte et des signaux abstraits. SecureStamp renvoie needs_confirmation et une Safe Next Step : interroger la contrepartie. Rien ne s'exécute avant qu'une personne ne réponde.
L’agent détecte une action sensible
Il identifie un changement de coordonnées bancaires et n’envoie que des signaux structurés plus un sourceMessageHash.
SecureStamp vérifie les faits du tenant
La clé d’API restreint la requête à un seul owner graph, aux politiques déclarées et aux instructions enregistrées.
L’agent reçoit un verdict
La réponse est un enregistrement de décision avec Safe Next Step et receiptId, pas une permission d’exécuter.
Humains ou contreparties confirment
Si nécessaire, create_action_challenge ouvre un chemin de confirmation manuelle avant que l’opération ne se poursuive.
Plafond d’autorisation local
L’autorisation cloud est nécessaire, mais jamais suffisante à elle seule.
Un grant ne devient une exécution que s’il entre aussi dans la politique que votre organisation a signée et installée à côté du Guardian. Cette politique est deny-only : elle fixe tenant, gateway, opérations, manifests d’adaptateur, autorités et versions de politique acceptées, ressources, paramètres, limites monétaires, concurrence et destinations réseau. Le mode production refuse de démarrer sans elle.
permission effective =
grant cloud
∩ politique locale signée
∩ contraintes de l’adaptateur
∩ kill switchesSecureStamp Cloud peut rendre une autorisation plus étroite. Il ne peut pas la rendre plus large que ce que votre organisation a autorisé localement.
Contrats
Ce que le vérificateur recalcule
ExecutionGrantV1L’artefact d’autorisation. Il porte le digest de l’effet, l’autorité, la version de politique (apol_v1:) et l’expiration. maxUses vaut 1.
ActionReceiptV2 / V3L’artefact de preuve. V3 ajoute la version de politique et le digest de la politique locale signée (gpol_v1:) qui a délimité l’exécution. V2 reste compatible octet par octet pour l’historique.
ActionProofBundleV1 / V2Tout ce dont un tiers a besoin pour recalculer la chaîne. V2 ajoute la politique locale signée et le descripteur d’assurance du connecteur.
AdapterManifestV1Un descripteur autonome et immuable d’une seule opération de connecteur. Le vérificateur contrôle le manifest présent dans le bundle au lieu de le régénérer, si bien que de nouvelles opérations n’invalident jamais d’anciennes preuves.
Vérifier un receipt hors ligne
Le vérificateur est un paquet publié à part, sans accès réseau, et il sort avant les artefacts qu’il vérifie. Les receipts se vérifient hors ligne sans contacter SecureStamp, et la vérification ne dépend pas d’un service SecureStamp en fonctionnement.
npx --package @securestamp/action-proof-verify action-proof-verify bundle.json
Limites de la preuve
Un Action Receipt prouve ce qui est passé par un Guardian enrôlé et le résultat que ce Guardian a pu établir. Il ne prouve pas qu’aucune action n’a eu lieu en dehors de SecureStamp, et n’établit pas non plus la propriété légale du compte fournisseur. La limite de la preuve, c’est le chemin d’exécution enrôlé.