L'ingegnere che rende il tuo agente AI sicuro da eseguire sui dati e sul denaro dei clienti

Progetto sistemi e dirigo l'IA che li costruisce. PANTHEON è uno di questi: multi-tenant, governato, misurato a consumo, in produzione, costruito da solo.

Ho progettato PANTHEON, isolamento multi-tenant, governance, metering, sicurezza degli agenti, partendo dai principi primi, poi ho diretto l'AI nel costruirlo tutto: da solo, fino alla produzione, con dati di attività reali. Quello che porto è il pensiero sistemico per progettarlo e la disciplina per costringere la macchina a dimostrare che funziona.

Scrivimi → Vedi le prove ↓

Isaac Teague Frayling · Cardiff, Regno Unito · cittadino britannico · disponibile a trasferirmi ovunque nel mondo (sponsorizzazione necessaria fuori da Regno Unito & Irlanda) · CV di una pagina →

↑ L'immagine hero, la favicon, l'avatar e la social card di questa pagina sono stati tutti generati dal sistema che ho costruito. Il lavoro ha creato il proprio portfolio.

Riconoscimento esterno. Reporter accreditato (uno di sette) per CVE-2026-104850 (GHSA-6qxp-vccf-f47h), un advisory di gravità alta (CVSS 7.5) nell'SDK TypeScript di MCP: il suo client OAuth poteva inviare credenziali memorizzate a un server scelto dal server MCP; corretto in 1.31.0 e 2.2.0. Non è una convalida di PANTHEON, ma una verifica che qualcun altro ha condotto sul mio lavoro.

non fidarti della mia parola

Ogni affermazione qui rimanda a una verifica che puoi eseguire.

Niente slide, niente "fidati di me". Il sistema è live: prova a romperlo, poi fai revisionare il codice che c'è dietro sotto NDA. Ciò che ho rilasciato è reale e in funzione, che io ne abbia digitato un carattere o no.

Prova a rompere l'assistente live ↗ · Prova tu a violare l'isolamento dei tenant → · Scrivi al bot su Telegram ↗ · Guarda cosa costruisce per aziende reali → · Leggi l'audit avversariale →

il valore

Cosa porto davvero.

Pensiero sistemico che regge sotto attacco

Ho progettato un isolamento multi-tenant rigoroso sulla sicurezza a livello di riga di Postgres, a due ruoli, che in caso di errore si chiude, e che nessun audit ha superato a livello di database. È stata trovata una fuga di dati al di fuori (cronologia chat, luglio), poi corretta. Non ho scritto io l'SQL. Ho progettato il modello: le modalità di guasto, il raggio d'impatto, e ho guidato lo sviluppo finché ha retto.

Progetto AI governata, non colla di prompt

Il loop dell'agente governato, percezione → conoscenza → strumenti → giudizio → misurazione, con limiti di sicurezza, un protocollo di crisi, una misurazione a prova di scoperto e punti di approvazione umana, è un mio progetto. L'impostazione del control plane è mia, l'AI ha scritto il codice secondo le mie specifiche.

Dall'idea alla produzione, dirigendo l'AI

Il substrato, uno Studio no-code, arte generativa su misura, un canale Telegram attivo (WhatsApp costruito, in attesa di approvazione da Meta), misurazione dei consumi, auth, domini personalizzati. Tutto frutto di una mia idea, tutto costruito dirigendo l'AI, da Postgres ai pixel, rilasciato e in funzione, da solo.

Faccio dimostrare alla macchina il suo lavoro

Ogni modifica deve superare un confine di purezza imposto in CI, il conteggio dell'ultima esecuzione CI dei test, audit avversariali ripetuti in cui ogni rilievo è stato confutato prima di contare. Dirigere bene l'AI significa rifiutarsi di fidarsene: questa è la vera competenza.

Giudizio, non solo output

Rilascio la versione onesta: ogni numero nella pagina dell'audit porta il suo asterisco, il sito dice apertamente cosa non è ancora risolto, e la sicurezza (un messaggio di crisi raggiunge l'aiuto anche a zero crediti) batte la metrica. Preferisco che ci si fidi di me piuttosto che impressionare.

Vado veloce senza rompere le garanzie

Ogni nuova capacità mantiene le stesse invarianti: un harness a file golden dimostra che le modifiche sono sicure a livello di byte, un registro delle modifiche rende ogni cambiamento annullabile, e tutto ciò che aggiunge nuova superficie passa una revisione di sicurezza avversariale prima del deploy. Vado veloce senza lasciare che la macchina prenda scorciatoie.

il metodo

Come costruisco: la versione onesta.

Decido cosa il sistema deve garantire, poi gli faccio dimostrare che lo fa. Progetto il sistema e dirigo l'IA che lo costruisce, e PANTHEON è il risultato. Leggo, valuto e faccio il debug di tutto ciò che la macchina produce; non scrivo l'implementazione partendo da un file vuoto. Ecco come funziona:

Cosa faccio

Progettare il sistema dai principi primi → scomporlo in parti che l'AI può costruire → dirigere l'AI nel costruire ciascuna → attaccare il risultato finché regge → rilasciarlo e mantenerlo in funzione in produzione. Questo è il ciclo, dall'inizio alla fine.

Concetti che conosco a menadito

Isolamento multi-tenant & confini di fiducia · livelli di governance & human-in-the-loop · metering atomico & controllo della frequenza · loop di agenti, tool & guardrail · difesa dalla prompt injection · ragionamento su modalità di guasto & raggio d'impatto. Ho progettato tutto questo. Ne parlo solo in un linguaggio semplice, non in gergo.

Sistemi che ho rilasciato (e che comprendo end-to-end)

Postgres con row-level security · servizi FastAPI · un agent loop governato · MCP, in entrambe le direzioni · frontend React · deploy Docker / nginx. Ho diretto la costruzione e so come si comporta ogni componente.

Come mantengo onesta l'IA

Confini di purezza in CI · test snapshot con golden file · il conteggio dell'ultima esecuzione CI dei test superati (ultima esecuzione CI) · audit avversariali ripetuti: un audit con 50 agenti e un nuovo audit con 14 prospettive, il più recente, in cui ogni rilievo viene confutato prima di contare. L'istinto di diffidare della prima risposta della macchina è tutto il lavoro.

Le prove, con l'asterisco già incluso.

Preferisco che tu ti fidi delle parti reali piuttosto che restare colpito da parti che non lo sono.

1mente, nessun team* progettato e diretto da solo

CItest superati* ultima esecuzione CI, non una dimostrazione formale

6 → 0audit · zero critici aperti* eseguito da me, non da terze parti

livein produzione, tenant reali* istanza singola. Non ho ancora dovuto scalarla

2 → 1attività, un'unica spina dorsale* piattaforma, non una demo, dimostrato dal lint

una decisione che ho sbagliato

Un esempio, incluso un mio errore.

Due settimane fa ho scelto di controllare i messaggi in inglese per formulazioni di crisi solo con un elenco fisso di frasi, per risparmiare alla maggior parte dei messaggi una chiamata AI in più. Un audit del 25 settembre ha mostrato che l'elenco non rilevava "I don't want to live anymore" e altre tre formulazioni comuni. Ho ribaltato la decisione in giornata: le formulazioni di crisi ora passano al controllo AI, tutte e quattro sono test che fallivano sul vecchio codice, e i messaggi ordinari che pagano la chiamata in più sono scesi da 4 su 32 a 1. Il risparmio era giusto per la maggior parte dei controlli e sbagliato per quello in cui un errore conta di più.

il patto onesto

Cosa ottieni, e cosa no.

L'architetto + regista

Mi occupo del pensiero sistemico e della delivery tramite l'AI: decido cosa costruire, progetto come deve reggere e lo porto avanti finché non è rilasciato. Affiancatemi a ingegneri che padroneggiano l'artigianato riga per riga che io non ho, e avrete coperte entrambe le metà.

La disciplina che l'AI non ha da sola

Ogni modifica che conta passa per una revisione avversariale; non mi fido mai della prima risposta della macchina. Due cose prodotte da questo istinto: la fuga di dati tra tenant di luglio, trovata dal mio audit e ora un test di regressione, e l'advisory sull'SDK MCP citato sopra, trovato nel codice di qualcun altro.

la richiesta

Cosa cerco.

Un solo ruolo: la persona responsabile del confine di fiducia del tuo agente AI. Tenancy, approvazioni, metering, lo strumento che si fida di chi lo chiama: individuo dove può cedere, integro la garanzia nel sistema e rilascio il test che la dimostra. Un founding hire o una delle prime assunzioni in una startup che ha un agente a contatto con clienti reali, o che sta per averlo. Sono disponibile a trasferirmi ovunque nel mondo per l'opportunità giusta, e mi importano più il problema e le persone che il titolo.

Perché un lavoro e non una mia startup?

Domanda legittima. Potrei raccogliere fondi su PANTHEON, ma so esattamente cosa gli manca, e non è lo sviluppo. È la distribuzione: la rete e la portata per metterlo davanti alle aziende per cui è costruito, che non ho e non fingerò di avere. Preferisco portarlo a un team che ha già quella portata piuttosto che passare anni a diventare un founder che non sono. Costruirlo da solo ha dimostrato che so progettare e rilasciare l'intero sistema. Portarlo sul mercato da solo non è mai stato il piano: PANTHEON resta live come prova, non come progetto secondario che divide la mia attenzione.

il primo giorno

Indicami un problema, ecco cosa farei per prima cosa.

Non "impara il mestiere per un trimestre". Il metodo che ha costruito PANTHEON, applicato al tuo prodotto:

Mappare il confine di fiducia

Trovare i confini di tenancy / autorizzazione / raggio d'impatto e capire come fallisce ciascuno, prima che venga costruito qualsiasi cosa. Non puoi governare ciò che non hai disegnato, e disegnarlo è quello che faccio.

Trova dove la sicurezza è aggiunta a posteriori

Trova la sicurezza aggiunta a posteriori: il contatore che può andare in scoperto, l'azione senza controllo, lo strumento che si fida di chi lo chiama, e riprogettala in modo che la garanzia sia integrata, non appiccicata sopra.

Dirigi la costruzione, poi dimostrala

Specificalo, fallo costruire all'AI e rilascialo con il controllo che lo dimostra: un test, uno snapshot, un invariante, così la persona successiva può muoversi in fretta senza doverlo dimostrare tutto da capo.

Parliamone.

Dimmi il ruolo e cosa state costruendo. Leggo ogni email e rispondo entro pochi giorni, poi una call, una demo dal vivo del sistema e il codice esaminato sotto NDA.

isaac@pantheonlabs.co.uk →

Preferisci provare prima di scrivere? Rompi l'assistente, attacca l'isolamento o scrivi al bot, è tutto live.

Niente LinkedIn. Il sistema principale è privato: il portfolio è il sistema in produzione, ma sei componenti sono pubblicati su PyPI e npm, il registro dei difetti è pubblico, il metodo è riproducibile, e sono uno dei sette segnalatori accreditati in un advisory di sicurezza dell'SDK MCP di gravità alta. Visualizza / scarica il mio CV →