Un protocole de confiance pour
l’autorisation de l’effet exact.
SecureStamp étend la confiance numérique de l’origine et de l’intention jusqu’à l’exécution. Les décisions approuvées deviennent des autorités d’exécution délimitées, encadrées par une politique contrôlée par le client et suivies d’une preuve vérifiable de manière indépendante.
Gmail, Outlook et Apple Mail, avec la preuve d’origine dans la boîte de réception
Canaux officiels
WhatsApp, Telegram et le périmètre qu’une marque déclare
Agents et API
Outils MCP, API et workflows autonomes
Architecture du protocole
La confiance avant d’agir. La preuve après l’exécution.
Une seule pile de confiance, appliquée à chaque surface.
SecureStamp n’est pas un vérificateur d’e-mails avec une fonction agent greffée dessus. Origine, intention, autorisation d’exécution et preuve d’exécution sont quatre couches d’une même chaîne — et cette chaîne fonctionne pareil que l’instruction arrive dans une boîte de réception, dans une messagerie ou via un appel d’outil MCP.
SecureStamp étend la confiance de l’instruction jusqu’à la conséquence.
Pile de confiance
Origine
D’où cela vient-il ? Domaines, en-têtes, signatures, identité déclarée et périmètre du canal. Preuve d’appui — nécessaire, et jamais le titre.
Intention
Que demande-t-on ? L’action demandée est lue et énoncée en premier : payer, approuver, livrer des identifiants, invoquer un outil. Un signal d’entrée, pas une preuve.
Execution Authorization
Quel effet exact peut être causé ? Une décision approuvée devient une autorité délimitée à usage unique pour une opération canonique sous des contraintes explicites.
Preuve d’exécution
Quelle autorisation a été consommée, et quel résultat le point d’exécution a-t-il pu établir ? Un reçu signé que n’importe qui peut vérifier hors ligne.
Appliqué à
Gmail · Outlook · Apple Mail
Canaux officiels
WhatsApp · Telegram · périmètres déclarés
Agents
Clients MCP et copilotes
APIs
Intégrations directes
Workflows
Automatisations et services délégués
Execution Authorization s’applique partout où l’autorité est déléguée à un logiciel, pas seulement aux agents IA. Une automatisation, un workflow ou un service délégué agissant au nom d’autrui pose la même question : quel effet exact a été approuvé ?
Thèse du protocole
Le nouveau périmètre, c’est l’action.
D’abord nous avons défendu les appareils contre les malwares et les chevaux de Troie. Puis les boîtes de réception contre le phishing. Aujourd’hui le logiciel agit en notre nom, et la question n’est plus seulement ce qu’il peut atteindre — c’est ce qu’il peut changer.
Messages, événements et prompts peuvent déclencher des API, des appels d’outils, des workflows et des opérations d’argent numérique. SecureStamp propose des signaux vérifiables avant qu’une communication ne devienne une action.
L’identité contrôle qui peut accéder à un système. SecureStamp délimite l’effet exact que le logiciel autonome est autorisé à causer.
Quatre couches
L’authentification établit l’identité. Le contrôle d’accès limite la portée. Execution Authorization délimite l’effet.
Authentification
Qui ou quoi agit ?
Autorisation d’accès
À quelles ressources peut-il accéder ?
Execution Authorization
Quel effet exact peut-il causer ?
Preuve d’exécution
Quelle autorisation a été consommée, et quel résultat le point d’exécution a-t-il pu établir ?
La quatrième question est formulée à dessein. Un résultat qui ne peut pas être établi reste indéterminé, et aucune couche de cette pile ne prétend le contraire.
Où nous nous situons
SecureStamp commence là où la décision s’arrête.
Les systèmes d’identité, de politique et d’approbation décident si une action doit se poursuivre. SecureStamp lie cette décision approuvée à l’effet exact qui peut être exécuté.
Décider
Qu’est-ce qui devrait être permis ? Ce sont l’identité, les policy engines, les approbations et les humains qui répondent.
Autoriser
Quel effet exact est permis ? C’est la couche qu’ajoute SecureStamp.
Exécuter
Appliquer cet effet dans les contraintes du client, à un point que le client contrôle.
Vérifier
Quelle autorisation a été consommée, et quel résultat le point d’exécution a-t-il pu établir ?
SecureStamp ne remplace ni l’identité, ni les policy engines, ni les workflows d’approbation, ni les API des fournisseurs. Il lie leurs décisions approuvées à des effets exécutables exacts.
SecureStamp fournit des signaux vérifiables et des autorisations délimitées. Il ne remplace ni les politiques internes, ni les permissions, ni le sandboxing, ni l’approbation humaine, ni les contrôles de sécurité existants.
Appareils
Le premier périmètre moderne fut l’appareil : malwares, chevaux de Troie, fichiers dangereux et comportement local.
Boîtes de réception
Puis le risque s’est déplacé vers les messages : domaines sosies, faux liens, pièces jointes, urgence de paiement et usurpation.
Actions
Aujourd’hui, une instruction peut ouvrir des outils, appeler des API, traiter des factures, déplacer des données ou préparer des paiements.
Trust checks
SecureStamp lit ce qu'un message demande — payer, approuver, livrer des identifiants, invoquer un outil — et l'étaye par des preuves d'origine, de canal et de contexte avant de répondre, de payer, de partager des données ou d'exécuter un workflow.
Agnostique au canal
Un standard agnostique au canal
SecureStamp n’est pas conçu pour une boîte de réception, une application ou un secteur. Le protocole organise les signaux autour de l’origine, du canal, de l’intention déclarée et de l’action. Il peut s’appliquer à l’e-mail, la messagerie, les QR, les sites web, les factures, les tickets, les API, les agents et les opérations d’argent numérique.
Autorité déléguée
Partout où l’autorité est déléguée à un logiciel.
Un agent, une automatisation, un workflow ou un service délégué agissant au nom d’autrui soulèvent tous la même question. La permission d’accès dit ce qu’ils peuvent atteindre ; elle ne définit pas l’effet exact approuvé pour cette transaction.
MCP pour les agents
SecureStamp MCP Server
MCP est la façon dont les applications d’IA atteignent outils, données et workflows. SecureStamp se place devant cette portée : le logiciel demande ce qu’une instruction réclame vraiment, qui est la contrepartie et quel effet exact elle peut causer — avant que quoi que ce soit ne s’exécute.
SecureStamp autorise ; il ne détient jamais vos credentials fournisseur en aval. Quand une opération doit réellement s’exécuter, le grant signé voyage vers un Execution Guardian que vous opérez, et seul ce daemon touche le fournisseur.
read_message_request(...)analyze_message_intent(...)verify_counterparty(...)get_safe_next_step(...)authorize_action(...)create_action_challenge(...)issue_action_receipt(...)get_source_envelope(...)request_execution_grant(...)get_execution_status(...)Flux conceptuel
agent → read_message_request → analyze_message_intent → get_safe_next_step → request_execution_grant → Execution Guardian → ActionReceiptV3Signal Framework
SSF: SecureStamp Signal Framework
SSF organise d'abord l'action demandée, puis les signaux de contenu, d'origine, d'authentification, de canal et de contexte, pour produire une sortie simple, auditable et lisible par les humains, les systèmes et les agents.
Requested Action
Répondre, ouvrir, payer, transférer, approuver, partager des données, invoquer des outils ou exécuter des workflows.
Content Signals
Urgence, liens, pièces jointes, identifiants, instructions de paiement et changements de coordonnées bancaires.
Origin Signals
Domaine, organisation, identité déclarée, expéditeur.
Technical Signals
SPF, DKIM, DMARC, DNS TXT, en-têtes, signatures, clés et receipts.
Channel Signals
E-mail, web, WhatsApp, Telegram, QR, API, support, facturation et tickets.
Verdict Layer
Trust, Signal et Action Verdict : une sortie lisible et auditable qui énonce d'abord l'action demandée et présente les preuves d'origine en dessous.
Trois signaux d’entrée, puis l’autorisation
Proof of Origin répond d’où vient une instruction. Proof of Intent énonce ce qu’elle demande. Action Verdict recommande si elle doit se poursuivre. Les trois sont des signaux qui alimentent une décision — et une décision n’est pas encore une autorisation.
Proof of Intent
Que demande-t-on ? Un signal d’entrée qui énonce d’abord l’action demandée. Ce n’est pas une preuve de ce qui a été autorisé.
Proof of Origin
D’où cela vient-il ? Domaine, organisation, canal, expéditeur, timbre et signaux techniques. Preuve d’appui.
Action Verdict
Faut-il poursuivre ? Un signal de décision. Ce qui se passe après cette décision, c’est Execution Authorization.
Couche d'exécution
Public Beta · accès en production contrôléUn verdict n'est pas une preuve.
Un verdict peut recommander si une action doit se poursuivre. À lui seul, il ne prouve pas l’effet exact qui a été autorisé, l’autorité derrière lui, si l’autorisation a été réutilisée, ni le résultat observé à l’exécution.
Action Proof crée cette chaîne de preuves. Une décision approuvée devient une autorité exécutable délimitée : un effet exact, une autorité, une expiration, un usage — vérifiable hors ligne, par n’importe qui.
L’accès n’est pas une autorisation d’agir
L’accès contrôle ce que le logiciel peut atteindre. Execution Authorization délimite l’effet exact qu’il peut causer.
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.
Autorisez l’effet, pas seulement l’accès à l’outil.
Plafond contrôlé par le client
Votre politique est le plafond.
SecureStamp Cloud peut rendre une autorisation plus étroite. Il ne peut pas la rendre plus large que la politique que votre organisation a signée et installée localement. L’autorisation cloud est nécessaire, mais jamais suffisante à elle seule.
Permission effective
permission effective =
grant cloud
∩ politique locale signée
∩ contraintes de l’adaptateur
∩ kill switches- La politique locale est un document que votre organisation signe avec sa propre clé et installe à côté du Guardian. 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.
- Elle est deny-only par construction. Elle n’a aucun champ capable d’accorder quelque chose que le cloud n’a pas accordé.
- Démarrer en mode production sans politique locale signée et valide n’est pas signalé par un avertissement : c’est refusé au démarrage.
- Les kill switches existent au niveau global et par fournisseur, opération, tenant et gateway — et de nouveau dans la politique locale elle-même. Ils arrêtent des grants déjà émis.
- Les politiques portent une date de revue obligatoire et une expiration facultative. Une politique expirée bloque les nouvelles mutations tout en laissant intacts statut, preuve, relecture et réconciliation.
- La récupération de clés est M-de-N et hors ligne. Le support SecureStamp ne peut pas se substituer à ce contrôle, et c’est précisément le but.
- Un plan de contrôle cloud compromis ne peut toujours pas dépasser l’autorité permise localement.
Hébergé par le client
Nous autorisons. Vous exécutez.
Le Guardian tourne dans votre environnement et détient les credentials du fournisseur. SecureStamp Cloud ne reçoit pas les credentials du fournisseur et n’appelle jamais votre fournisseur.
- Les credentials du fournisseur sont montés comme des fichiers appartenant à root, jamais comme variables d’environnement ni configuration en ligne.
- Le bridge MCP — le processus le plus proche du modèle — n’a besoin ni de credentials fournisseur ni de SDK cloud.
- L’effet est résolu à partir de l’état que le daemon lit lui-même, jamais de paramètres fournis par le modèle.
- L’état antérieur est relu juste avant la mutation ; un changement matériel invalide le grant au lieu de l’écraser.
Chaîne de preuve
Cinq maillons, chacun signé par une partie différente
Preuve cryptographique de l’autorisation. Preuve signée du résultat de l’exécution.
Source Envelope
Le plugin signe ce que la personne a réellement vu, sur l’appareil, avec une clé qui n’en sort jamais. Le corps des messages n’est jamais transmis.
Action Effect
Le Guardian — pas le modèle — lit l’état du fournisseur et normalise l’effet exact : fournisseur, opération, ressources, paramètres et un digest de l’état antérieur.
Execution Grant
SecureStamp Cloud signe un grant à usage unique lié à ce digest d’effet, à l’autorité qui l’a approuvé, à la version de politique en vigueur et à une expiration. maxUses vaut 1, toujours.
Execution Claim
Votre Guardian réclame le grant contre son propre ledger. Un grant rejoué est rejeté avant que le moindre fournisseur ne soit contacté.
Action Receipt
Le Guardian signe l’autorisation consommée, le contexte d’exécution et le résultat qu’il a pu établir, avec le digest de la politique locale qui l’a délimité.
Autorité
Aucune requête ne porte sa propre permission.
L’autorité qu’exige une opération est fixée par le protocole. L’appelant ne peut pas la choisir, le modèle ne peut pas plaider pour elle, et elle ne peut pas être rétrogradée à l’intérieur de la requête qui en a besoin. Les profils de quorum sont des snapshots de politique signés, pas des valeurs d’autorité : standard et elevated sont des libellés pour les humains, tandis que la preuve repose sur le threshold, la liste des approbateurs et le hash de la politique.
noneN’accorde jamais l’exécution. Elle existe pour que son absence soit explicite plutôt qu’implicite.
policy_delegatedAutonomie à l’intérieur d’une politique définie à l’avance par l’organisation, et uniquement pour une requête signée sur l’appareil. Jamais pour une requête corrélée.
human_mfaUne personne identifiée approuve contre une session MFA active. Utilisé là où l’effet est délimité et réversible en pratique.
quorumM-de-N approbateurs indépendants, chacun avec sa propre session MFA, contre une politique définie à l’avance. Le demandeur ne peut jamais approuver sa propre demande. Obligatoire pour tout octroi de privilège.
Sûreté en cas d’échec
L’inconnu reste inconnu.
Une réponse ambiguë du fournisseur reste indéterminée jusqu’à réconciliation. Les opérations mutantes ne sont pas réessayées à l’aveugle.
Une API de paiement dépasse le délai après avoir reçu une mutation. La répéter peut dupliquer l’effet. SecureStamp ne suppose pas l’échec et ne réessaie pas : le Guardian réconcilie l’état du fournisseur et peut renvoyer indeterminate. L’ambiguïté est un résultat de première classe et n’est jamais arrondie à un succès.
Vérification indépendante
Vérifiez la chaîne sans nous le demander.
Le vérificateur est un paquet publié sans accès réseau. Il recalcule hors ligne chaque digest et chaque signature d’un proof bundle, y compris le hash du snapshot de politique et le digest de la politique locale signée. 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.jsonLe vérificateur sort avant les artefacts qu’il vérifie. Une nouvelle version de receipt ou de bundle n’est jamais émise avant qu’un vérificateur publié ne l’accepte déjà.
Connecteurs
Apportez le point d’exécution que vous utilisez déjà.
Le modèle d’autorisation de SecureStamp est indépendant du fournisseur. Ce sont des connecteurs de référence, pas un catalogue fermé. La façon dont un connecteur s’intègre et le degré auquel SecureStamp en répond sont deux questions distinctes, et nous les gardons séparées à dessein.
Comment ça se connecte
Adaptateur certifié
Un module que nous avons écrit, revu et lié à des preuves de certification publiées.
Adaptateur HTTPS déclaratif
Origine, méthode et path fixés à l’installation. Aucune URL, méthode ou header arbitraire venant du modèle, pas de redirects, schema strict, idempotence déterministe.
SDK / sidecar
Pour les protocoles qui ne peuvent pas satisfaire le contrat déclaratif, via un socket Unix.
Comment son assurance est déclarée
SecureStamp Certified
Nous l’avons écrit, nous l’avons revu, et nous avons publié les preuves.
Partner Attested
Un partenaire identifié en répond, et le bundle le dit.
Customer Defined
Vous l’avez construit. La chaîne se vérifie quand même, et le bundle déclare clairement que SecureStamp n’a pas certifié le code du connecteur.
Les adaptateurs traduisent un effet autorisé en exécution propre au fournisseur. Ils ne redéfinissent pas l’autorité accordée.
Stripe
refund.createhuman_mfaOkta
group.add_userhuman_mfaAWS
iam.attach_role_policyquorumGoogle Cloud
iam.project_binding.addquorumAzure
rbac.role_assignment.createquorumMicrosoft Entra
pim.directory_role_assignment.createquorumS’intègre à votre control plane existant
Fonctionne avec les contrôles que vous avez déjà.
SecureStamp ne remplace ni l’identité, ni les policy engines, ni les workflows d’approbation, ni les API des fournisseurs. Il lie leurs décisions approuvées à des effets exécutables exacts.
Limites de la preuve
Ce qu’un receipt établit et ce qu’il n’établit pas.
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é.
Les actions effectuées hors de ce chemin sortent du périmètre du receipt.
État de la version
Pourquoi ces paquets portent encore la mention bêta.
Le protocole, le code et le vérificateur sont complets et auditables aujourd’hui. Mais nous ne qualifions pas un connecteur de stable tant que nous n’avons pas publié la preuve de 100 exécutions réelles contre un fournisseur en production — y compris injection de fautes, rejet de rejeu et preuve que le credential n’aurait pas pu en faire plus — liée au commit exact qui les a produites. L’exécution en production exige un opt-in explicite et l’éligibilité du connecteur, et tant qu’un connecteur n’a pas passé cette porte, son Guardian refuse de tourner hors du mode sandbox. Un produit de confiance qui vous demande de le croire sur parole a déjà échoué.
Paquets
@securestamp/action-proof-verifyLe vérificateur hors ligne et ses contrats de vérification. Publié avant tout ce qu’il vérifie.
@securestamp/action-proofContrats, signature et proof bundles.
@securestamp/execution-guardianLe daemon hébergé par le client et ses connecteurs de fournisseur.
@securestamp/execution-guardian-mcpLe bridge MCP. Aucun credential, aucun SDK cloud, par construction.
Trust Levels
Trust Level explique l’origine. Action Verdict aide à décider de l’action.
Les niveaux L1-L5 notent la preuve d’origine vérifiable. Ils n’affirment pas que le contenu est vrai ni qu’une action doit s’exécuter automatiquement.
L1
Enregistré
Le domaine ou l’organisation est enregistré dans SecureStamp.
L2
Aligné
Les signaux techniques comme SPF, DKIM, DMARC ou DNS sont alignés.
L3
Signé
Le message, le canal ou l’événement inclut un jeton signé et vérifiable.
L4
Notarié
Une référence d’intégrité ou un reçu vérifiable existe pour un audit ultérieur.
L5
Certifié
L’identité organisationnelle derrière l’origine a été examinée avec des preuves supplémentaires.
Origine vérifiée ne veut pas dire action approuvée
Trust Level décrit la force de la preuve d’origine. Action Verdict évalue une action concrète à l’aide du SSF, du contexte et de la politique. Une origine légitime peut tout de même demander une action qui exige une révision.
Points d’intégration
Quatre façons de déclarer et d’interroger la confiance
DNS TXT record
Publiez un enregistrement TXT sous _securestamp.[domain]. Les vérificateurs résolvent le sous-domaine et valident l’origine déclarée sans inspecter de contenu privé.
- —v=1 — version du protocole
- —id=<stamp_id> — identifiant vérifiable
- —url=<verify_url> — URL canonique de vérification
_securestamp.example.com. 3600 IN TXT
"securestamp=v=1;
id=f47ac10b-58cc-4372-a567-0e02b2c3d479;
url=https://securestamp.org/verify/eyJhbG..."Email header
Injectez X-SecureStamp dans les messages sortants pour que clients, plugins et passerelles interrogent origine et statut avec des signaux signés.
- —Jeton signé par l’expéditeur ou un nœud autorisé
- —Claims minimaux : stampId, domain, orgId, score, exp
- —Clé publique ou référence vérifiable pour la validation
X-SecureStamp: v=1;
token=eyJhbGciOiJFUzI1NiJ9.eyJzdGFtcElkIjoiZjQ3YWMxM...;
verify=https://securestamp.org/verify/eyJhbG...REST API
Interrogez domaines, canaux ou actions sans stocker d’instructions sensibles en clair. Les réponses peuvent inclure des signaux, des reasons et des Trust Receipts.
- —Trust checks pour domaines et canaux
- —Action Verdict pour les actions sensibles
- —Receipts vérifiables pour l’audit
- —Vérificateur public et registry le cas échéant
GET https://securestamp.org/v1/trust/example.com{
"domain": "example.com",
"trustLevel": "L3",
"signals": { "spf": "pass", "dkim": "pass", "dmarc": "pass" },
"actionVerdict": "needs_confirmation",
"receiptRef": "tr_01h..."
}MCP Server
Couche Agent Trust active pour que les agents interrogent des trust checks avant les tool calls, APIs, workflows et opérations sensibles.
- —SecureStamp MCP Server
- —Tool call checks
- —Action Verdict avant l’exécution
- —Approbation humaine quand la politique l’exige
securestamp.get_action_verdict({
origin: "billing@example.com",
action: "payment_request",
amount: "1200.00",
destination: "acct_..."
})Official Channel Signal
Vérification des canaux officiels sur les surfaces conversationnelles
Signal permet de vérifier si un numéro, un bot, un identifiant, un lien, un compte ou un point de contact appartient au périmètre officiel déclaré par une entité. C’est la couche pour WhatsApp, Telegram, le web, les QR, le support, la facturation et les autres canaux par lesquels une personne ou un agent peut recevoir des instructions sensibles.
Périmètre officiel
Vérifie les canaux e-mail, WhatsApp, Telegram, web, QR, support et facturation contre des enregistrements vérifiables.
Connecté au SSF
Les signaux de canal alimentent Trust, Action Verdict et les receipts sans transformer une marque en garantie absolue.
Limite honnête
Signal vérifie l’appartenance au périmètre officiel. Il ne prouve pas que chaque message est vrai.
Receipts, registry et audit
Une preuve auditable sans dépendre de captures d’écran
Chaque requête ou déclaration pertinente peut générer un receipt vérifiable. Les receipts aident à auditer origine, canal, intention déclarée et Action Verdict sans faire confiance aveuglément à une interface.
Trust Receipts
Receipts signés résumant signal, contexte autorisé, horodatage et référence vérifiable.
Registry
Jetons, receipts et références publiques peuvent être vérifiés sans authentification quand le flux le permet.
Audit
Les organisations peuvent combiner les receipts avec leurs politiques internes, leurs approbations et leurs contrôles de conformité.
Glossaire public
Un langage commun pour utilisateurs, support et intégrateurs
The glossary explains SecureStamp, email, cryptography, Signal, E2EE, API and infrastructure terms so a non-technical person or junior developer can understand what they are reading.
Ouvrir le glossaireSecureStamp Terms
Concepts created or defined by SecureStamp to explain trust, stamps, receipts and verifiable perimeters.
Email, Domains and Authentication
Classic abbreviations used when SecureStamp explains whether a sender or domain is properly authenticated.
Cryptography and Security
Terms needed to understand signatures, encryption, keys, verifiable logs and enterprise recovery.
Protocols, APIs and Infrastructure
Common language for junior developers and integrators reading APIs, plugins, dashboards or runbooks.
Réseau fédéré
Réseau fédéré et nœuds approuvés
La SecureStamp Foundation coordonne un réseau de nœuds approuvés qui écrivent et vérifient des enregistrements partagés. Opérer un nœud exige une revue technique, un SLA et un alignement avec les principes de gouvernance.
Envoyer la demande
Indiquez organisation, région, capacité opérationnelle, SLA prévu, surface technique et cas d’usage déclaré.
Revue technique
La fondation évalue la capacité, la sécurité opérationnelle, la couverture et les conflits d’intérêts potentiels.
Identifiants délivrés
En cas d’approbation, l’opérateur reçoit ses identifiants et les exigences d’intégration pour rejoindre le réseau.
Exploitation auditée
Le nœud doit maintenir la disponibilité, la health publique, la traçabilité opérationnelle et des processus de réponse aux incidents.
Obligations du nœud
Registre vérifiable
Vérifier timbres, receipts et références publiques
Chaque timbre, receipt ou référence publique émis par SecureStamp peut être vérifié sans transformer ce site en page d’atterrissage commerciale. La fondation maintient le standard et les points d’interrogation.
securestamp.org/verify/[token]FAQ technique
Questions fréquentes des développeurs et intégrateurs
Qu’est-ce que la SecureStamp Foundation ?
L’entité qui publie et gouverne le standard ouvert SecureStamp pour vérifier origine, intention, canal et action avant d’opérer.
Quel problème le protocole résout-il ?
Il aide humains, systèmes et agents à interroger des signaux vérifiables avant de répondre, payer, partager des données, appeler des API ou exécuter des workflows.
Quel lien entre la pile de confiance et les surfaces ?
La pile de confiance, c’est Origine, Intention, Execution Authorization et Preuve d’exécution. Les surfaces sont l’e-mail, les canaux officiels, les agents, les API et les workflows. Ce sont deux axes indépendants : la même pile s’applique à chaque surface, et Execution Authorization est une couche, jamais une surface à part.
Qu’est-ce que Proof of Origin ?
Une preuve vérifiable qu’un domaine, un canal, un expéditeur ou une organisation correspond à une origine enregistrée.
Qu’est-ce que Execution Authorization ?
Le processus qui lie une décision approuvée à une autorité délimitée et propre à une transaction, permettant à un logiciel de causer un effet défini sous contraintes explicites. Le contrôle d’accès limite ce que le logiciel peut atteindre ; Execution Authorization délimite l’effet exact qu’il peut causer.
Qu’est-ce que Action Verdict ?
Une évaluation d’une action concrète avant exécution. Elle peut recommander autoriser, réviser, refuser ou demander une approbation humaine selon les signaux et la politique.
Qu’est-ce que le SSF ?
SecureStamp Signal Framework : un langage commun pour les signaux d’origine, d’authentification, de canal, de contenu, de contexte, d’action et de verdict.
Qu’est-ce que le SecureStamp MCP Server ?
Une direction en developer preview permettant aux agents d’interroger des trust checks avant des appels d’outils sensibles, via le Model Context Protocol.
Docs et spécification
Documentation du protocole
La spécification couvre Proof of Origin, Proof of Intent, SSF, Action Verdict, les points d’intégration, les receipts, les limites honnêtes et la direction MCP pour les agents.
Des questions sur la spécification ou la conception du protocole ? protocol@securestamp.org
Contact
Écrivez-nous
Chaque adresse mène directement à la bonne équipe. Pas de système de tickets — de vraies personnes.