Un protocollo di fiducia per
l’autorizzazione dell’effetto esatto.
SecureStamp estende la fiducia digitale dall’origine e dall’intenzione fino all’esecuzione. Le decisioni approvate diventano autorità di esecuzione delimitate, vincolate da una policy controllata dal cliente e seguite da prove verificabili in modo indipendente.
Gmail, Outlook e Apple Mail, con prova di origine nella casella di posta
Canali ufficiali
WhatsApp, Telegram e il perimetro che dichiara un brand
Agenti e API
Strumenti MCP, API e workflow autonomi
Architettura del protocollo
Fiducia prima di agire. Prova dopo l’esecuzione.
Un solo stack di fiducia, applicato a ogni superficie.
SecureStamp non è un controllore di email con una funzione agente attaccata sopra. Origine, intenzione, autorizzazione di esecuzione e prova di esecuzione sono quattro livelli di una sola catena — e quella catena funziona allo stesso modo che l’istruzione arrivi in una casella di posta, in un messenger o tramite una chiamata a uno strumento MCP.
SecureStamp estende la fiducia dall’istruzione fino alla conseguenza.
Stack di fiducia
Origine
Da dove arriva? Domini, header, firme, identità dichiarata e perimetro del canale. Prova di supporto — necessaria, e mai il titolo.
Intenzione
Che cosa viene chiesto? L’azione richiesta viene letta e dichiarata per prima: pagare, approvare, consegnare credenziali, invocare uno strumento. Un segnale in ingresso, non una prova.
Execution Authorization
Quale effetto esatto può essere causato? Una decisione approvata diventa un’autorità delimitata e monouso per una singola operazione canonica sotto vincoli espliciti.
Prova di esecuzione
Quale autorizzazione è stata consumata e quale esito ha potuto stabilire il punto di esecuzione? Una ricevuta firmata che chiunque può verificare offline.
Applicato a
Gmail · Outlook · Apple Mail
Canali ufficiali
WhatsApp · Telegram · perimetri dichiarati
Agenti
Client MCP e copiloti
APIs
Integrazioni dirette
Workflows
Automazioni e servizi delegati
Execution Authorization vale ovunque l’autorità venga delegata al software, non solo agli agenti IA. Un’automazione, un workflow o un servizio delegato che agisce per conto di qualcun altro pone la stessa domanda: quale effetto esatto è stato approvato?
Tesi del protocollo
Il nuovo perimetro è l’azione.
Prima abbiamo difeso i dispositivi da malware e trojan. Poi le caselle di posta dal phishing. Ora il software agisce per conto nostro, e la domanda non è più solo cosa può raggiungere — è cosa può cambiare.
Messaggi, eventi e prompt possono innescare API, chiamate a strumenti, workflow e operazioni di denaro digitale. SecureStamp propone segnali verificabili prima che una comunicazione diventi un’azione.
L’identità controlla chi può accedere a un sistema. SecureStamp delimita l’effetto esatto che il software autonomo può causare.
Quattro livelli
L’autenticazione stabilisce l’identità. Il controllo degli accessi limita la portata. Execution Authorization delimita l’effetto.
Autenticazione
Chi o che cosa sta agendo?
Autorizzazione di accesso
A quali risorse può arrivare?
Execution Authorization
Quale effetto esatto può causare?
Prova di esecuzione
Quale autorizzazione è stata consumata e quale esito ha potuto stabilire il punto di esecuzione?
La quarta domanda è formulata di proposito. Un esito che non si può stabilire resta indeterminato, e nessun livello di questo stack finge il contrario.
Dove ci collochiamo
SecureStamp inizia dove finisce la decisione.
I sistemi di identità, policy e approvazione decidono se un’azione debba procedere. SecureStamp lega quella decisione approvata all’effetto esatto che può essere eseguito.
Decidere
Che cosa dovrebbe essere permesso? A questo rispondono identità, policy engine, approvazioni e persone.
Autorizzare
Quale effetto esatto è consentito? È il livello che SecureStamp aggiunge.
Eseguire
Applicare quell’effetto entro i vincoli del cliente, in un punto che il cliente controlla.
Verificare
Quale autorizzazione è stata consumata e quale esito ha potuto stabilire il punto di esecuzione?
SecureStamp non sostituisce identità, policy engine, workflow di approvazione o API dei provider. Lega le loro decisioni approvate a effetti eseguibili esatti.
SecureStamp fornisce segnali verificabili e autorizzazioni delimitate. Non sostituisce policy interne, permessi, sandboxing, approvazione umana o controlli di sicurezza esistenti.
Dispositivi
Il primo perimetro moderno è stato il dispositivo: malware, trojan, file pericolosi e comportamento locale.
Caselle di posta
Poi il rischio si è spostato sui messaggi: domini sosia, link falsi, allegati, urgenza di pagamento e impersonificazione.
Azioni
Oggi un’istruzione può aprire strumenti, chiamare API, elaborare fatture, spostare dati o preparare pagamenti.
Trust checks
SecureStamp legge che cosa chiede un messaggio — pagare, approvare, consegnare credenziali, invocare uno strumento — e lo sostiene con prove di origine, canale e contesto prima di rispondere, pagare, condividere dati o eseguire workflow.
Agnostico rispetto al canale
Uno standard agnostico rispetto al canale
SecureStamp non è pensato per una casella, un’app o un settore. Il protocollo organizza i segnali attorno a origine, canale, intenzione dichiarata e azione. Può applicarsi a email, messaggistica, QR, siti web, fatture, ticket, API, agenti e operazioni di denaro digitale.
Autorità delegata
Ovunque l’autorità venga delegata al software.
Un agente, un’automazione, un workflow o un servizio delegato che agisce per conto di qualcun altro pongono tutti la stessa domanda. Il permesso di accesso dice cosa possono raggiungere; non definisce l’effetto esatto approvato per questa transazione.
MCP per gli agenti
SecureStamp MCP Server
MCP è il modo in cui le applicazioni di IA raggiungono strumenti, dati e workflow. SecureStamp si mette davanti a quella portata: il software chiede che cosa stia davvero chiedendo un’istruzione, chi sia la controparte e quale effetto esatto possa causare — prima che qualsiasi cosa venga eseguita.
SecureStamp autorizza; non detiene mai le credenziali del tuo provider a valle. Quando un’operazione deve davvero essere eseguita, il grant firmato viaggia verso un Execution Guardian che gestisci tu, e solo quel daemon tocca il provider.
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(...)Flusso concettuale
agent → read_message_request → analyze_message_intent → get_safe_next_step → request_execution_grant → Execution Guardian → ActionReceiptV3Signal Framework
SSF: SecureStamp Signal Framework
SSF organizza prima l'azione richiesta e poi i segnali di contenuto, origine, autenticazione, canale e contesto, per produrre un esito semplice, verificabile e leggibile da persone, sistemi e agenti.
Requested Action
Rispondere, aprire, pagare, trasferire, approvare, condividere dati, invocare strumenti o eseguire workflow.
Content Signals
Urgenza, link, allegati, credenziali, istruzioni di pagamento e cambi di coordinate bancarie.
Origin Signals
Dominio, organizzazione, identità dichiarata, mittente.
Technical Signals
SPF, DKIM, DMARC, DNS TXT, header, firme, chiavi e receipt.
Channel Signals
Email, web, WhatsApp, Telegram, QR, API, assistenza, fatturazione e ticket.
Verdict Layer
Trust, Signal e Action Verdict: un esito leggibile e verificabile che dichiara prima l'azione richiesta e mostra sotto le prove di origine.
Tre segnali in ingresso, poi l’autorizzazione
Proof of Origin risponde da dove è arrivata un’istruzione. Proof of Intent dichiara cosa sta chiedendo. Action Verdict raccomanda se debba procedere. Tutti e tre sono segnali che alimentano una decisione — e una decisione non è ancora un’autorizzazione.
Proof of Intent
Che cosa viene chiesto? Un segnale in ingresso che dichiara per prima l’azione richiesta. Non è una prova di ciò che è stato autorizzato.
Proof of Origin
Da dove è arrivato? Dominio, organizzazione, canale, mittente, francobollo e segnali tecnici. Prova di supporto.
Action Verdict
Deve procedere? Un segnale di decisione. Ciò che accade dopo quella decisione è Execution Authorization.
Livello di esecuzione
Public Beta · accesso produttivo controllatoUn verdetto non è una prova.
Un verdetto può raccomandare se un’azione debba procedere. Da solo non dimostra l’effetto esatto che è stato autorizzato, l’autorità dietro di esso, se l’autorizzazione sia stata riutilizzata, né il risultato osservato all’esecuzione.
Action Proof crea questa catena di prove. Una decisione approvata diventa autorità eseguibile delimitata: un effetto esatto, un’autorità, una scadenza, un uso — verificabile offline, da chiunque.
L’accesso non è autorizzazione ad agire
L’accesso controlla a cosa può arrivare il software. Execution Authorization delimita l’effetto esatto che può causare.
L’autorizzazione delle risorse risponde a cosa può accedere un principal. Execution Authorization risponde a quale effetto, specifico di una transazione, può causare. Un accesso fine-grained lascia comunque la transazione indefinita: quale risorsa, quale importo, quale destinazione, quante volte.
Autorizza l’effetto, non solo l’accesso allo strumento.
Tetto controllato dal cliente
La tua policy è il tetto.
SecureStamp Cloud può rendere un’autorizzazione più stretta. Non può renderla più ampia della policy che la tua organizzazione ha firmato e installato localmente. L’autorizzazione cloud è necessaria, ma da sola non è mai sufficiente.
Permesso effettivo
permesso effettivo =
grant cloud
∩ policy locale firmata
∩ vincoli dell’adattatore
∩ kill switches- La policy locale è un documento che la tua organizzazione firma con la propria chiave e installa accanto al Guardian. Fissa tenant, gateway, operazioni, manifest degli adattatori, autorità e versioni di policy accettate, risorse, parametri, limiti monetari, concorrenza e destinazioni di rete.
- È deny-only per costruzione. Non ha alcun campo capace di concedere qualcosa che il cloud non abbia concesso.
- Avviare in modalità produttiva senza una policy locale firmata e valida non produce un avviso: viene rifiutato all’avvio.
- I kill switches esistono a livello globale e per provider, operazione, tenant e gateway — e di nuovo dentro la policy locale stessa. Fermano grant già emessi.
- Le policy portano una data di revisione obbligatoria e una scadenza facoltativa. Una policy scaduta blocca nuove mutazioni lasciando intatti stato, prova, rilettura e riconciliazione.
- Il recupero delle chiavi è M-di-N e offline. Il supporto SecureStamp non può sostituirsi a quel controllo, ed è esattamente il punto.
- Un control plane cloud compromesso continua a non poter eccedere l’autorità permessa localmente.
Ospitato dal cliente
Noi autorizziamo. Tu esegui.
Il Guardian gira nel tuo ambiente e conserva le credenziali del provider. SecureStamp Cloud non riceve credenziali del provider e non chiama mai il tuo provider.
- Le credenziali del provider sono montate come file di proprietà di root, mai come variabili d’ambiente né configurazione inline.
- Il bridge MCP — il processo più vicino al modello — non richiede né credenziali del provider né SDK cloud.
- L’effetto si risolve dallo stato che il daemon legge da sé, mai da parametri forniti dal modello.
- Lo stato precedente viene riletto subito prima della mutazione; un cambiamento sostanziale invalida il grant invece di sovrascriverlo.
Catena di prova
Cinque anelli, ciascuno firmato da una parte diversa
Prova crittografica dell’autorizzazione. Prova firmata del risultato dell’esecuzione.
Source Envelope
Il plugin firma ciò che la persona ha davvero visto, sul dispositivo, con una chiave che non ne esce mai. Il corpo dei messaggi non viene mai trasmesso.
Action Effect
Il Guardian — non il modello — legge lo stato del provider e normalizza l’effetto esatto: provider, operazione, risorse, parametri e un digest dello stato precedente.
Execution Grant
SecureStamp Cloud firma un grant monouso legato a quel digest dell’effetto, all’autorità che l’ha approvato, alla versione di policy in vigore e a una scadenza. maxUses è 1, sempre.
Execution Claim
Il tuo Guardian reclama il grant contro il proprio ledger. Un grant riprodotto viene rifiutato prima che venga contattato qualsiasi provider.
Action Receipt
Il Guardian firma l’autorizzazione consumata, il contesto di esecuzione e il risultato che ha potuto stabilire, insieme al digest della policy locale che lo ha delimitato.
Autorità
Nessuna richiesta porta con sé il proprio permesso.
L’autorità che un’operazione richiede è fissata dal protocollo. Chi chiama non può sceglierla, il modello non può argomentare a suo favore e non può essere declassata dentro la stessa richiesta che ne ha bisogno. I profili di quorum sono snapshot di policy firmati, non valori di autorità: standard ed elevated sono etichette per le persone, mentre la prova si basa sul threshold, sull’elenco degli approvatori e sull’hash della policy.
noneNon concede mai l’esecuzione. Esiste perché la sua assenza sia esplicita anziché implicita.
policy_delegatedAutonomia dentro una policy che l’organizzazione ha definito in anticipo, e solo per una richiesta firmata sul dispositivo. Mai per una correlata.
human_mfaUna persona identificata approva contro una sessione MFA attiva. Si usa dove l’effetto è delimitato e reversibile nella pratica.
quorumM-di-N approvatori indipendenti, ciascuno con la propria sessione MFA, contro una policy definita in anticipo. Chi richiede non può mai approvare la propria richiesta. Obbligatorio per ogni concessione di privilegi.
Sicurezza in caso di guasto
L’ignoto resta ignoto.
Una risposta ambigua del provider resta indeterminata fino alla riconciliazione. Le operazioni che mutano non vengono ritentate alla cieca.
Un’API di pagamento va in timeout dopo aver ricevuto una mutazione. Ripeterla può duplicare l’effetto. SecureStamp non assume il fallimento e non ritenta: il Guardian riconcilia lo stato del provider e può restituire indeterminate. L’ambiguità è un risultato di prima classe e non viene mai arrotondata a successo.
Verifica indipendente
Controlla la catena senza chiedercelo.
Il verificatore è un pacchetto pubblicato senza accesso alla rete. Ricalcola offline ogni digest e ogni firma di un proof bundle, inclusi l’hash dello snapshot di policy e il digest della policy locale firmata. I receipt si verificano offline senza contattare SecureStamp, e la verifica non dipende da un servizio SecureStamp attivo.
npx --package @securestamp/action-proof-verify action-proof-verify bundle.jsonIl verificatore esce prima degli artefatti che verifica. Una nuova versione di receipt o di bundle non viene mai emessa prima che un verificatore già rilasciato la accetti.
Connettori
Porta il punto di esecuzione che già usi.
Il modello di autorizzazione di SecureStamp è indipendente dal provider. Questi sono connettori di riferimento, non un catalogo chiuso. Come un connettore si integra e quanto SecureStamp risponda per esso sono due domande distinte, e le teniamo separate di proposito.
Come si collega
Adattatore certificato
Un modulo che abbiamo scritto, revisionato e legato a prove di certificazione pubblicate.
Adattatore HTTPS dichiarativo
Origine, metodo e path fissati all’installazione. Nessun URL, metodo o header arbitrario dal modello, nessun redirect, schema stretto, idempotenza deterministica.
SDK / sidecar
Per protocolli che non possono soddisfare il contratto dichiarativo, su un socket Unix.
Come viene dichiarata la sua garanzia
SecureStamp Certified
L’abbiamo scritto, l’abbiamo revisionato e abbiamo pubblicato le prove.
Partner Attested
Un partner identificato ne risponde, e il bundle lo dichiara.
Customer Defined
L’hai costruito tu. La catena si verifica lo stesso, e il bundle dichiara a chiare lettere che SecureStamp non ha certificato il codice del connettore.
Gli adattatori traducono un effetto autorizzato in esecuzione specifica del provider. Non ridefiniscono l’autorità concessa.
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.createquorumSi integra con il control plane che già hai
Funziona con i controlli che hai già.
SecureStamp non sostituisce identità, policy engine, workflow di approvazione o API dei provider. Lega le loro decisioni approvate a effetti eseguibili esatti.
Confini della prova
Cosa stabilisce un receipt e cosa no.
Un Action Receipt dimostra cosa è passato attraverso un Guardian arruolato e il risultato che quel Guardian ha potuto stabilire. Non dimostra che nessuna azione sia avvenuta fuori da SecureStamp, né stabilisce la proprietà legale dell’account del provider.
Il confine della prova è il percorso di esecuzione arruolato.
Le azioni compiute fuori da quel percorso sono fuori dal perimetro del receipt.
Stato della release
Perché questi pacchetti dicono ancora beta.
Il protocollo, il codice e il verificatore sono completi e verificabili oggi. Ma non chiamiamo stabile un connettore finché non abbiamo pubblicato la prova di 100 esecuzioni reali contro un provider dal vivo — inclusi fault injection, rifiuto del replay e prova che la credenziale non avrebbe potuto fare di più — legata all’esatto commit che le ha prodotte. L’esecuzione in produzione richiede un opt-in esplicito e l’idoneità del connettore, e finché un connettore non supera quel gate il suo Guardian si rifiuta di girare fuori dalla modalità sandbox. Un prodotto di fiducia che ti chiede di credergli sulla parola ha già fallito.
Pacchetti
@securestamp/action-proof-verifyIl verificatore offline e i suoi contratti di verifica. Pubblicato prima di tutto ciò che verifica.
@securestamp/action-proofContratti, firma e proof bundle.
@securestamp/execution-guardianIl daemon ospitato dal cliente e i suoi connettori di provider.
@securestamp/execution-guardian-mcpIl bridge MCP. Nessuna credenziale, nessun SDK cloud, per costruzione.
Trust Levels
Trust Level spiega l’origine. Action Verdict aiuta a decidere l’azione.
I livelli L1-L5 valutano la prova di origine verificabile. Non affermano che il contenuto sia vero né che un’azione debba essere eseguita automaticamente.
L1
Registrato
Il dominio o l’organizzazione è registrato in SecureStamp.
L2
Allineato
I segnali tecnici come SPF, DKIM, DMARC o DNS sono allineati.
L3
Firmato
Il messaggio, il canale o l’evento include un token firmato e verificabile.
L4
Notarizzato
Esiste un riferimento di integrità o una ricevuta verificabile per un audit successivo.
L5
Certificato
L’identità organizzativa dietro l’origine è stata esaminata con prove aggiuntive.
Origine verificata non significa azione approvata
Trust Level descrive la solidità della prova di origine. Action Verdict valuta un’azione concreta usando SSF, contesto e policy. Un’origine legittima può comunque richiedere un’azione che va rivista.
Punti di integrazione
Quattro modi per dichiarare e interrogare la fiducia
DNS TXT record
Pubblica un record TXT sotto _securestamp.[domain]. I verificatori risolvono il sottodominio e validano l’origine dichiarata senza ispezionare contenuti privati.
- —v=1 — versione del protocollo
- —id=<stamp_id> — identificatore verificabile
- —url=<verify_url> — URL canonico di verifica
_securestamp.example.com. 3600 IN TXT
"securestamp=v=1;
id=f47ac10b-58cc-4372-a567-0e02b2c3d479;
url=https://securestamp.org/verify/eyJhbG..."Email header
Inserisci X-SecureStamp nei messaggi in uscita così che client, plugin e gateway possano interrogare origine e stato con segnali firmati.
- —Token firmato dal mittente o da un nodo autorizzato
- —Claim minimi: stampId, domain, orgId, score, exp
- —Chiave pubblica o riferimento verificabile per la validazione
X-SecureStamp: v=1;
token=eyJhbGciOiJFUzI1NiJ9.eyJzdGFtcElkIjoiZjQ3YWMxM...;
verify=https://securestamp.org/verify/eyJhbG...REST API
Interroga domini, canali o azioni senza salvare istruzioni sensibili in chiaro. Le risposte possono includere segnali, reasons e Trust Receipts.
- —Trust check per domini e canali
- —Action Verdict per azioni sensibili
- —Receipt verificabili per l’audit
- —Verificatore pubblico e registry quando applicabile
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
Livello Agent Trust attivo per permettere agli agenti di consultare trust checks prima di tool call, API, workflow e operazioni sensibili.
- —SecureStamp MCP Server
- —Tool call checks
- —Action Verdict prima dell’esecuzione
- —Approvazione umana quando la policy lo richiede
securestamp.get_action_verdict({
origin: "billing@example.com",
action: "payment_request",
amount: "1200.00",
destination: "acct_..."
})Official Channel Signal
Verifica dei canali ufficiali sulle superfici conversazionali
Signal permette di verificare se un numero, un bot, un handle, un link, un account o un punto di contatto appartiene al perimetro ufficiale dichiarato da un’entità. È il livello per WhatsApp, Telegram, web, QR, assistenza, fatturazione e altri canali dove una persona o un agente può ricevere istruzioni sensibili.
Perimetro ufficiale
Controlla canali email, WhatsApp, Telegram, web, QR, assistenza e fatturazione contro record verificabili.
Collegato all’SSF
I segnali di canale alimentano Trust, Action Verdict e i receipt senza trasformare un brand in una garanzia assoluta.
Limite onesto
Signal verifica l’appartenenza al perimetro ufficiale. Non dimostra che ogni messaggio sia vero.
Receipt, registry e audit
Prove verificabili senza dipendere dagli screenshot
Ogni interrogazione o dichiarazione rilevante può generare un receipt verificabile. I receipt aiutano a verificare origine, canale, intenzione dichiarata e Action Verdict senza fidarsi ciecamente di un’interfaccia.
Trust Receipts
Receipt firmati che riassumono segnale, contesto consentito, timestamp e riferimento verificabile.
Registry
Token, receipt e riferimenti pubblici si possono verificare senza autenticazione quando il flusso lo consente.
Audit
Le organizzazioni possono combinare i receipt con policy interne, approvazioni e controlli di conformità.
Glossario pubblico
Un linguaggio comune per utenti, supporto e integratori
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.
Apri il glossarioSecureStamp 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.
Rete federata
Rete federata e nodi approvati
SecureStamp Foundation coordina una rete di nodi approvati che scrivono e verificano record condivisi. Gestire un nodo richiede revisione tecnica, SLA e allineamento ai principi di governance.
Inviare la richiesta
Indica organizzazione, regione, capacità operativa, SLA previsto, superficie tecnica e caso d’uso dichiarato.
Revisione tecnica
La fondazione valuta capacità, sicurezza operativa, copertura e potenziali conflitti di interesse.
Credenziali emesse
Se approvato, l’operatore riceve credenziali e requisiti di integrazione per partecipare alla rete.
Operatività verificata
Il nodo deve mantenere disponibilità, health pubblica, tracciabilità operativa e processi di risposta agli incidenti.
Obblighi del nodo
Registry verificabile
Verifica francobolli, receipt e riferimenti pubblici
Ogni francobollo, receipt o riferimento pubblico emesso da SecureStamp può essere verificato senza trasformare questo sito in una landing commerciale. La fondazione mantiene lo standard e i punti di interrogazione.
securestamp.org/verify/[token]FAQ tecniche
Domande frequenti di sviluppatori e integratori
Che cos’è SecureStamp Foundation?
L’ente che pubblica e governa lo standard aperto SecureStamp per verificare origine, intenzione, canale e azione prima di operare.
Quale problema risolve il protocollo?
Aiuta persone, sistemi e agenti a interrogare segnali verificabili prima di rispondere, pagare, condividere dati, invocare API o eseguire workflow.
Che rapporto c’è tra stack di fiducia e superfici?
Lo stack di fiducia è Origine, Intenzione, Execution Authorization e Prova di esecuzione. Le superfici sono email, canali ufficiali, agenti, API e workflow. Sono due assi indipendenti: lo stesso stack si applica a ogni superficie, ed Execution Authorization è un livello, mai una superficie a sé.
Che cos’è Proof of Origin?
Prova verificabile che un dominio, un canale, un mittente o un’organizzazione corrisponde a un’origine registrata.
Che cos’è Execution Authorization?
Il processo che lega una decisione approvata a un’autorità delimitata e specifica di una transazione, che consente al software di causare un effetto definito sotto vincoli espliciti. Il controllo degli accessi limita ciò che il software può raggiungere; Execution Authorization delimita l’effetto esatto che può causare.
Che cos’è Action Verdict?
Una valutazione di un’azione concreta prima dell’esecuzione. Può raccomandare consentire, rivedere, negare o richiedere approvazione umana secondo segnali e policy.
Che cos’è l’SSF?
SecureStamp Signal Framework: un linguaggio comune per i segnali di origine, autenticazione, canale, contenuto, contesto, azione e verdetto.
Che cos’è il SecureStamp MCP Server?
Una direzione in developer preview perché gli agenti interroghino trust check prima di chiamate a strumenti sensibili, tramite Model Context Protocol.
Docs e specifica
Documentazione del protocollo
La specifica copre Proof of Origin, Proof of Intent, SSF, Action Verdict, i punti di integrazione, i receipt, i limiti onesti e la direzione MCP per gli agenti.
Domande sulla specifica o sul design del protocollo? protocol@securestamp.org
Contatti
Mettiti in contatto
Ogni indirizzo arriva direttamente al team giusto. Nessun sistema di ticket — persone vere.