Lascia lavorare l'agente. Mantieni il controllo dell'effetto finale.

A chi è rivolta

Tre superfici, un solo principio

Gli agenti possono proporre. L'autorità resta fuori dall'agente. La copertura è limitata alle rotte dichiarate e testate: SecureStamp non controlla le operazioni che aggirano quel confine, e le nomina invece di nasconderle.

Break the Mandate — la dimostrazione passo passo

La domanda iniziale è semplice: il tuo agente può fare qualcosa al di fuori dell'attività che hai approvato? Lo scenario di riferimento risponde in cinque passaggi, su fixture sintetiche, senza account e senza chiave API di un modello.

1. 01

   Un'attività utile

   L'agente prepara una modifica reale all'interno di una fixture contenuta.

2. 02

   La lacuna, nella baseline

   Lo stesso tentativo fuori ambito produce il suo effetto in una baseline volutamente permissiva, osservata da un altro processo. È un controllo sperimentale noto, non una vulnerabilità scoperta sulla tua macchina.

3. 03

   La lacuna, contenuta

   Con il controllo attivo quella rotta è contenuta e l'attività utile viene comunque completata. Un rifiuto che rende l'attività inutile non conta come valore.

4. 04

   Le prove scadono quando l'ambiente cambia

   Una dipendenza materiale del profilo cambia: le prove precedenti smettono di abilitare quella rotta finché non vengono rivalidate.

5. 05

   Esce solo il candidato esatto

   Il candidato congelato viene rivisto. Alterarne i byte o la destinazione invalida l'esportazione; ripristinare ciò che era stato approvato consente l'effetto.

Avvio rapido

Doctor non richiede né Docker né un modello e non esegue nulla di ciò che legge. Lo scenario di riferimento è sintetico: non esegue mai codice del progetto e il suo report è etichettato come prova simulata.

# Node 22.22.3 o successivo
npm install --save-dev @securestamp/mcp-guard @securestamp/execution-governance

# 1. Doctor: diagnosi statica dei file che scegli
npx securestamp-mcp-doctor scan .mcp.json --propose
npx securestamp-mcp-doctor scan-native <settings.json|config.toml> --format=<shape>
npx securestamp-mcp-doctor scan-workflow .github/workflows/agent.yml

# 2. Scenario portabile: valida ed esegui il riferimento, con un hold
npx securestamp-execution-governance validate scenario.json
npx securestamp-execution-governance run scenario.json --hold-before=step-1

Ogni comando stampa il proprio utilizzo e i formati supportati quando riceve argomenti non validi. Per un HarnessProfileV1 completo, usa securestamp-mcp-doctor scan-harness. Con --hold-before, l'esecuzione mostra un effetto trattenuto che non viene mai ammesso. Nessuna telemetria per impostazione predefinita.

Doctor: prima i tuoi file nativi

Doctor produce fatti dichiarati, ciascuno con il proprio file e campo di origine, e una diagnosi parziale che indica quali livelli ha letto e quali restano sconosciuti. La compatibilità è descritta come forma + trasporto + client testato; un formato che non riconosce viene segnalato come non supportato, mai saltato in silenzio.

• .mcp.json · JSON con mcpServers (stdio)

  Comandi dichiarati, riferimenti a credenziali, segreti scritti nel file, avvii tramite shell e pacchetti mutabili o @latest. Una versione bloccata non stabilisce l'integrità: verificare l'artefatto effettivo rispetto a quello approvato è compito dell'esecutore.

• settings.json · config.toml ([mcp_servers])

  Permessi, strumenti e livelli di configurazione riconosciuti, con conflitti e dati mancanti. Un singolo file non rivela policy gestite, override della CLI o configurazione ereditata: l'output lo dice.

• .github/workflows/*.yml

  Agent Workflow Doctor: input non attendibile da issue, PR o commenti che raggiunge l'agente, permessi dichiarati, riferimenti a secret, strumenti ampi e checkout di contenuti esterni. Non scarica action, non risolve secret né esegue YAML.

• HarnessProfileV1

  Il profilo completo per utenti avanzati. Doctor non lo inventa mai a partire da un solo file: mount, osservatore, credenziali effettive e backend sono scelti e validati dall'operatore.

• Legge solo i file a cui viene puntato; non scansiona la home directory.
• Non esegue comandi, hook o espressioni contenuti nel file.
• Non risolve segreti e non valida token.
• Propone una patch rivedibile su una copia; non sovrascrive mai l'originale.
• Mostra un risultato pulito con lo stesso peso di un rilievo.
• Una diagnosi statica non stabilisce né isolamento né protezione.

Exact Export: l'agente prepara, tu autorizzi la modifica esatta

L'agente prepara la modifica in una copia contenuta del tuo progetto. La credenziale di esportazione resta fuori dal suo ambiente e solo il candidato rivisto esce, tramite l'Execution Guardian.

1. 01

   Preparare

   In quarantena, su uno snapshot del progetto scelto; il tuo .git non viene mai riutilizzato come base attendibile.

2. 02

   Congelare

   Il candidato viene fissato prima della revisione: base, byte e digest, ref, destinazione e stato precedente.

3. 03

   Autorizzare

   L'approvazione è legata a quel candidato. Una modifica successiva la invalida; un --yes non sostituisce MFA o quorum.

4. 04

   Eseguire

   Tenuto in custodia dal Guardian, con un controllo dello stato della destinazione: drift e race non vengono mai sovrascritti.

5. 05

   Verificare

   Verifica indipendente della postcondizione e una ricevuta da allegare alla PR o all'issue.

La destinazione iniziale è un repository Git locale. Con un profilo e una destinazione autorizzati, l'adapter GitHub crea un nuovo ref: non aggiorna alcun branch, non fa force-push, merge o deploy, e aprire una PR è un effetto separato con la propria autorizzazione. La custodia delle credenziali è dichiarata solo per il profilo che la dimostra con identità effettiva, mount, socket e rete più canary dal contesto dell'agente.

Una configurazione portabile, tre interfacce

La configurazione è un file JSON versionato nel tuo repository. La libreria genera i contratti completi e i loro digest; nessuno scrive le firme a mano. CLI e dashboard importano ed esportano la stessa rappresentazione e superano la stessa validazione: non esiste una policy web diversa dalla policy in Git. Ogni modifica crea una nuova revisione e le esecuzioni attive mantengono il proprio snapshot.

• npm · @securestamp/execution-governance

  Contratti di scenario portabili, un piano di controllo con hold, resume e stop, e report redatti: validare e serializzare scenari, avviare esecuzioni, emettere ordini idempotenti, e costruire, verificare e confrontare report. Non concede autorità, non contiene l'host e non sostituisce il Guardian del cliente.

• CLI · securestamp-mcp-doctor · securestamp-execution-governance

  scan, scan-native, scan-workflow e scan-harness per la diagnosi; validate e run per gli scenari. Nessun account. Ogni esecuzione produce il proprio report senza sovrascriverne un altro.

• Dashboard · securestamp.online/dashboard/agents

  Scenari, preparazione, esecuzioni, dettaglio in tempo reale e analisi post-esecuzione, su runner registrati gestiti dal cliente. Il browser non esegue il test e non riceve le credenziali del provider; collegare un runner è opzionale.

Hold, resume, stop

I controlli agiscono sulle rotte mediate dal Guardian. L'agente può continuare a ragionare mentre i suoi effetti sono trattenuti; l'interfaccia lo mostra come «effetti trattenuti / processo in esecuzione», mai come un agente congelato.

Una risposta HTTP riuscita conferma solo che l'ordine è stato ricevuto. La dashboard mostra separatamente ciò che è stato richiesto, ciò che il supervisore ha applicato e ciò che è stato osservato. Se il canale remoto cade mentre l'osservatore è integro, le ammissioni restano trattenute in locale; se l'osservatore si guasta, il profilo interrompe l'egress e termina il container. Lo stop locale non dipende mai dalla dashboard.

Report: stati che non si riducono a un semaforo

Il report di esecuzione contiene solo un checksum informativo, dichiara il livello di prova e permette di confrontare le esecuzioni; un checksum non autentica l'emittente. Quando è allegato un bundle Action Proof completo, il verificatore indipendente lo verifica offline con ancore fornite fuori dal report e collega candidato, destinazione, autorità e risultato osservato del receipt. FAIL, un SKIP, evidenza mancante e rotta non valutata restano visibili; un guasto di strumentazione lascia l'esecuzione INCOMPLETE, mai PASS.

Controllo informativo sulle pull request

Confronta base e head dei file nativi con gli stessi importer e le stesse regole, mostra le modifiche dichiarate, gli elementi sconosciuti e i candidati alla rivalidazione, e valida una ricevuta allegata rispetto ai suoi anchor. Viene eseguito da una revisione attendibile bloccata, con permessi di lettura, senza secret e senza eseguire codice della PR. Informa la revisione: non è il controllo che autorizza un'esportazione, né un sostituto del Guardian o di un ruleset.

Cosa non fa

• Non rende sicuro il modello né dimostra un allineamento generale: testa i limiti di esecuzione su un profilo dichiarato.
• Non controlla le rotte che aggirano il Guardian; una rotta senza sonda resta not evaluated, mai protetta per ereditarietà.
• Non annulla un effetto già avvenuto: hold e stop non sono un rollback.
• Una ricevuta mostra integrità e ambito rispetto ai suoi anchor; non mostra che il codice approvato sia innocuo né che qualcuno di indipendente lo abbia sottoposto ad audit.
• Non è un kill switch a livello aziendale: la v1 controlla l'esecuzione scelta e i suoi runner dichiarati.
• La compatibilità è pubblicata per profilo, versione e ambiente. Un PASS su un harness non si trasferisce a un altro sistema operativo, rotta o client.

Continua a leggere