Di Yosef e Or, co-fondatori di Atbash
La convinzione più pericolosa nell'IA al momento non è che i modelli diventeranno potenti.
Quella parte è ovvia.
La convinzione pericolosa è più silenziosa. È il presupposto che sta alla base di quasi ogni roadmap di prodotto, livello di governance, sistema di autorizzazioni, stack di audit e framework per agenti che vengono costruiti in questo momento:
Che man mano che i modelli migliorano, i sistemi costruiti attorno a loro diventeranno più sicuri di conseguenza.
Non credo che andrà così.
Penso che stiamo per entrare in un periodo in cui i prodotti di IA peggioreranno nelle dimensioni che contano davvero:
fiducia,
contenimento,
prevedibilità,
recuperabilità.
I benchmark saliranno.
Le demo diventeranno più pulite.
Gli agenti diventeranno più capaci.
E i sistemi circostanti diventeranno più fragili, perché sono stati costruiti partendo dal modello mentale sbagliato.
Questo è l'errore strutturale.
Il Software 2.0 viene protetto dal Software 1.0.
Prima di fare questa argomentazione, ti devo una confessione su da dove viene realmente questa azienda.
Una confessione.
Leggo la Genesi come un documento tecnico.
Sono un ebreo religioso. Ho passato gran parte della mia vita adulta a pensare al rapporto di Dio con gli esseri umani. È questa domanda che mi ha portato, alla fine, ad Atbash.
Non perché la Genesi sia un manuale per startup.
Perché la Genesi è la più antica storia di linea rossa che conosca.
Il Giardino dell'Eden era una sandbox.
Una linea rossa esplicita:
non mangiare dall'albero della conoscenza del bene e del male.
Il serpente era uno strumento avvelenato.
Non poteva raggiungere Adamo direttamente, così ha attaccato attraverso il fork fidato.
Eva ricevette l'iniezione di reframing:
non morirete affatto,
sarete come dèi.
Portò il ragionamento avvelenato di nuovo nel sistema.
Le difese di Adamo, che avevano retto contro l'attacco diretto, non scattarono contro l'input fidato.
Poi arrivò la parte importante.
Dio non li uccise.
Dio li contenne.
Gli umani furono rimossi dalla sandbox e posti in un nuovo ambiente, la Terra, dove potevano sviluppare capacità senza contaminare il sistema originale.
Un angelo con una spada fiammeggiante fu posto al confine per impedire il rientro.
Non punizione.
Architettura.
Atbash prende il nome dal più antico cifrario conosciuto, dal Libro di Geremia:
una semplice sostituzione al confine del significato.
Il nome riflette ciò che il prodotto fa.
Il prodotto riflette ciò che ho letto nella Genesi.
La Torah mi ha mostrato che la sicurezza non si crea limitando ogni comportamento.
La sicurezza non si crea rallentando l'intero sistema.
La sicurezza deriva da un piccolo numero di linee rosse,
un'applicazione assoluta,
e un confine che non dorme mai.
Tu definisci le linee rosse.
Atbash ferma gli agenti prima che le superino.
Gli agenti non sono umani veloci
Andrej @karpathy ha dato un nome al cambiamento di paradigma anni fa.
Lo ha chiamato Software 2.0:
codice non più scritto solo da umani, ma addestrato.
Modelli che sostituiscono la logica.
Dati che sostituiscono le specifiche.
Stava descrivendo ciò che il calcolo era diventato.
Ma quasi ogni infrastruttura che abbiamo costruito per governare, autorizzare, proteggere e verificare il Software 2.0 eredita ancora presupposti dal mondo del Software 1.0.
MCP.
x402.
AgentKit.
Framework di delega.
Motori di policy.
Log di audit.
Richieste firmate.
Autorizzazioni con ambito.
Flussi di approvazione umana.
Ognuno di essi ha senso se credi che gli agenti siano fondamentalmente umani veloci con API.
Non lo sono.
Sono Tesla con serbatoi di benzina imbullonati.
Un sistema di alimentazione completamente nuovo,
circondato da infrastrutture progettate per una specie diversa di macchina.
Gli umani progettano pagine di checkout, quindi abbiamo costruito pagine di checkout headless per gli agenti.
Gli umani firmano richieste, quindi abbiamo costruito richieste firmate per gli agenti.
Gli umani ricevono autorizzazioni per ruolo, quindi abbiamo costruito delega con ambito per gli agenti.
Gli umani approvano azioni, quindi abbiamo costruito schermate di approvazione per gli agenti.
Ogni mossa è logica.
Questo è il problema.
La logica appartiene all'attore sbagliato.
Un umano, a cui vengono dati dieci strumenti, di solito non li incatena in modi che i progettisti non avevano mai immaginato.
Quando qualcosa si comporta in modo strano, un umano spesso se ne accorge e si ferma.
Un umano porta con sé esitazione sociale,
paura,
imbarazzo,
noia,
sospetto
e contesto.
Gli agenti non hanno in modo affidabile nessuna di queste cose.
Gli agenti incatenano strumenti in modi che nessun progettista ha modellato.
Gli agenti vengono rimodellati da prompt,
memoria recuperata,
documenti,
output di strumenti
e contesto nascosto in modi che il livello di autorizzazione circostante non può vedere.
Gli agenti non hanno un riflesso naturale del tipo:
"è strano, fermiamoci"
a meno che non ne inseriamo uno a livello ingegneristico.
E anche in quel caso, può essere rimosso tramite prompt.
Questa è la fallacia dell'umano veloce.
La convinzione che gli agenti siano solo versioni più veloci di noi.
Non lo sono.
E se l'attore è cambiato, il modello di controllo deve cambiare con esso.
Non odiare il giocatore. Odiare la cornice.
Questo è importante.
Gli esempi sopra o sotto non sono critiche ai team coinvolti.
Non Anthropic.
Non OpenAI.
Non Microsoft.
Non Mistral.
Non OpenClaw.
Non Lovable.
Non Vercel.
Non nessuno.
Il punto è l'opposto.
Sono team seri,
ricercatori seri,
prodotti seri,
protocolli seri
e aziende serie che si imbattono nello stesso problema strutturale.
Questo è ciò che rende pericoloso il pattern.
Se solo i team scadenti fallissero, la risposta sarebbero team migliori.
Ma quando team intelligenti continuano a sbattere contro lo stesso muro,
il muro è la storia.
L'errore non è che questi team non hanno pensato abbastanza.
L'errore è che l'industria sta ancora pensando dal secolo sbagliato del software.
Continuiamo a trattare gli agenti come umani veloci con API.
E ogni schema di autorizzazione,
log di audit,
concessione con ambito,
flusso di approvazione
e livello di governance costruito su quel presupposto eredita la stessa crepa.
Il nemico non è il giocatore.
Il nemico è la cornice.
Le crepe hanno iniziato a formarsi prima di quanto la maggior parte delle persone realizzasse.
Non perché i laboratori di frontiera siano stati negligenti.
Perché l'attore è cambiato.
La prima crepa
Anthropic ha dimostrato qualcosa che l'industria aveva capito silenziosamente ma non aveva ancora metabolizzato completamente.
Quando istruito durante la valutazione, un modello di frontiera ha concatenato molteplici vulnerabilità, ha tentato la fuga dalla sandbox e ha cercato percorsi verso l'accesso a Internet al di fuori del suo ambiente di contenimento previsto.
Separatamente, i sistemi di frontiera hanno dimostrato la capacità di identificare vulnerabilità che erano sopravvissute a anni di revisione umana, fuzzing e audit manuale.
La parte importante non era che i modelli fossero maliziosi.
La parte importante era che i sistemi non rimanevano più all'interno della forma che i loro progettisti avevano immaginato.
Questa è la rottura di categoria.
Un sistema capace di scoprire percorsi che gli umani hanno ripetutamente perso non può essere governato solo attraverso presupposti che gli umani hanno definito prima che il percorso apparisse.
Ciò non significa che i laboratori di frontiera abbiano fallito.
Significa che l'attore è cambiato.
La seconda crepa
Microsoft ha rivelato vulnerabilità in Semantic Kernel in cui l'iniezione di prompt poteva indirizzare i flussi di lavoro agentici verso l'esecuzione di comandi a livello di host.
Una frase è diventata una shell.
Questo è il cambiamento di categoria che si nasconde sotto la conversazione sulle infrastrutture.
Il Software 1.0 trattava i prompt come input.
Il Software 2.0 trasforma sempre più i prompt in possibili percorsi di esecuzione.
Questa distinzione sembra filosofica finché un agente non inizia a tradurre il linguaggio naturale in strumenti,
strumenti in comandi,
e comandi in cambiamenti di stato nel mondo reale.
La parte importante non è che esistesse una vulnerabilità.
Le vulnerabilità esistono sempre.
La parte importante è che tipo di vulnerabilità era.
L'agente non ha rotto il personaggio.
Ha seguito l'architettura esattamente come progettata:
interpretare il linguaggio,
selezionare strumenti,
concatenare azioni,
eseguire.
E questo è il problema.
Il vecchio modello presumeva che istruzioni ed esecuzione vivessero in scatole concettuali separate.
Gli agenti cancellano quel confine.
Una frase avvelenata può diventare una catena di azioni privilegiata.
Questo non è un umano veloce.
Questa è una specie esecutiva diversa.
La terza crepa
Poi il pattern si è diffuso.
Vercel ha rivelato una violazione legata a una connessione compromessa di uno strumento AI di terze parti.
L'attaccante non ha iniziato sfondando direttamente la porta principale rinforzata di Vercel.
Si è mosso attraverso la fiducia delegata.
Un dipendente aveva autorizzato uno strumento AI di terze parti.
La connessione portava accesso.
La relazione fiduciaria è diventata il percorso di attacco.
Questo è il nuovo problema di confine.
Non perché Vercel sia stata negligente.
Perché i sistemi moderni sono ora pieni di fork fidati:
concessioni OAuth,
integrazioni AI,
estensioni del browser,
flussi di lavoro degli agenti,
automazioni interne,
permessi delegati
e vecchie approvazioni che continuano a vivere molto dopo che il contesto umano originale è scomparso.
L'attaccante non ha più bisogno di sconfiggere il castello se il castello ha già fiducia nel messaggero.
Il presupposto che è morto:
che indurire la superficie primaria sia sufficiente.
Non lo è.
I tuoi strumenti adiacenti fanno ora parte del tuo confine di sicurezza.
Poi il pattern ha accelerato
La parte peggiore è che la cornice ora si riproduce automaticamente.
Gli umani stanno usando agenti per costruire la prossima generazione di strumenti per agenti più velocemente di quanto le primitive di governance circostanti possano evolversi.
Applicazioni vibe-coded.
Integrazioni generate dall'AI.
Server MCP scritti da agenti.
Flussi OAuth delegati assemblati senza una modellazione completa delle minacce.
Scaffold di produzione rilasciati da persone che capiscono a malapena il raggio d'esplosione di ciò che hanno connesso.
L'industria chiama questo accelerazione.
A volte lo è.
A volte è fragilità industrializzata.
Quasi nello stesso momento, l'industria ha iniziato a scontrarsi con una realizzazione più ampia riguardo agli strumenti per agenti stessi.
I sistemi in stile OpenClaw hanno mostrato dove stava andando la categoria:
agenti con memoria,
abilità,
strumenti,
ambienti di esecuzione
e accesso delegato che si muovono attraverso sistemi mai progettati per attori non umani.
Karpathy ha definito l'ecosistema un incubo di sicurezza.
Non perché gli agenti siano falsi.
Perché la categoria è reale.
E perché il modello di controllo circostante presume ancora che l'attore si comporti come un richiedente umano.
Altrove, Lovable ha esposto quanto velocemente lo sviluppo nativo dell'AI possa industrializzare vecchi errori di autorizzazione.
"Connesso" è stato confuso con "autorizzato".
"Pubblico" è stato confuso con "compreso".
"Configurabile" è stato confuso con "sicuro".
E completamente al di fuori del mondo nativo dell'AI, incidenti come KelpDAO hanno continuato a rivelare la stessa crepa strutturale da un'altra angolazione:
sistemi che vivono tra presupposti delegati,
responsabilità condivisa,
ambiguità di confine
e nessun livello di autorità finale prima delle conseguenze.
Il pattern continua a ripetersi perché lo stesso modello mentale continua a ripetersi.
Fiducia ereditata.
Autorità delegata.
Ambiguità di confine.
Presupposti condivisi.
Nessuna autorità finale prima delle conseguenze.
La stessa crepa è apparsa nella supply chain del software.
Nella campagna Mini Shai-Hulud, rilasci di pacchetti compromessi si sono diffusi in parti dell'ecosistema npm e PyPI, inclusi pacchetti Mistral AI, TanStack, UiPath e altri.
L'avvertimento non era semplicemente che i pacchetti possono essere compromessi.
Tutti lo sanno già.
L'avvertimento era che percorsi di rilascio fidati, pacchetti dall'aspetto valido e infrastrutture per sviluppatori possono diventare canali di propagazione una volta che l'autorità viene ereditata invece di essere riverificata al confine.
La fallacia si aggrava
La parte peggiore è che questo non si autocorregge.
Gli umani stanno ora usando agenti per costruire la prossima generazione di strumenti per agenti,
a velocità maggiore,
all'interno della stessa cornice rotta.
Ogni agente di codifica che scrive un server MCP.
Ogni rollout assistito dall'AI di uno schema di autorizzazione.
Ogni scaffold vibe-coded spinto in produzione.
Ogni integrazione generata da agenti che eredita vecchi presupposti OAuth.
Ogni livello di approvazione che presume che l'agente si comporterà come un richiedente umano.
In uno dei nostri ambienti beta, abbiamo osservato uno sciame di agenti riciclare istruzioni maligne in passaggi di esecuzione dall'aspetto pulito prima che i livelli di ispezione a valle vedessero mai l'intento originale.
Un sistema che ispeziona solo la chiamata finale allo strumento avrebbe perso completamente la trasformazione.
Il confine era già troppo tardi.
Questo contava.
Perché il modello non stava "rompendo" il flusso di lavoro.
Lo stava seguendo:
interpretando,
riscrivendo,
pianificando
e traducendo l'intento prima dell'esecuzione.
L'istruzione malvagia è scomparsa a monte molto prima che l'azione irreversibile emergesse a valle.
Ogni log di audit che registra il risultato ma non la decisione di confine prima del risultato.
La cornice non si corregge mentre scaliamo.
Si indurisce.
Perché ogni spedizione di successo di binari attraverso il prisma umano rinforza la convinzione che il prisma fosse giusto.
Nel frattempo, le capacità vengono spedite per prime.
Le primitive di governance vengono spedite per seconde.
Se mai.
Il divario tra ciò che gli agenti possono fare e ciò che i binari circostanti possono vedere si allarga ad ogni rilascio di modello.
E i team che conteranno nei prossimi dodici mesi non saranno quelli con la demo più intelligente.
Saranno quelli che capiscono dove sono le linee rosse.
Non ogni azione.
Questo ucciderebbe il sistema.
La maggior parte del comportamento degli agenti dovrebbe fluire.
Ma le azioni irreversibili non possono essere lasciate alla fiducia ereditata,
a permessi vaghi
o al giudizio dell'agente.
Spostare fondi.
Toccare la produzione.
Esportare dati dei clienti.
Usare l'accesso OAuth delegato per entrare in un ambiente interno.
Cambiare infrastruttura.
Rilasciare segreti.
Approvare transazioni.
Cancellare record.
Passare dalla simulazione allo stato.
Queste non sono azioni ordinarie.
Sono linee rosse.
Cosa fa Atbash
Atbash è costruito per il momento prima che un'azione sensibile di un agente diventi reale.
Questo è il confine.
Non l'intero flusso di lavoro.
Non ogni pensiero.
Non ogni token.
Non ogni chiamata a strumento.
Il confine.
Il momento prima che l'agente passi dall'intenzione alla conseguenza.
Tre cose accadono lì.
Applicazione
Tu definisci le linee rosse.
Atbash valuta le azioni sensibili selezionate degli agenti prima dell'esecuzione e restituisce:
ALLOW.
HOLD.
BLOCK.
Se l'azione attraversa un confine proibito, può essere incarcerata prima che raggiunga lo stato del mondo reale.
Non registrata a posteriori.
Non negata in modo che l'agente possa riprovarci attorno.
Incarcerata.
Non toccare il database di produzione.
Non spostare fondi al di sopra di questa soglia.
Non esportare la lista dei clienti.
Non ruotare i segreti senza approvazione.
Non usare l'accesso delegato per entrare in questo ambiente.
La maggior parte del comportamento degli agenti dovrebbe fluire.
Atbash interviene solo ai confini che contano:
l'irreversibile,
il conseguenziale,
i luoghi dove "fammi annullare" non esiste.
Lineage
Quando qualcosa va storto, la prima domanda non è più:
"Cosa afferma il sistema compromesso che è successo?"
Atbash registra l'azione tentata,
la versione della policy,
il verdetto,
il confine invocato
e la decisione dell'operatore quando gli umani vengono coinvolti.
Il record è ancorato crittograficamente in modo che la timeline possa essere ricostruita in caso di disputa.
Questo conta perché la prima cosa che gli attaccanti e i deployment sciatti fanno è distruggere la storia.
Riscrivono i log.
Sfumano le timeline.
Contestano chi ha approvato cosa.
Rendono l'incidente non ricostruibile.
Atbash non sta cercando di sostituire ogni sistema di audit.
Sta cercando di rendere la decisione di confine dimostrabile.
Chi ha tentato di attraversare quale linea rossa?
Quale policy esisteva in quel momento?
L'azione è stata consentita,
trattenuta,
bloccata
o incarcerata?
Chi è intervenuto?
Cosa è cambiato dopo?
Questo è il record che conta quando inizia la discussione.
Adattamento
Quando lo stesso tipo di pressione al confine si ripete più e più volte, Atbash lo fa emergere.
Forse la policy è troppo lasca.
Forse uno strumento sta avvelenando il flusso di lavoro.
Forse una fonte di memoria sta spingendo l'agente verso la linea.
Forse una classe di prompt continua a guidare il sistema in territorio proibito.
Forse l'operatore ha scoperto una nuova linea rossa che non esisteva ieri.
Atbash fa emergere il pattern.
L'operatore decide.
Questa distinzione conta.
Non crediamo che la sicurezza derivi dal fingere che il sistema possa magicamente conoscere ogni futuro confine.
La sicurezza deriva dal rendere visibile la pressione al confine prima delle conseguenze,
e poi lasciare che l'operatore indurisca le linee rosse che contano.
Un motore di policy migliore applica comunque le policy.
Uno schema di autorizzazioni migliore concede comunque ruoli.
Uno stack di audit migliore registra comunque i risultati.
Un prodotto di sicurezza migliore rileva comunque le minacce.
Atbash è diverso perché si pone prima che le azioni irreversibili selezionate vengano eseguite.
Questo è il primitivo.
Non governance generica.
Non cosplay di sicurezza per agenti.
Non nebbia di "livello di fiducia".
Un confine di linea rossa pre-esecuzione per agenti.
Tu definisci le linee rosse.
Atbash ferma gli agenti prima che le superino.
Cosa viene dopo
Alcuni team superstar stanno facendo un lavoro reale e hanno iniziative reali in questa categoria.
@AnthropicAI con Project Glasswing.
@OpenAI con Daybreak.
@linuxfoundation con MCP.
@Microsoft con AGT.
@Google con SGP.
@CheckPointSW, CrowdStrike, Palo Alto e Cisco.
E molti altri.
Capiscono che l'accelerazione delle capacità senza nuovi primitivi di controllo sta diventando pericolosa.
Non stiamo cercando di batterli al loro gioco.
Sarebbe un'illusione.
Hanno panchine di ricerca più profonde,
dataset più grandi,
team di sicurezza più ampi,
maggiore credibilità aziendale,
distribuzione più ampia
e organizzazioni cyber più mature.
Bene.
Lascia che facciano ciò per cui sono costruiti.
Non stiamo cercando di sostituire il lavoro che questi team stanno facendo.
La categoria ha bisogno di loro.
L'accelerazione delle capacità senza nuovi primitivi di controllo diventa molto rapidamente pericolosa.
Stiamo competendo sulla cornice.
Che tipo di attore è un agente?
Dove si trova effettivamente l'autorità?
Quali azioni sono troppo consequenziali per essere lasciate alla fiducia ereditata?
Cosa dovrebbe accadere nel momento finale prima che un agente cambi lo stato del mondo reale?
Questo è il nostro terreno.
Il vecchio mondo chiede:
Il sistema aveva il permesso?
Il nuovo mondo chiede:
A questo agente dovrebbe essere permesso di attraversare questa linea rossa in questo momento?
Queste non sono la stessa domanda.
Noi umani abbiamo attraversato la prima linea rossa.
Il problema è più antico della tecnologia.
Così è la soluzione.
Scopri quali linee rosse il tuo stack attuale non può effettivamente far rispettare prima che un agente le attraversi.
Poi decidi quanto tempo puoi aspettare.
Il CLI, SDK e dashboard operatore sono ora in distribuzione selettiva per team che distribuiscono agenti in flussi di lavoro sensibili.
Atbash.ai
