Autorizza l’effetto, non solo l’accesso allo strumento.
Il controllo degli accessi limita a cosa può arrivare il software. Execution Authorization delimita l’effetto esatto che può causare. Action Proof è il protocollo che produce la catena verificabile: un grant firmato e monouso per una singola operazione canonica, applicato in un punto che controlli tu e chiuso con prove che chiunque può controllare offline.
Prova crittografica dell’autorizzazione. Prova firmata del risultato dell’esecuzione. Un Execution Grant dimostra cosa è stato autorizzato; un Action Receipt conserva prove firmate del risultato che il Guardian arruolato ha potuto stabilire.
Il cloud autorizza, il tuo Guardian esegue
Chiavi per tenant, credenziali a privilegio minimo
Ricevute firmate, verificabili offline
POST https://mcp.securestamp.online/mcp
Authorization: Bearer ss_live_...
{ "jsonrpc":"2.0", "id":1, "method":"tools/list" }L’accesso non è autorizzazione ad agire
Avere accesso al processore di pagamenti non è la stessa cosa che essere autorizzati a fare un rimborso specifico.
Accesso
L’agente può chiamare le API di rimborso del processore di pagamenti
Execution Authorization
refund.create charge ch_89172 amount USD 1.427,00 destination original_payment_method maxUses 1 expires 14:02 UTC
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.
Tre passi
Definire
Quale effetto esatto viene richiesto? Il Guardian — non il modello — legge lo stato del provider e lo normalizza in un’operazione canonica con parametri espliciti.
Autorizzare
Lega quell’effetto a un Execution Grant firmato e monouso dentro la tua policy, all’autorità che il protocollo richiede per quell’operazione.
Verificare
Esegui in un punto che controlli tu e conserva un Action Receipt firmato che si ricalcola offline.
read_message_request
Restituisce che cosa sta chiedendo un messaggio, solo da segnali. Il corpo non lascia mai il dispositivo.
analyze_message_intent
Mappa segnali astratti su intenzioni di azione sensibile. Solo segnali, mai testo grezzo.
verify_counterparty
Verifica se un mittente o una controparte corrisponde al registro del tenant.
get_safe_next_step
Calcola il prossimo passo più sicuro a partire da fatti dichiarati nel registro.
authorize_action
Restituisce un Action Verdict, un Safe Next Step e una ricevuta prima di un'azione sensibile.
create_action_challenge
Crea una verifica manuale a doppio controllo verso una controparte nota.
issue_action_receipt
Emette un Action Receipt firmato su fatti già calcolati.
get_source_envelope
Recupera l'envelope firmato sul dispositivo che una persona ha realmente visto e approvato.
request_execution_grant
Richiede un grant monouso per eseguire un effetto esatto. Restituisce un HOLD finché non approva l'autorità umana o il quorum richiesto.
get_execution_status
Riporta a che punto è un'esecuzione, inclusi gli esiti ancora genuinamente indeterminati.
Livello di esecuzione
Il grant non è il permesso di improvvisare
Un Execution Grant è legato a un digest dell’effetto e alla versione di policy in vigore, scade e si può usare esattamente una volta. Il tuo Guardian rilegge lo stato del provider subito prima della mutazione, reclama il grant contro il proprio ledger e firma l’esito — inclusi gli esiti ambigui. Un grant riprodotto non raggiunge mai un provider.
- I grant sono monouso e legati a un solo digest dell’effetto esatto. maxUses è 1, sempre.
- L’autorità richiesta è fissata dal protocollo; chi chiama non può declassarla.
- Ogni concessione di privilegi richiede quorum M-di-N, e chi richiede non può mai approvare la propria richiesta.
- I profili di quorum sono snapshot di policy firmati, non valori di autorità: la prova si basa sul threshold, sull’elenco degli approvatori e sull’hash della policy.
- Gli esiti sono succeeded, failed_no_effect o indeterminate — l’ambiguità non viene mai arrotondata per eccesso.
- I proof bundle si verificano offline, senza richiamare SecureStamp.
Parabola 3
L’agente si ferma prima di modificare un conto
Un workflow riceve la richiesta di un fornitore di cambiare le coordinate bancarie. Invece di aggiornare il conto, chiama authorize_action tramite l'MCP Guard remoto con un hash e segnali astratti. SecureStamp risponde needs_confirmation e un Safe Next Step: interpellare la controparte. Nulla viene eseguito finché non risponde una persona.
L’agente rileva un’azione sensibile
Individua un cambio di coordinate bancarie e invia solo segnali strutturati più un sourceMessageHash.
SecureStamp verifica i fatti del tenant
La chiave API restringe la ricerca a un solo owner graph, alle policy dichiarate e alle istruzioni registrate.
L’agente riceve un verdetto
La risposta è un record di decisione con Safe Next Step e receiptId, non un permesso di eseguire.
Persone o controparti confermano
Se serve, create_action_challenge apre un percorso di conferma manuale prima che l’operazione prosegua.
Tetto di autorizzazione locale
L’autorizzazione cloud è necessaria, ma da sola non è mai sufficiente.
Un grant diventa esecuzione solo se rientra anche nella policy che la tua organizzazione ha firmato e installato accanto al Guardian. Quella policy è deny-only: fissa tenant, gateway, operazioni, manifest degli adattatori, autorità e versioni di policy accettate, risorse, parametri, limiti monetari, concorrenza e destinazioni di rete. La modalità produttiva si rifiuta di partire senza di essa.
permesso effettivo =
grant cloud
∩ policy locale firmata
∩ vincoli dell’adattatore
∩ kill switchesSecureStamp Cloud può rendere un’autorizzazione più stretta. Non può renderla più ampia di quanto la tua organizzazione abbia permesso localmente.
Contratti
Cosa ricalcola il verificatore
ExecutionGrantV1L’artefatto di autorizzazione. Porta il digest dell’effetto, l’autorità, la versione di policy (apol_v1:) e la scadenza. maxUses è 1.
ActionReceiptV2 / V3L’artefatto di prova. V3 aggiunge la versione di policy e il digest della policy locale firmata (gpol_v1:) che ha delimitato l’esecuzione. V2 resta compatibile byte per byte per lo storico.
ActionProofBundleV1 / V2Tutto ciò che serve a un terzo per ricalcolare la catena. V2 aggiunge la policy locale firmata e il descrittore di assurance del connettore.
AdapterManifestV1Un descrittore autonomo e immutabile di una singola operazione di connettore. Il verificatore controlla il manifest dentro il bundle invece di rigenerarlo, così le nuove operazioni non invalidano mai le prove vecchie.
Verificare un receipt offline
Il verificatore è un pacchetto pubblicato a parte, senza accesso alla rete, e viene rilasciato prima degli artefatti che verifica. 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.json
Confini della prova
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.