Proteggere un agente IA richiede sei controlli: identità delimitata, permessi degli strumenti al minimo privilegio, tokenizzazione delle PII, scansione delle iniezioni di prompt, un kill switch e un registro di audit. Ciascuno chiude una modalità di guasto distinta — l'identità per sapere quale agente ha fatto cosa, i permessi perché un agente compromesso non possa chiamare qualsiasi cosa voglia, la tokenizzazione perché una fuga di dati non sembri l'agente che sta semplicemente facendo il suo lavoro, la scansione delle iniezioni perché un input manipolato non possa dirottare una chiamata a uno strumento, un kill switch per poter fermare un agente senza aspettare la sua collaborazione, e un registro di audit perché ci siano prove quando qualcosa va storto. Ecco cosa fa ciascuno, dove risiede e su quale piano è disponibile.
Proteggere un agente IA significa chiudere sei distinte modalità di guasto a runtime — identità, accesso agli strumenti, esposizione dei dati, istruzioni manipolate, override dell'operatore ed evidenza — con controlli che operano al di fuori del ragionamento dell'agente stesso. Un'istruzione nel system prompt che dice all'agente cosa non fare non è un controllo; è una richiesta da cui il modello può essere convinto a discostarsi. Ogni voce qui sotto viene applicata a un livello su cui l'agente non ha alcun voto in capitolo.
Nell'ordine in cui la maggior parte dei team li implementa — prima l'identità e il livello decisionale, poiché tutto il resto dipende dal sapere quale agente si sta osservando.
POST /v1/credentials/issue, verificabile contro /.well-known/jwks.json) è la base gratuita — illimitata su ogni piano. L'identità più completa — verifica della proprietà, manifesti firmati che dichiarano cosa un agente può fare, e deleghe delimitate da un account umano — è VeriSwarm Passport, dal piano Pro in su. Piano: credenziali di base gratuite; Passport da Pro in su. Come funziona la verifica dell'identità dell'agente.POST /v1/suite/guard/tool-permissions) ti permettono di definire una lista consentita per ogni strumento, invece di fidarti del giudizio dell'agente stesso su cosa dovrebbe chiamare. Piano: Max (Guard).[VS:EMAIL:a1b2c3]) prima di attraversare il confine di uno strumento, non dopo. VeriSwarm Guard esegue questo su POST /v1/suite/guard/pii/tokenize, supportato da un motore di rilevamento NER basato su Presidio, e Guard Proxy lo applica in modo trasparente a ogni chiamata a strumenti MCP senza modifiche al codice dell'agente. Piano: Max (Guard). I tre vettori che questo chiude.POST /v1/suite/guard/scan) controlla il testo non attendibile prima che raggiunga un passaggio in grado di agire su di esso, combinando il rilevamento di pattern strutturali con un classificatore ML DeBERTa. Piano: Max (Guard). Come funziona la scansione.POST /v1/suite/guard/kill/{agent_id}) blocca ogni successiva verifica delle decisioni ed emissione di credenziali per quell'agente, indipendentemente da cosa dica il suo stesso prompt. Vive completamente al di fuori del ragionamento dell'agente — non viene chiesto all'agente di fermarsi, gli viene negato a livello di policy la prossima volta che tenta di agire. Piano: Max (Guard). Come funziona davvero il kill switch.È allettante leggere una checklist di sei voci come sei cose da comprare. Non è così che si dividono i piani. Il livello decisionale che sta alla base di ogni controllo — VeriSwarm Gate — è gratuito: punteggio di fiducia completo, 5.000 verifiche consenti/rivedi/nega al giorno, acquisizione di eventi illimitata, ed emissione illimitata di credenziali di base. Puoi stabilire l'identità e iniziare a valutare il comportamento dell'agente senza registrare una carta. Ciò che è limitato è il livello di applicazione — i permessi degli strumenti di Guard, la tokenizzazione, la scansione delle iniezioni e il kill switch, oltre al registro interrogabile ed esportabile di Vault — che è su Max. L'identità Passport più completa (verifica, manifesti, deleghe) si trova nel mezzo, su Pro. Non lasciare che un fornitore lasci intendere che il piano gratuito sia una demo ridotta; per gran parte degli agenti interni a basso raggio d'impatto, identità più livello decisionale bastano da soli.
I sei controlli non sono interruttori indipendenti — alimentano un'unica decisione. L'identità dice al motore delle policy quale agente sta chiedendo. Il punteggio di fiducia, alimentato dal flusso di eventi su cui scrivono sia Guard che Gate, gli dice come si è comportato quell'agente. I permessi degli strumenti, la tokenizzazione delle PII e la scansione delle iniezioni sono i punti di applicazione in cui una richiesta specifica procede oppure viene fermata. Il kill switch è l'override che prevale su tutto il resto. Il registro di audit è ciò che ti permette di ricostruire, a posteriori, perché una determinata richiesta è stata consentita o negata. Quella decisione — allow, review, or deny — è il livello di fiducia che sta alla base di tutti e sei i controlli. Cos'è davvero un livello di fiducia.
Identità delimitata (sapere quale agente è questo, e chi ne è responsabile), permessi degli strumenti al minimo privilegio (limitare quali strumenti può chiamare e a quali condizioni), tokenizzazione delle PII (rimuovere i dati sensibili prima che attraversino il confine di uno strumento), scansione delle iniezioni di prompt (individuare istruzioni manipolate prima che innescino una chiamata a uno strumento), un kill switch (un override dell'operatore che vive al di fuori del ragionamento dell'agente stesso), e un registro di audit (un archivio immutabile di ciò che l'agente ha effettivamente fatto). Nessuno dei sei sostituisce un altro — un agente con identità perfetta e senza kill switch è comunque a un solo prompt sbagliato di distanza da un incidente.
Il livello decisionale che sta alla base di tutti e sei è gratuito: il punteggio di fiducia di VeriSwarm Gate, le decisioni di policy consenti/rivedi/nega (5.000 verifiche/giorno), l'acquisizione illimitata di eventi, e l'emissione illimitata di credenziali portatili di base (token di identità JWT, verificabili tramite JWKS) non costano nulla. Il livello di applicazione — i permessi degli strumenti di Guard, la tokenizzazione delle PII, la scansione delle iniezioni e il kill switch, oltre al registro di audit interrogabile ed esportabile di Vault — è una funzionalità del piano Max. La verifica dell'identità più completa con manifesti firmati e deleghe (Passport) si trova su Pro. Puoi collegare l'identità e iniziare a valutare il comportamento sul livello gratuito; l'applicazione è dove il piano a pagamento inizia a fare il proprio lavoro.
No. Un'istruzione nel system prompt è una richiesta da cui il modello può essere convinto a discostarsi — è esattamente ciò che sfrutta l'iniezione di prompt. Ogni controllo di questo elenco, tranne l'identità, opera al di fuori del ragionamento del modello stesso: i permessi degli strumenti vengono verificati prima che una chiamata venga eseguita, la tokenizzazione delle PII agisce sul testo indipendentemente da ciò che l'agente intendeva, e il kill switch nega a livello di policy indipendentemente da cosa dica il prompt dell'agente. Lo schema in tutti e quattro i controlli di applicazione è lo stesso — spostare la verifica su un livello con cui il modello non può discutere.
Identità e livello decisionale (Gate) sono la base minima — distribuire senza di essi significa non avere modo di sapere quale agente ha fatto cosa, né di agire su uno schema di comportamento scorretto una volta individuato. Gli altri quattro scalano in base a ciò che l'agente può effettivamente fare. Un agente interno di sola lettura senza esposizione di PII ha una superficie di rischio molto più sottile di uno che chiama un'API di pagamento e gestisce dati dei clienti — ma nel momento in cui un agente può chiamare uno strumento esterno o toccare dati sensibili, i permessi degli strumenti e la tokenizzazione delle PII smettono di essere opzionali. Il kill switch e il registro di audit sono abbastanza economici, in termini di ingegneria, che raramente c'è un buon motivo per saltarli una volta che Guard e Vault sono già collegati.
Le protezioni di un framework (callback di LangChain, i validatori di task di CrewAI, un try/except personalizzato attorno a una chiamata a uno strumento) vengono eseguite all'interno dello stesso processo dell'agente e dipendono dalla corretta esecuzione del percorso di codice dell'agente stesso. I sei controlli descritti qui sono esterni a quel processo — VeriSwarm si colloca tra l'agente e gli strumenti/decisioni che sta cercando di prendere, così un bug o un'iniezione riuscita nella logica dell'agente stesso non disattiva anche il controllo che la sorveglia. È la stessa ragione per cui un firewall non viene implementato come un'impostazione all'interno dell'applicazione che protegge.
Ogni controllo chiude una distinta modalità di guasto, quindi saltarne uno lascia aperta proprio quella modalità. Salta l'identità e non potrai attribuire un incidente a uno specifico agente né revocare solo l'accesso di quell'agente. Salta i permessi degli strumenti e un agente compromesso potrà chiamare qualsiasi cosa per cui abbia credenziali. Salta la tokenizzazione delle PII e una fuga di dati sembrerà l'agente che sta semplicemente facendo il suo lavoro. Salta la scansione delle iniezioni e un input manipolato potrà innescare una chiamata a uno strumento non autorizzata prima che qualcuno la esamini. Salta il kill switch e non ci sarà un modo rapido per fermare un agente che si comporta male, se non revocargli le credenziali. Salta il registro di audit e non avrai alcuna prova di ciò che è accaduto, il che conta tanto per il post-mortem quanto per l'incidente stesso.
Il punteggio di fiducia di Gate, le verifiche delle decisioni e l'emissione di credenziali di base non costano nulla. Aggiungi i controlli di applicazione di Guard e il registro esportabile di Vault quando il raggio d'impatto di un agente lo giustifica.