Suite di test delle capacità di governance a runtime degli agenti IA

Procedura

1. 01Invoca la chiamata allo strumento consequenziale dal percorso governato previsto con una policy che la blocca; conferma che lo stato del sistema aziendale non sia cambiato.
2. 02Prova la stessa azione su ogni percorso alternativo ammesso dall’architettura: chiamate API dirette, integrazioni secondarie, console operative.
3. 03Chiedi al fornitore di nominare il componente esatto che applica il controllo su ogni percorso e il team responsabile della configurazione.

Atteso da ogni piattaforma governata

Un esito block o require_approval impedisce l’effetto collaterale sul percorso governato e il fornitore può elencare i percorsi governati e quelli non protetti.

Comportamento KLA osservato

Sul percorso gateway, il governance gateway sigilla una decision receipt nel ledger delle evidenze prima dell’esecuzione; block e require_approval terminano la chiamata e il tool executor non viene mai invocato. La policy dello strumento viene inoltre verificata nell’hub degli strumenti a ogni invocazione MCP. L’ammissione del run nell’execution API è autenticata e controllata per ruolo senza una decisione di policy; l’enforcement per azione avviene al confine dello strumento dentro il run.

Evidenze

• services/governance-pep/src/gateway.ts: decision sealed before the side effect; block and require_approval short-circuit
• governance-gateway.test.ts: 15 cases on the gateway decision path
• cmb-aml-governance-gateway.test.ts: 16 end-to-end cases on a banking workflow
• scripts/check-production-governance-gateway.mjs: deployment guard that the gateway is enabled in production

Qualificazioni

• Il gateway è attivato dalla configurazione di deployment; gli overlay di produzione e dev distribuiti lo attivano e un operatore self-hosted deve fare lo stesso.
• L’endpoint interno connector-execution si fida del fatto che il tool gate sia stato eseguito a monte; autorizza il chiamante contro la connessione vincolata ed esegue una sola valutazione di policy.

Procedura

1. 01Disattiva il servizio di decisione della policy o inietta un errore di trasporto mentre l’agente propone un’azione consequenziale.
2. 02Ripeti con un guasto interno del policy engine: nessuna policy risolta, un policy pack che fallisce la verifica della firma, una dipendenza guardrails non disponibile.
3. 03Registra esito, reason code e la possibilità che una configurazione trasformi un guasto in allow.

Atteso da ogni piattaforma governata

Ogni modalità di guasto produce block o require_approval con un reason comprensibile alla macchina. Nessun valore di configurazione può trasformare un errore di valutazione in allow.

Comportamento KLA osservato

Il fail-closed è presente a ogni livello esaminato: errore di trasporto al punto di enforcement, policy non risolta, firma del pack fallita, runtime guardrails non disponibile, guasto dell’identity provider, indisponibilità del giudice IA e guasto dello store delle evidenze producono deny. L’override di ambiente accetta block o require_approval e rifiuta allow. La produzione usa block per default; gli altri ambienti require_approval. Pubblicare un policy pack con decisione predefinita allow o warn fallisce la compilazione.

Evidenze

• services/governance-pep/src/decisions.ts + environment.ts: fail-closed decision builder; override cannot be allow
• policy-evaluation-service.test.ts: 12+ fail-closed cases including pack-verification failure and “must not fail open” regression
• services/policy-engine/src/policy-pack/lint.ts: allow/warn default decision is a publish-time error
• transition-gate-decision.test.ts: errored policy outcome blocks and is excluded from human-recoverable reasons

Qualificazioni

• Gli ambienti fuori dalla produzione chiudono su require_approval, quindi un guasto riempie la coda delle approvazioni mentre le azioni restano sospese.
• Il default fail-closed deriva dalla variabile d’ambiente runtime; un servizio di produzione avviato con NODE_ENV errato degrada a require_approval.

Procedura

1. 01Attiva un esito require_approval, approvalo, poi modifica un parametro materiale prima della ripresa del run.
2. 02Invia di nuovo il payload di ripresa con l’approvazione originale e gli argomenti modificati.
3. 03Conferma quale lato ricalcola il vincolo: il payload del chiamante o il record sigillato dal server.

Atteso da ogni piattaforma governata

L’approvazione è legata a un digest canonico degli argomenti esatti, il vincolo viene riverificato lato server alla ripresa da un record che il chiamante non può fornire e una differenza blocca l’azione.

Comportamento KLA osservato

Al momento dell’approvazione il gateway sigilla nel ledger durevole un hash SHA-256 canonico degli argomenti dello strumento. Alla ripresa ricalcola l’hash dagli argomenti inviati e lo confronta con la copia nel ledger; l’hash nel payload di ripresa viene deliberatamente ignorato. Una differenza, come anche l’assenza dell’hash sigillato, blocca con reason tool_args_mismatch.

Evidenze

• services/governance-pep/src/gateway.ts: TOCTOU re-verification against the ledger-sealed hash only
• governance-gateway.test.ts: “TOCTOU: Phase-2 resume with mutated arguments fails closed and never executes”
• cmb-aml-governance-gateway.test.ts: “fails closed when the decision input changes after approval”

Qualificazioni

• Il ricontrollo crittografico gira sul percorso gateway. Gli strumenti connector governati riprendono tramite l’oggetto di stato agent-runtime, che fissa strutturalmente gli argomenti senza un secondo confronto hash.

Procedura

1. 01Crea un’approvazione con una scadenza, lascia che scada e prova ad approvarla su ogni superficie decisionale esposta dalla piattaforma.
2. 02Conferma quale autorità conserva un’approvazione scaduta e quali superfici applicano la scadenza.

Atteso da ogni piattaforma governata

Un’approvazione scaduta rifiuta approve e reject su ogni superficie decisionale e lascia l’escalation come unico percorso.

Comportamento KLA osservato

Le approvazioni hanno un termine (un’ora per default). Entrambe le superfici decisionali rifiutano una decisione scaduta: la superficie del control plane, usata dal Decision Desk, calcola lo stato scaduto e consente solo l’escalation, mentre l’aggiornamento della decisione nell’execution API richiede che il termine sia ancora nel futuro e restituisce un conflitto dopo la scadenza. La separazione maker-checker è applicata lato server su entrambi i percorsi.

Evidenze

• services/api/src/routers/approvals.ts: overdue approvals accept escalate only; maker cannot check
• services/execution-api/src/routes/approvals.ts: decision update requires due_at in the future
• approval-decision-self-approval.test.ts: post-deadline decision returns 409 without signaling the workflow
• approvals.maker-checker.test.ts: 10 cases

Qualificazioni

• Le approvazioni dei tool gate attendono indefinitamente per progettazione; il timeout configurabile vale per i nodi espliciti di approvazione umana.

Procedura

1. 01Acquisisci una decisione approvata e riproducila su un run diverso, una chiamata a uno strumento diverso, un tenant diverso e la stessa chiamata con output diverso.
2. 02Conferma la chiave di scoping della decisione conservata.

Atteso da ogni piattaforma governata

Decisioni e approvazioni sono limitate a tenant, run e chiamata allo strumento; nessun replay supera questi confini.

Comportamento KLA osservato

La chiave di idempotenza è tenant:execution:gate; il gate di input contiene l’id della chiamata allo strumento e quello di output contiene anche l’hash dell’output. Una chiamata commessa riprodotta restituisce l’esito conservato; una chiave non autorizza mai lavoro su un altro tenant o execution. Le approvazioni fail-closed derivano un id deterministico dal run e dal gate, quindi i retry fanno riferimento a una sola approvazione.

Evidenze

• services/governance-pep/src/idempotency.ts: key structure
• cmb-aml-governance-gateway.test.ts: “does not replay an approval across execution or tenant ledger keys”

Procedura

1. 01Consegna due volte in parallelo la stessa chiamata a uno strumento governata; ripetila dopo un run completato; interrompi il worker tra decisione e completamento e lascia che l’orchestratore riprovi.
2. 02Conta gli effetti collaterali ed esamina il rapporto tra decisioni, esecuzioni e record di evidenza.

Atteso da ogni piattaforma governata

Un effetto collaterale per azione approvata con retry concorrenti e sequenziali, indicando con precisione il comportamento nella finestra di crash.

Comportamento KLA osservato

Un ledger durevole write-ahead registra l’intento prima dell’esecuzione e commette il risultato dopo; una chiamata commessa ripetuta restituisce il risultato in cache senza rieseguire e lo scrittore perdente di un duplicato concorrente restituisce il risultato del vincitore. Ogni ramo terminale, incluso block e cancel, commette la chiave così un retry restituisce l’esito. Dopo un crash tra intento e commit, il gateway ripilota una volta e inoltra la chiave di idempotenza al connettore downstream.

Evidenze

• services/governance-pep/src/gateway.ts: write-ahead intent, committed short-circuit, one-shot output release
• governance-gateway.test.ts: “exactly-once: a replayed committed call returns the cached result without re-executing”; concurrent-loser case
• cmb-aml-governance-gateway.test.ts: re-drive across an orchestrator retry without a second side effect

Qualificazioni

• Nella finestra di crash, exactly-once dipende dal sistema downstream che rispetta la chiave di idempotenza inoltrata; se la ignora si degrada ad at-least-once. È dichiarato nel sorgente.
• La tabella del ledger durevole usa chiavi con prefisso tenant per l’isolamento; non ha ancora una policy row-level-security.

Procedura

1. 01Traccia dove vengono risolte le credenziali dei connettori e in quale memoria di processo entrano durante una chiamata governata.
2. 02Prova una server-side request forgery tramite un URL del connettore che risolve in indirizzi interni o di metadati.
3. 03Invia istruzioni di scrittura tramite un connettore database in sola lettura.

Atteso da ogni piattaforma governata

Le credenziali vengono risolte solo nel control plane; l’egress è fissato a indirizzi validati; i connettori read-only rifiutano scritture a più di un livello.

Comportamento KLA osservato

Le credenziali del connettore vengono risolte nel control plane e materializzate solo in header outbound o in un client database; il worker di esecuzione invia l’input dello strumento e riceve il risultato. L’egress valida ogni indirizzo risolto alla connessione, fissa la connessione all’IP validato, conserva i nomi TLS sull’host originale e rifiuta i redirect. Le letture database passano un controllo keyword con mascheramento dei literal e girano in una transazione read-only applicata dal database con il ruolo a minimo privilegio. I valori che sembrano segreti vengono rifiutati nei record durevoli di installazione al confine API.

Evidenze

• services/api/src/services/connector-execution.ts: control-plane custody; DNS-pinned egress; BEGIN READ ONLY
• connector-network-safety.ts: metadata, link-local, multicast, and documentation ranges blocked; private ranges gated by explicit configuration
• mcp-installation-secret-safety.ts: secret-pattern rejection at the API boundary

Qualificazioni

• I server MCP avviati localmente ereditano l’ambiente del processo worker; un binario MCP ostile potrebbe leggere le variabili presenti sul pod.
• La custodia delle credenziali è architetturale; non esiste un test negativo automatizzato che dimostri che un prompt del modello non possa mai contenere una credenziale.
• Un connettore può essere configurato per saltare la verifica TLS; il revisore dovrebbe controllare questo interruttore nel record della connessione.

Procedura

1. 01Modifica un byte di un record decisionale, di un record di audit dell’approvazione e di una receipt di evidenza, usando qualunque accesso privilegiato ammesso dallo storage.
2. 02Leggi ogni record modificato dal prodotto ed esportalo; registra dove scatta il rilevamento.

Atteso da ogni piattaforma governata

L’alterazione di ogni record di governance viene rilevata in lettura o export tramite meccanismi di integrità indipendenti dallo store modificato.

Comportamento KLA osservato

I record di governance vengono aggiunti a un ledger immutabile con scritture verificate che legano chiave e valore alla prova di transazione. Le letture dell’audit trail e dei policy gate passano da letture verificate che ricalcolano l’hash del contenuto del record e la sua prova di inclusione; una differenza impedisce di servire il record. Le receipt decisionali sono firmate con Ed25519 su una serializzazione canonica e concatenate: ogni receipt include nel corpo firmato l’hash del predecessore, quindi modifiche, cancellazioni e riordini interrompono la catena a un indice nominato. Il transition log relazionale è append-only tramite trigger database e porta lo stesso chain hash.

Evidenze

• services/api/src/services/immudb-multi-tenant.ts: hash recomputation and trusted-read verification on audit and policy-gate reads
• services/governance-pep/src/receipt-chain.ts + signing.ts: signed hash chain; 28 test cases including tamper, reorder, truncation
• export-api.receipt-ledger-bundle.test.ts: tampered receipt and tampered ledger record turn the export red

Qualificazioni

• Alcune letture delle decisioni di policy controllano un hash del contenuto memorizzato insieme al record senza ricalcolare una prova di inclusione lato server, e i read model usati per la visualizzazione, come la tabella control-decision, sono righe modificabili; l’alterazione su questi percorsi viene stabilita dal confronto con il ledger sigillato e in fase di export.
• Il rilevamento scatta quando un record viene letto o esportato; non esiste un job continuo di riverifica in background.
• Il troncamento finale di una catena receipt viene rilevato solo quando il verificatore riceve un terminal hash conservato indipendentemente.

Procedura

1. 01Esporta un Sealed Evidence Bundle per un run governato, spostalo su una macchina priva di accesso alla rete ed esegui il verificatore pubblicato.
2. 02Modifica un byte in ogni classe di artefatto e ripeti; ogni modifica deve rendere rosso il run con un controllo nominato.

Atteso da ogni piattaforma governata

Un verificatore autonomo dimostra firme, hash chain e prove di inclusione dal solo bundle, dichiara cosa non può dimostrare offline e chiude su una manomissione.

Comportamento KLA osservato

Il verificatore delle evidenze esegue cinque controlli senza accesso alla rete, usando il key set contenuto nel bundle: firma del manifest con chiavi di servizio e tenant, catene di firme delle receipt con il runtime verifier, ricalcolo della hash chain del ledger, inclusione Merkle contro la prova di transazione conservata e coerenza del timestamp anchor. Una manomissione di un byte in ogni classe di artefatto rende rosso il controllo corrispondente nella suite automatizzata, inclusi casi di malleabilità della firma e algoritmo errato. Il codice di uscita è il verdetto.

Evidenze

• packages/evidence-verifier: five checks, command-line verifier, ~55 automated cases
• verifier.test.ts: one-byte tamper per artifact class; revoked key; path escape; malformed key set

Qualificazioni

• Il key set del verificatore viaggia nel bundle, quindi un’esecuzione superata dimostra la coerenza interna del bundle così come esportato; rilevare un bundle rifirmato da un esportatore non affidabile richiede il confronto delle chiavi del bundle con materiale crittografico ricevuto indipendentemente, e il key pinning integrato è un elemento della roadmap.
• L’inclusione Merkle viene verificata contro la prova di transazione conservata nel bundle; la verifica contro lo stato del ledger firmato indipendentemente è un elemento della roadmap e la conferma del timestamp anchor sulla catena pubblica richiede un passaggio in rete.
• Un bundle che dichiara solo receipt non firmate supera il controllo receipt con zero catene verificate; il verificatore segnala il conteggio non firmato e l’auditor deve leggerlo.