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.
Da dove arriva? Domini, header, firme, identità dichiarata e perimetro del canale. Prova di supporto — necessaria, e mai il titolo.
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.
Approfondisci · Official Channel Signal
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.
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.
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.
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.
Approfondisci · Quattro livelli
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.
Signal 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.
Quale effetto esatto può essere causato? Una decisione approvata diventa un’autorità delimitata e monouso per una singola operazione canonica sotto vincoli espliciti.
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.
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.
Agenti e harness · Beta
Un laboratorio riproducibile cerca di violare i limiti dichiarati di un agente di programmazione — tramite MCP, la shell, uno script o una chiamata diretta all’API — osserva il risultato dall’esterno dell’agente e poi esegue il task reale con lo stesso profilo. Esce solo la modifica esatta che è stata revisionata, attraverso l’Execution Guardian.
Approfondisci · Livello di esecuzione
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.
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.
For the single-grant chain, the protocol, the code and the verifier are complete and auditable today. Bounded delegation — one approval for several exact steps — is a separate profile still in design and simulation, and its known gaps are published. We do not call a connector stable until we have published evidence of 100 real executions against a live provider — including fault injection, replay rejection and proof that the credential could not have done more — bound to the exact commit that produced them. Production execution requires explicit opt-in and connector eligibility, and until a connector clears that gate its Guardian refuses to run outside sandbox mode. A trust product that asks you to take its word for it has already failed.
Pacchetti
@securestamp/action-proof-verifyIl verificatore offline e i suoi contratti di verifica. Pubblicato prima di tutto ciò che verifica.
@securestamp/action-proof-verify@securestamp/execution-guardianIl daemon ospitato dal cliente e i suoi connettori di provider.
@securestamp/execution-guardian@securestamp/execution-guardian-mcpIl bridge MCP. Nessuna credenziale, nessun SDK cloud, per costruzione.
@securestamp/execution-guardian-mcpAutorità 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 → ActionReceiptV3Action Proof — Execution Authorization
Autorizza l’effetto, non solo l’accesso allo strumento: l’esempio canonico, i tre passi, il tetto di autorizzazione locale, i contratti che il verificatore ricalcola e come verificare un receipt offline.
Bounded delegation — Task Contract
The specification for a signed, revisable mandate: tenant, actors, Guardian, revision, steps, budget, validity window, policy and revocation — plus the deliberate exclusions and the known gaps of the local runtime, listed until they close.
Laboratorio di agenti e harness
Profili HP0–HP2 e livelli di laboratorio LR0–LR2, le famiglie di guasti dietro i test, l’applicabilità delle evidenze per rotta, l’esportazione esatta attraverso l’Execution Guardian, lo stop e il budget di campagna — e ciò che il laboratorio non dimostra.
Quale autorizzazione è stata consumata e quale esito ha potuto stabilire il punto di esecuzione? Una ricevuta firmata che chiunque può verificare offline.
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à.
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]Evidence and coverage
What is proven, and what is not. The four evidence levels, the rules that make a coverage claim refutable, the named threats with their open gaps, and everything that sits outside the guarantee.
Livello di esecuzione nel whitepaper
Lo stesso livello alla profondità della specifica: la catena di prova a cinque anelli, i grant monouso, i profili di quorum come snapshot di policy firmati, la piattaforma aperta di adattatori e i confini della prova.
Applicato a
Gmail · Outlook · Apple Mail
Canali ufficiali
WhatsApp · Telegram · perimetri dichiarati
Agenti
Client MCP e assistenti
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?
Da dove iniziare
Quattro percorsi, a seconda di cosa c’è da fare.
Dichiarare e interrogare la fiducia da DNS, header email, API REST o server MCP. Ogni forma ha il suo esempio e la sua documentazione.
DNS TXT record
Pubblica un record TXT sotto _securestamp.[domain]. I verificatori risolvono il sottodominio e validano l’origine dichiarata senza ispezionare contenuti privati.
Email header
Inserisci X-SecureStamp nei messaggi in uscita così che client, plugin e gateway possano interrogare origine e stato con segnali firmati.
REST API
Interroga domini, canali o azioni senza salvare istruzioni sensibili in chiaro. Le risposte possono includere segnali, reasons e Trust Receipts.
MCP Server
Livello Agent Trust attivo per permettere agli agenti di consultare trust checks prima di tool call, API, workflow e operazioni sensibili.
Approfondisci · Punti di integrazione
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_..."
})Delimitare ciò che il software delegato può causare: Action Proof per un effetto esatto, la delega delimitata per più passaggi e il Safe Defaults Kit per esaminare una configurazione prima di concederle autonomia.
Action Proof — Execution Authorization
Autorizza l’effetto, non solo l’accesso allo strumento: l’esempio canonico, i tre passi, il tetto di autorizzazione locale, i contratti che il verificatore ricalcola e come verificare un receipt offline.
Bounded delegation — Task Contract
The specification for a signed, revisable mandate: tenant, actors, Guardian, revision, steps, budget, validity window, policy and revocation — plus the deliberate exclusions and the known gaps of the local runtime, listed until they close.
Laboratorio di agenti e harness
Profili HP0–HP2 e livelli di laboratorio LR0–LR2, le famiglie di guasti dietro i test, l’applicabilità delle evidenze per rotta, l’esportazione esatta attraverso l’Execution Guardian, lo stop e il budget di campagna — e ciò che il laboratorio non dimostra.
Safe Defaults Kit
A local kit that reads the config files you point it at, names what it found — an inline secret, a shell launch, an unpinned package — and proposes a minimal corrected version on a copy. No account, no data leaving the machine.
Evidence and coverage
What is proven, and what is not. The four evidence levels, the rules that make a coverage claim refutable, the named threats with their open gaps, and everything that sits outside the guarantee.
Verificare francobolli, receipt e riferimenti pubblici — i receipt si verificano anche offline — con un vocabolario comune a utenti, supporto e integratori.
Approfondisci · Glossario pubblico
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.
Evidence and coverage
What is proven, and what is not. The four evidence levels, the rules that make a coverage claim refutable, the named threats with their open gaps, and everything that sits outside the guarantee.
Modello notarile e L5
Come SecureStamp arriva a L5 Certified: un record notarile firmato in ES256 dell’envelope del messaggio più una verifica dell’identità aziendale (KYB). I cinque livelli e il limite onesto: certifica origine e integrità, non la veridicità del contenuto.
Aggiungere un nodo alla rete federata: candidatura, revisione tecnica, credenziali e operatività sottoposta ad audit.
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
Gestisci un nodo
Guida per entrare nella rete federata SecureStamp: requisiti, setup, configurazione e obblighi dell’operatore del nodo.
Whitepaper
Specifica tecnica e razionale di design del protocollo SecureStamp: modello di fiducia a cinque livelli, livello notarile, Action Verdict, la catena di esecuzione Action Proof, segnali, scoring e architettura.
Docs e specifica
Documentazione del protocollo
Documentazione per sviluppatori e istituzioni che delegano lavoro a software autonomo. Copre come proteggere server MCP, agenti e harness con Break the Mandate — Doctor sui tuoi file nativi, un laboratorio riproducibile, Exact Export e controllo dell'esecuzione; Action Proof per autorizzare l'effetto esatto, con ricevute verificabili offline; delega limitata con il Task Contract; Proof of Origin, Proof of Intent, SSF e Action Verdict per i messaggi, con i plugin Gmail e Outlook già pubblicati; il livello di prova di ciascun profilo; e i limiti onesti di tutto questo.
Domande sulla specifica o sul design del protocollo? protocol@securestamp.org
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.
Contatti
Mettiti in contatto
Ogni indirizzo arriva direttamente al team giusto. Nessun sistema di ticket — persone vere.