Sull'essere Agent Ready

2026-06-21T00:00:00+00:00

Ho scoperto di recente Is Your Site Agent Ready</a>, un sito di CloudFlare che ti dice quanto il tuo sito sia davvero... agent ready.

"Che figata", ho pensato. Poi qualcosa ha preso il sopravvento. Uso LLM e agenti ogni giorno e sanno leggere HTML, quindi ho deciso di andare a fondo per capire meglio cosa significhi davvero essere agent ready. Per loro, almeno.

Apro la homepage: "What do we check?", "What's the easiest way to improve my score?", "Where can I learn more?". C'è roba, facile da leggere. MA i miei occhi cadono su un piccolo testo in fondo: "These are AI-generated recommendations. AI can make mistakes. Please use your professional judgment when implementing these tips...".

Ricapitoliamo: questo è un sito AI per verificare se il tuo sito è "AI ready" e, siccome le raccomandazioni sono generate dall'AI, non dovresti fidarti ciecamente? Adoro l'intelligenza artificiale, ma un po' di HI (Human Intelligence) in più non guasterebbe.

Baseline</h2>
Da ingegnere SW non posso fermarmi qui: devo sapere di più, devo misurare, devo impostare un esperimento per capire meglio e arrivare a conclusioni appropriate.
Farò tutto l'esperimento usando ovviamente questo sito: Kalizi.dev</a>. È dietro CloudFlare, quindi loro ce l'hanno già: archiviato, copiato, salvato, in cache, versionato. Lo conoscono, ne hanno visto ogni versione. E sanno ovviamente se qualche agente lo ha letto nel tempo. Spoiler: Google, Amazon, Anthropic, OpenAI, Microsoft, ByteDance e Huawei l'hanno fatto. Sono lusingato. La prossima volta mi aspetto almeno un caffè. </picture>
Comunque, ho ottenuto una valutazione di base di 21 su 100: dicono che è "Basic Web Presence" (Livello 1).
Basic Web Presence</h2>
Il punteggio è pesato su 5 sezioni:

Discoverability: 50 (2 su 4)</li>
Content: 0 (0 su 1)</li>
Bot Access Control: 50 (1 su 2)</li>
API, Auth, MCP & Skill Discovery: 0 (0 su 7)</li>
Commerce: non verificato (questo non è un sito e-commerce)</li> </ul>
Ma c'era ancora un'idea che girava in testa. Fermiamoci un momento e pensiamo a cos'è un agente AI. Oggi, quando si parla di AI Agent si intende generalmente potenziare un LLM con la capacità di svolgere compiti e usare strumenti in un loop.
Se decostruiamo un agente nei suoi componenti base, abbiamo una serie di messaggi e strumenti avvolti in un loop che continua finché l'LLM decide che ha finito. Qualcosa del genere, per chi vuole essere tecnico:
messages = [ {"role": "user", "content": input()} ] task_complete = False while not task_complete: response = llm(messages) task_complete = response.task_complete if response.should_call_tool: tool_result = call_tool( name=response.tool_name, args=response.tool_args ) messages.append({ "role": "assistant", "content": response.reasoning_or_request }) messages.append({ "role": "tool", "content": tool_result }) else: output = response.output messages.append({ "role": "assistant", "content": output }) print(output)</code></pre> Il nucleo è SEMPRE l'LLM. Un LLM può leggere questo sito?</h2> La maggior parte degli LLM di frontiera sono già agenti: non ti danno solo una risposta ma possono usare strumenti e svolgere compiti per te. Quindi li ho interrogati tutti, con lo stesso prompt, per vedere se riuscivano a leggere questo sito. ChatGPT</h3> </picture> Sembra che ChatGPT ce la faccia. Claude</h3> </picture> Anche Claude. Gemini</h3> </picture> Pure Gemini. Proviamo qualcosa di meno "corporate". Deepseek</h3> </picture> Anche Deepseek sembra leggere il contenuto. Mistral</h3> </picture> Persino Mistral l'ha letto. · · · Proprio tutti. Cinque LLM diversi, dai grandi nomi corporate alle alternative open-source più spigliate, hanno letto e capito questo sito. Zero configurazione speciale. Nessun header, nessuna markdown negotiation, nessun record DNS. Solo HTML. Il che solleva la domanda ovvia: se gli agenti riescono già a leggere il sito senza problemi, su cosa stavo prendendo 21 su 100? Allora cosa misurano questi punteggi?</h2> Scomponiamoli.
Discoverability</h3>
Questo punteggio ha 4 controlli:

`robots.txt</code></li>`
`Sitemap</code></li>`
`Link headers</code></li>`
`DNS for AI Discovery (DNS-AID)</code></li> </ul> L'obiettivo dichiarato di robots.txt</code> è: Pubblica /robots.txt con regole di crawl chiare.`User-agent: * Disallow: Allow: / Sitemap: https://kalizi.dev/sitemap.xml</code></pre> Non vedo letteralmente nulla di specifico per gli agenti. Pubblica una sitemap e referenziala da robots.txt. Anche qui, niente che non faresti normalmente. I Link Headers sono il primo punto su cui questo sito non è pronto. Obiettivo: Includi header HTTP Link per la scoperta degli agenti (RFC 8288</a>). L'RFC è lungo 48 pagine stampabili, ha 7 capitoli e 3 appendici. In breve: quando il server invia una pagina, dovrebbe includere uno o più header HTTP Link: ...</code> che indicano ad agenti AI, o ad altri software, dove trovare risorse leggibili dalla macchina sul tuo sito o API. Quindi il server dovrebbe mandare qualcosa del tipo: Link: </me>; rel="author" Link: </projects>; rel="collection" Link: </blog>; rel="collection"</code></pre> In seguito, lo standard HTML ha introdotto il suo modo di farlo, quindi dovrebbe esserci anche qualcosa come: <link rel="me" href="https://github.com/kalizi"> <link rel="me" href="https://www.linkedin.com/in/kalizi-dev/"></code></pre> Diamo un'occhiata al DNS-AID prima di andare avanti. Obiettivo: Pubblica record DNS for AI Discovery (DNS-AID) per la scoperta degli agenti tramite DNS. Si riferisce all'RFC 9460</a>. Altre 48 pagine. Questa volta dice di aggiungere un nuovo record DNS SVCB</code> per dare ai browser istruzioni extra e velocizzare il caricamento del sito. Puoi indicare: usa questo sottodominio</li> </ul> example.com. HTTPS 0 svc.example.net.</code></pre> usa questa porta non standard</li> </ul> example.com. HTTPS 1 . port=8443</code></pre> controlla questi indirizzi IP</li> </ul> example.com. HTTPS 1 . ipv4hint=192.0.2.10 ipv6hint=2001:db8::10</code></pre> Quindi... Siccome il sito è dietro Cloudflare, non posso toccare nulla nell'SVCB</code> senza rischiare di rompere la configurazione di caching o HTTPS di Cloudflare, o di esporre l'IP (non che sia un dramma, ci sono mille altri modi per trovarlo, ma a che serve il proxy se poi suggerisco l'IP direttamente?). E abbiamo davvero bisogno dei link? Può essere più veloce per qualche software, ma lo è per un agente? Gli agenti e gli LLM sono progettati per essere intelligenti, sanno cosa stanno cercando e possono tranquillamente ignorare i link. Content</h3> Qui c'è un solo punto chiave: la Markdown Negotiation. Obiettivo: Restituire le risposte HTML in markdown quando gli agenti lo richiedono. Viene direttamente dalla documentazione di Cloudflare</a> e NON da un RFC. Questo punto è in qualche modo controverso: è solo una proposta, non ci sono prove specifiche che Accept: text/markdown</code> venga usato da qualche agente, tranne nelle osservazioni di Cloudflare. Anche OpenCode ha una issue aperta</a> sull'argomento, ma non è ancora implementata. Il markdown è un formato fantastico, lo uso moltissimo con gli agenti, e anche se potrebbe aiutare gli LLM, potrebbero comunque preferire l'HTML per verificare altri elementi: tag nascosti, link, dati embedded come payload JSON e simili. Bot Access Control</h3> Qui abbiamo il "Bot Access Control". Obiettivo: Aggiungi regole User-agent per i crawler AI come GPTBot, Claude-Web e altri. La parte divertente è leggere il risultato: No AI-specific bot rules; wildcard rules apply to all crawlers including AI bots. Ok! Il punto successivo è la "Web Bot Auth request signing". Non gestisco bot. Saltato. L'ultimo è curioso, il suo obiettivo recita Dichiara le preferenze di utilizzo dei contenuti AI con Content Signals nel robots.txt. PREFERENZE. Ecco un esempio di Cloudflare: Content-Signal: ai-train=no, search=yes, ai-input=no</code></pre> È solo una preferenza, non un'imposizione, quindi... posso dire che la trovo inutile? API, Auth, MCP & Skill Discovery</h3> Si potrebbe parlare a lungo di questa sezione. Ma in breve: questo sito non espone API, non ha autenticazione, non ha funzionalità specifiche, quindi è tutto irrilevante per questo scopo. Agent Ready per cosa?</h2> Ecco il punto: tutti quegli LLM hanno letto questo sito senza problemi. Nessun header speciale, nessuna markdown negotiation, nessun record DNS-AID. Hanno analizzato l'HTML, capito il contenuto, risposto a domande su di esso. Quindi perché 21/100? Perché "agent ready" non riguarda davvero la leggibilità. Riguarda l'azionabilità. C'è una differenza, e conta. Un LLM che legge il tuo sito è un'operazione passiva: fetch, parse, comprensione. Gli LLM moderni sono molto bravi in questo. L'HTML leggibile è sufficiente. "Agent ready" nel senso di Cloudflare significa qualcosa di completamente diverso: un agente AI può fare cose sul tuo sito? Può autenticarsi, chiamare un'API, invocare una skill, piazzare un ordine? È una domanda completamente diversa. Per un blog come questo, la risposta è: non c'è nulla da fare. Non ci sono azioni da compiere. Un agente può leggere dei miei progetti ma non può forkarne uno, prenotare una call o comprare qualcosa. Non è un fallimento, è semplicemente quello che è questo sito. Il punteggio di 21/100 non dice che il mio sito è invisibile agli agenti. Dice che il mio sito non espone nessuna superficie azionabile dalla macchina. Il che è accurato. Quindi la vera domanda non è "il tuo sito è agent ready?" ma "cosa vuoi che gli agenti facciano sul tuo sito?" Se la risposta è "leggerlo e basta": ci sei già. Ogni LLM che ho testato l'ha fatto senza nessuna configurazione speciale. Se vuoi che gli agenti interagiscano, transazionino o si integrino: sì, hai lavoro da fare. API, flussi di autenticazione, endpoint MCP, tutto lo stack. Per la maggior parte dei blog personali e dei siti informativi, questo framework sta risolvendo un problema che non esiste ancora. Gli LLM possono leggere il tuo HTML. Lo fanno da anni. Quello che Cloudflare sta davvero misurando è qualcosa di più vicino alla maturità API per sistemi autonomi: una preoccupazione legittima per e-commerce, piattaforme SaaS, API di servizio. Per un blog? È un martello in cerca di un chiodo. 21/100. Ci sto benissimo.

Ho attaccato un ModernBERT con un algoritmo genetico. Ha funzionato.

2026-04-27T00:00:00+00:00

Ogni hacker, a un certo livello, è qualcuno che ha deciso di non fidarsi della parola "sicuro".

Kevin Mitnick è entrato nei sistemi dell'FBI mentre lo stavano cercando, e ha lasciato un pacco sul posto con scritto "FBI Donuts." Frank Abagnale ha ingannato il sistema di verifica identità di un'intera compagnia aerea a 16 anni. Ogni sistema ha punti ciechi. Ed è lì che vivono gli avversari.

Per la mia tesi magistrale all'Università di Palermo, ho deciso di fare l'avversario. Non contro un istituto finanziario o una rete governativa. Contro un modello NLP allo stato dell'arte: un ModernBERT fine-tuned sul dataset di recensioni IMDB.

Il risultato: 100% di successo nell'attacco. Una media di 18 query al modello. Zero degradazione semantica.

Ecco come funziona.

La crepa nel NLP "robusto"</h2>
I modelli linguistici moderni sono davvero impressionanti. ModernBERT raggiunge il 93,9% di accuratezza nella classificazione del sentiment su IMDB dopo un fine-tuning di 3 epoche. Sembra robusto. Non lo è.
C'è una vulnerabilità strutturale che la ricerca sull'adversarial ML sfrutta da anni: i modelli imparano pattern dai dati di training, non il significato.
Un'illustrazione semplice. Prendi un testo di 10 parole dove ogni parola ha almeno 2 sinonimi. I sinonimi sono semanticamente equivalenti. Puoi sostituirli liberamente senza cambiare il significato della frase. Ottieni 3^10 - 1 = 59.048 versioni semanticamente equivalenti del testo originale. Il modello è stato addestrato su un corpus enorme. Quasi certamente non su tutte le 59.048 varianti.
Alcune parole sono abbastanza frequenti da essere ben rappresentate. I loro sinonimi potrebbero non esserlo. Una parola e il suo sinonimo possono finire in regioni completamente diverse della rappresentazione interna del modello. Anche se significano la stessa cosa.
Questo è il problema centrale: l'equivalenza semantica non garantisce l'equivalenza del classificatore. La domanda è come trovare la sostituzione giusta in modo efficiente, automatico, e senza trasformare il testo in qualcosa che nessuno scriverebbe mai.
L'evoluzione come strategia d'attacco</h2>
È qui che entrano in gioco gli algoritmi genetici.
Gli algoritmi genetici sono metodi di ricerca ispirati all'evoluzione biologica. Si mantiene una popolazione di soluzioni candidate (chiamate cromosomi), ognuna valutata rispetto a una fitness function, e si itera attraverso due operazioni:

Mutazione: piccole modifiche casuali a un candidato</li>
Crossover: combinazione delle caratteristiche di due candidati genitori</li> </ul>
Nel corso delle generazioni, la popolazione converge verso soluzioni migliori. In questo caso, testi che preservano il significato ma invertono la classificazione del modello da positivo a negativo (o viceversa).
Il nucleo della mia implementazione opera sui bigrammi: coppie di parole adiacenti, non token individuali. È una scelta deliberata. I bigrammi esplorano lo spazio di ricerca più velocemente delle sostituzioni a singolo token e riflettono meglio come cambia realmente il linguaggio: il contesto muta per blocchi, non in parole isolate.
Il vincolo difficile: l'onestà semantica</h2>
Qualsiasi esempio avversario che cambia il significato del testo originale non sta dimostrando una vulnerabilità del modello. Sta solo generando rumore. L'attacco ha senso solo se la perturbazione è genuinamente semanticamente equivalente.
Vocabolario bloccato. Non tutto è eleggibile per la sostituzione. Nomi propri, numeri, punteggiatura e token non riconosciuti sono bloccati. L'attacco opera solo sulle parole di contenuto che possono essere sostituite senza alterare il significato del testo.
Coerenza sintattica e morfologica. Ogni sostituzione candidata passa attraverso il POS-tagging via spaCy. Se la parola originale è un sostantivo plurale, anche la sostituzione deve esserlo. Se è un verbo alla terza persona singolare del presente, il sinonimo viene flesso di conseguenza, usando pyinflect sopra l'analisi morfologica di spaCy. È qui che gli approcci naïf alla sostituzione di sinonimi collassano: ignorano che "gioca" e "giocano" sono sintatticamente distinti anche se sono la stessa parola.
I sinonimi provengono da WordNet: non solo una lista, ma un grafo di relazioni semantiche con archi tipizzati (iperonimia, iponimia, antonimia, implicazione). Conta perché la prossimità nello spazio degli embedding non significa similarità semantica. Word2Vec è famoso per mettere i contrari vicini tra loro. WordNet non ha questo problema.
Verifica della similarità semantica. Dopo ogni mutazione, un modello `paraphrase-MiniLM-L6-v2</code> misura la similarità coseno tra il testo originale e quello perturbato. Scendi sotto la soglia configurata: perturbazione rifiutata. Questo cattura la deriva sottile che si accumula quando si sostituiscono più parole. Sinonimi individualmente validi possono combinarsi in qualcosa di semanticamente sbagliato. Il modello è stato addestrato specificamente su coppie di parafrasi, il che lo rende particolarmente adatto a questo compito.`
`Targeting gerarchico delle frasi. Per gli input multi-frase, l'attacco non sparge modifiche sull'intero documento. Valuta ogni frase per il suo contributo individuale alla probabilità di classificazione, poi concentra le mutazioni prima sulla frase più impattante. Questo è centrale per i numeri di efficienza.`
I risultati</h2> Ho confrontato i risultati con 9 metodi allo stato dell'arte del framework TextAttack: BAE, Checklist, DeepWordBug, Faster Alzantot, Input Reduction, Pruthi, PWWS, TextBugger e TextFooler. Il Global Score composito pondera il tasso di successo dell'attacco (40%), l'efficienza delle query (20%) e la preservazione semantica (40%). Attacco</th> Global Score</th> Tasso di successo</th> Query medie</th></tr></thead> custom (questo lavoro)</td> 97,2</td> 100%</td> 17,9</td></tr> Pruthi</td> 89,8</td> 89,4%</td> 3.242</td></tr> Checklist</td> 86,9</td> 93,8%</td> 260</td></tr> BAE</td> 66,2</td> -</td> 324</td></tr> Faster Alzantot</td> -</td> -</td> 10.677</td></tr> </tbody></table> Il divario di efficienza è il numero che conta di più. Faster Alzantot è anch'esso un algoritmo genetico. Ha bisogno di 10.677 query in media. Questa implementazione ne ha bisogno di 18. La differenza viene da tre cose: selezione gerarchica delle frasi, campionamento casuale dei bigrammi invece di valutare ogni candidato, e stop anticipato nel momento in cui l'etichetta cambia. Il 100% di successo contro un modello con il 93,9% di accuratezza è significativo. La maggior parte degli attacchi pre-ModernBERT mostrava già alti tassi di fallimento contro di esso. La finestra di contesto più ampia di ModernBERT (8.192 token contro i 512 di BERT) e l'architettura migliorata hanno genuinamente aumentato la robustezza. Ha retto contro la maggior parte della competizione. Non ha retto contro questo. Tutto gira su hardware consumer: Ryzen 9 5900x, RTX 3080, 128 GB di RAM. Nessun datacenter, nessun credito API, nessun accesso speciale. Cosa rivela davvero</h2> La lettura ovvia: anche i modelli allo stato dell'arte hanno punti ciechi sfruttabili. È vero, e non è banale. La lettura più profonda: quando un testo e la sua versione avversaria semanticamente equivalente ricevono classificazioni diverse, il modello sta rispondendo alle distribuzioni superficiali di parole apprese dai dati di training. Non al significato. Il contenuto semantico è lo stesso. La predizione non lo è. Questa è una proprietà strutturale, non un bug. E ha conseguenze dirette per qualsiasi deployment NLP in produzione dove un avversario ha un incentivo a invertire una classificazione: Monitoraggio del sentiment per intelligence di mercato o politica</li> Sistemi di moderazione dei contenuti</li> Classificazione di testi medici o legali</li> Sistemi di raccomandazione che si affidano a valutazioni automatiche della qualità del testo</li> </ul> L'attacco funziona in modalità black-box: nessun accesso ai pesi, nessun gradiente, solo accesso alle query. Un endpoint API è sufficiente. L'avversario non ha bisogno di sapere nulla degli interni del modello. Problemi aperti</h2> Due direzioni che vale la pena esplorare. Prima i domini ristretti. Un modello addestrato esclusivamente su testi legali o medici è probabilmente più fragile, non meno. Il vocabolario è più piccolo, i pattern più prevedibili, lo spazio di ricerca adversarial più vincolato. L'attacco richiederebbe probabilmente ancora meno query. Gli LLM sono il problema più difficile. La letteratura sull'adversarial ML si concentra sempre di più lì: jailbreak, prompt injection, agenti dormienti che si attivano solo sotto condizioni trigger specifiche. L'approccio di ricerca evolutiva si generalizza in linea di principio. La sfida pratica è il costo delle query e la natura stocastica dell'output degli LLM, che rende la valutazione della fitness incoerente. Vale la pena esplorarlo. Le difese sono la questione aperta. La risposta ovvia è l'adversarial training: includere esempi avversariali nel training set. Ma l'adversarial training su un metodo di attacco non si generalizza bene ad altri, e l'attacco evolve. La corsa agli armamenti è in corso. Bruce Schneier l'ha detto bene: "Se pensi che la tecnologia possa risolvere i tuoi problemi di sicurezza, non capisci né i problemi né la tecnologia." Un modello con il 93,9% di accuratezza è genuinamente buono. È anche un sistema con vulnerabilità strutturali che possono essere localizzate e sfruttate senza alcun accesso agli interni. Capire quelle vulnerabilità è il prerequisito per costruire sistemi davvero affidabili. Non solo accurati sul test set. L'avversario sa sempre esattamente dove guardare. Costruire la difesa richiede prima capire l'attacco. Ho costruito l'attacco. La difesa è il problema aperto. La tesi completa è disponibile su richiesta. L'implementazione gira su Python 3.9-3.11, costruita su spaCy, WordNet (via NLTK), HuggingFace Transformers, BitsAndBytes e pyinflect. Blocca le dipendenze con Docker: come ha salvato la build Android di un vecchio progetto React Native 2023-01-15T00:00:00+00:00 Sviluppo di pacchetti Laravel Parte 2: Controller, Request e TDD 2022-09-01T00:00:00+00:00 Sviluppo di pacchetti Laravel Parte 1: progettare un pacchetto per la registrazione delle sessioni utente 2022-08-01T00:00:00+00:00 Strategie Data-Driven con Laravel #5: email tracking, hanno letto le tue email? 2022-07-01T00:00:00+00:00 Strategie Data-Driven con Laravel #4: tracciamento della navigazione utente e funnel 2022-06-01T00:00:00+00:00 Strategie Data-Driven con Laravel #3: migliora la UX con heat map e click map 2022-05-01T00:00:00+00:00 Strategie Data-Driven con Laravel #2: configura la registrazione delle sessioni utente 2022-04-01T00:00:00+00:00 Strategie Data-Driven con Laravel #1: configura l'A/B testing nella tua applicazione 2022-03-01T00:00:00+00:00 Difendersi dagli attacchi Ransomware 2021-09-01T00:00:00+00:00 Sicurezza 101 per Java: CWE-22 Path Traversal 2021-08-01T00:00:00+00:00 Combinare debugging in produzione e remoto nelle applicazioni Java 2021-07-01T00:00:00+00:00 Sto imparando l'Ethical Hacking: ecco come sono passato da 0 a 1 2021-06-10T00:00:00+00:00 Vulnerabilità open source nello sviluppo web 2021-05-01T00:00:00+00:00 Le migliori soluzioni di hosting WordPress per la sicurezza nel 2021 2021-04-01T00:00:00+00:00 Come iniziare lo sviluppo di plugin WordPress con Docker: Parte 2, creare una pagina semplice 2021-03-01T00:00:00+00:00 Come iniziare lo sviluppo di plugin WordPress con Docker: Parte 1, Docker e pannello Admin 2021-02-01T00:00:00+00:00 Gatsby.js, GitHub e Cloudflare: costruisci un sito statico con React 2020-09-01T00:00:00+00:00 Machine Learning con PHP usando Support Vector Machine (SVM) tramite ext-svm 2020-06-01T00:00:00+00:00 Configura una Dashboard Admin Laravel con InfyOm in pochi minuti, anche su progetti esistenti 2020-03-01T00:00:00+00:00 Implementa l'autenticazione JWT tra più API con Laravel 2020-01-01T00:00:00+00:00

Un LLM può leggere questo sito?</h2>
La maggior parte degli LLM di frontiera sono già agenti: non ti danno solo una risposta ma possono usare strumenti e svolgere compiti per te. Quindi li ho interrogati tutti, con lo stesso prompt, per vedere se riuscivano a leggere questo sito.</p>

ChatGPT</h3> </picture>
Sembra che ChatGPT ce la faccia.</p>

Claude</h3> </picture>
Anche Claude.</p>

Gemini</h3> </picture>
Pure Gemini.</p>
Proviamo qualcosa di meno "corporate".</p>

Deepseek</h3> </picture>
Anche Deepseek sembra leggere il contenuto.</p>

Allora cosa misurano questi punteggi?</h2>
Scomponiamoli.</p>

API, Auth, MCP & Skill Discovery</h3>
Si potrebbe parlare a lungo di questa sezione. Ma in breve: questo sito non espone API, non ha autenticazione, non ha funzionalità specifiche, quindi è tutto irrilevante per questo scopo.</p>

kalizi.dev

Sull'essere Agent Ready

Ho attaccato un ModernBERT con un algoritmo genetico. Ha funzionato.

Blocca le dipendenze con Docker: come ha salvato la build Android di un vecchio progetto React Native

Sviluppo di pacchetti Laravel Parte 2: Controller, Request e TDD

Sviluppo di pacchetti Laravel Parte 1: progettare un pacchetto per la registrazione delle sessioni utente

Strategie Data-Driven con Laravel #5: email tracking, hanno letto le tue email?

Strategie Data-Driven con Laravel #4: tracciamento della navigazione utente e funnel

Strategie Data-Driven con Laravel #3: migliora la UX con heat map e click map

Strategie Data-Driven con Laravel #2: configura la registrazione delle sessioni utente

Strategie Data-Driven con Laravel #1: configura l'A/B testing nella tua applicazione

Difendersi dagli attacchi Ransomware

Sicurezza 101 per Java: CWE-22 Path Traversal

Combinare debugging in produzione e remoto nelle applicazioni Java

Sto imparando l'Ethical Hacking: ecco come sono passato da 0 a 1

Vulnerabilità open source nello sviluppo web

Le migliori soluzioni di hosting WordPress per la sicurezza nel 2021

Come iniziare lo sviluppo di plugin WordPress con Docker: Parte 2, creare una pagina semplice

Come iniziare lo sviluppo di plugin WordPress con Docker: Parte 1, Docker e pannello Admin

Gatsby.js, GitHub e Cloudflare: costruisci un sito statico con React

Machine Learning con PHP usando Support Vector Machine (SVM) tramite ext-svm

Configura una Dashboard Admin Laravel con InfyOm in pochi minuti, anche su progetti esistenti

Implementa l'autenticazione JWT tra più API con Laravel

Attacco</th>	Global Score</th>	Tasso di successo</th>	Query medie</th></tr></thead>
custom (questo lavoro)</strong></td>	97,2</strong></td>	100%</strong></td>	17,9</strong></td></tr>
Pruthi</td>	89,8</td>	89,4%</td>	3.242</td></tr>
Checklist</td>	86,9</td>	93,8%</td>	260</td></tr>
BAE</td>	66,2</td>	-</td>	324</td></tr>
Faster Alzantot</td>	-</td>	-</td>	10.677</td></tr> </tbody></table> Il divario di efficienza è il numero che conta di più. Faster Alzantot è anch'esso un algoritmo genetico. Ha bisogno di 10.677 query in media. Questa implementazione ne ha bisogno di 18. La differenza viene da tre cose: selezione gerarchica delle frasi, campionamento casuale dei bigrammi invece di valutare ogni candidato, e stop anticipato nel momento in cui l'etichetta cambia.</p> Il 100% di successo contro un modello con il 93,9% di accuratezza è significativo. La maggior parte degli attacchi pre-ModernBERT mostrava già alti tassi di fallimento contro di esso. La finestra di contesto più ampia di ModernBERT (8.192 token contro i 512 di BERT) e l'architettura migliorata hanno genuinamente aumentato la robustezza. Ha retto contro la maggior parte della competizione. Non ha retto contro questo.</p> Tutto gira su hardware consumer: Ryzen 9 5900x, RTX 3080, 128 GB di RAM. Nessun datacenter, nessun credito API, nessun accesso speciale.</p> Cosa rivela davvero</h2> La lettura ovvia: anche i modelli allo stato dell'arte hanno punti ciechi sfruttabili. È vero, e non è banale.</p> La lettura più profonda: quando un testo e la sua versione avversaria semanticamente equivalente ricevono classificazioni diverse, il modello sta rispondendo alle distribuzioni superficiali di parole apprese dai dati di training. Non al significato. Il contenuto semantico è lo stesso. La predizione non lo è.</p> Questa è una proprietà strutturale, non un bug. E ha conseguenze dirette per qualsiasi deployment NLP in produzione dove un avversario ha un incentivo a invertire una classificazione:</p> Monitoraggio del sentiment per intelligence di mercato o politica</li> Sistemi di moderazione dei contenuti</li> Classificazione di testi medici o legali</li> Sistemi di raccomandazione che si affidano a valutazioni automatiche della qualità del testo</li> </ul> L'attacco funziona in modalità black-box</strong>: nessun accesso ai pesi, nessun gradiente, solo accesso alle query. Un endpoint API è sufficiente. L'avversario non ha bisogno di sapere nulla degli interni del modello.</p> Problemi aperti</h2> Due direzioni che vale la pena esplorare.</p> Prima i domini ristretti. Un modello addestrato esclusivamente su testi legali o medici è probabilmente più fragile, non meno. Il vocabolario è più piccolo, i pattern più prevedibili, lo spazio di ricerca adversarial più vincolato. L'attacco richiederebbe probabilmente ancora meno query.</p> Gli LLM sono il problema più difficile. La letteratura sull'adversarial ML si concentra sempre di più lì: jailbreak, prompt injection, agenti dormienti che si attivano solo sotto condizioni trigger specifiche. L'approccio di ricerca evolutiva si generalizza in linea di principio. La sfida pratica è il costo delle query e la natura stocastica dell'output degli LLM, che rende la valutazione della fitness incoerente. Vale la pena esplorarlo.</p> Le difese sono la questione aperta. La risposta ovvia è l'adversarial training: includere esempi avversariali nel training set. Ma l'adversarial training su un metodo di attacco non si generalizza bene ad altri, e l'attacco evolve. La corsa agli armamenti è in corso.</p> Bruce Schneier l'ha detto bene: "Se pensi che la tecnologia possa risolvere i tuoi problemi di sicurezza, non capisci né i problemi né la tecnologia."</em></p> Un modello con il 93,9% di accuratezza è genuinamente buono. È anche un sistema con vulnerabilità strutturali che possono essere localizzate e sfruttate senza alcun accesso agli interni. Capire quelle vulnerabilità è il prerequisito per costruire sistemi davvero affidabili. Non solo accurati sul test set.</p> L'avversario sa sempre esattamente dove guardare. Costruire la difesa richiede prima capire l'attacco.</p> Ho costruito l'attacco. La difesa è il problema aperto.</p> La tesi completa è disponibile su richiesta. L'implementazione gira su Python 3.9-3.11, costruita su spaCy, WordNet (via NLTK), HuggingFace Transformers, BitsAndBytes e pyinflect.</em></p> Blocca le dipendenze con Docker: come ha salvato la build Android di un vecchio progetto React Native 2023-01-15T00:00:00+00:00 Sviluppo di pacchetti Laravel Parte 2: Controller, Request e TDD 2022-09-01T00:00:00+00:00 Sviluppo di pacchetti Laravel Parte 1: progettare un pacchetto per la registrazione delle sessioni utente 2022-08-01T00:00:00+00:00 Strategie Data-Driven con Laravel #5: email tracking, hanno letto le tue email? 2022-07-01T00:00:00+00:00 Strategie Data-Driven con Laravel #4: tracciamento della navigazione utente e funnel 2022-06-01T00:00:00+00:00 Strategie Data-Driven con Laravel #3: migliora la UX con heat map e click map 2022-05-01T00:00:00+00:00 Strategie Data-Driven con Laravel #2: configura la registrazione delle sessioni utente 2022-04-01T00:00:00+00:00 Strategie Data-Driven con Laravel #1: configura l'A/B testing nella tua applicazione 2022-03-01T00:00:00+00:00 Difendersi dagli attacchi Ransomware 2021-09-01T00:00:00+00:00 Sicurezza 101 per Java: CWE-22 Path Traversal 2021-08-01T00:00:00+00:00 Combinare debugging in produzione e remoto nelle applicazioni Java 2021-07-01T00:00:00+00:00 Sto imparando l'Ethical Hacking: ecco come sono passato da 0 a 1 2021-06-10T00:00:00+00:00 Vulnerabilità open source nello sviluppo web 2021-05-01T00:00:00+00:00 Le migliori soluzioni di hosting WordPress per la sicurezza nel 2021 2021-04-01T00:00:00+00:00 Come iniziare lo sviluppo di plugin WordPress con Docker: Parte 2, creare una pagina semplice 2021-03-01T00:00:00+00:00 Come iniziare lo sviluppo di plugin WordPress con Docker: Parte 1, Docker e pannello Admin 2021-02-01T00:00:00+00:00 Gatsby.js, GitHub e Cloudflare: costruisci un sito statico con React 2020-09-01T00:00:00+00:00 Machine Learning con PHP usando Support Vector Machine (SVM) tramite ext-svm 2020-06-01T00:00:00+00:00 Configura una Dashboard Admin Laravel con InfyOm in pochi minuti, anche su progetti esistenti 2020-03-01T00:00:00+00:00 Implementa l'autenticazione JWT tra più API con Laravel 2020-01-01T00:00:00+00:00

kalizi.dev

Sull'essere Agent Ready

Basic Web Presence</h2> Il punteggio è pesato su 5 sezioni:</p> Discoverability</strong>: 50 (2 su 4)</li> Content</strong>: 0 (0 su 1)</li> Bot Access Control</strong>: 50 (1 su 2)</li> API, Auth, MCP & Skill Discovery</strong>: 0 (0 su 7)</li>

Un LLM può leggere questo sito?</h2> La maggior parte degli LLM di frontiera sono già agenti: non ti danno solo una risposta ma possono usare strumenti e svolgere compiti per te. Quindi li ho interrogati tutti, con lo stesso prompt, per vedere se riuscivano a leggere questo sito.</p>

ChatGPT</h3> </picture> Sembra che ChatGPT ce la faccia.</p>

Claude</h3> </picture> Anche Claude.</p>

Gemini</h3> </picture> Pure Gemini.</p> Proviamo qualcosa di meno "corporate".</p>

Deepseek</h3> </picture> Anche Deepseek sembra leggere il contenuto.</p>

Allora cosa misurano questi punteggi?</h2> Scomponiamoli.</p>

Discoverability</h3> Questo punteggio ha 4 controlli:</p>

API, Auth, MCP & Skill Discovery</h3> Si potrebbe parlare a lungo di questa sezione. Ma in breve: questo sito non espone API, non ha autenticazione, non ha funzionalità specifiche, quindi è tutto irrilevante per questo scopo.</p>

Ho attaccato un ModernBERT con un algoritmo genetico. Ha funzionato.

Blocca le dipendenze con Docker: come ha salvato la build Android di un vecchio progetto React Native

Sviluppo di pacchetti Laravel Parte 2: Controller, Request e TDD

Sviluppo di pacchetti Laravel Parte 1: progettare un pacchetto per la registrazione delle sessioni utente

Strategie Data-Driven con Laravel #5: email tracking, hanno letto le tue email?

Strategie Data-Driven con Laravel #4: tracciamento della navigazione utente e funnel

Strategie Data-Driven con Laravel #3: migliora la UX con heat map e click map

Strategie Data-Driven con Laravel #2: configura la registrazione delle sessioni utente

Strategie Data-Driven con Laravel #1: configura l'A/B testing nella tua applicazione

Difendersi dagli attacchi Ransomware

Sicurezza 101 per Java: CWE-22 Path Traversal

Combinare debugging in produzione e remoto nelle applicazioni Java

Sto imparando l'Ethical Hacking: ecco come sono passato da 0 a 1

Vulnerabilità open source nello sviluppo web

Le migliori soluzioni di hosting WordPress per la sicurezza nel 2021

Come iniziare lo sviluppo di plugin WordPress con Docker: Parte 2, creare una pagina semplice

Come iniziare lo sviluppo di plugin WordPress con Docker: Parte 1, Docker e pannello Admin

Gatsby.js, GitHub e Cloudflare: costruisci un sito statico con React

Machine Learning con PHP usando Support Vector Machine (SVM) tramite ext-svm

Configura una Dashboard Admin Laravel con InfyOm in pochi minuti, anche su progetti esistenti

Implementa l'autenticazione JWT tra più API con Laravel

Un LLM può leggere questo sito?</h2>
La maggior parte degli LLM di frontiera sono già agenti: non ti danno solo una risposta ma possono usare strumenti e svolgere compiti per te. Quindi li ho interrogati tutti, con lo stesso prompt, per vedere se riuscivano a leggere questo sito.</p>

ChatGPT</h3> </picture>
Sembra che ChatGPT ce la faccia.</p>

Claude</h3> </picture>
Anche Claude.</p>

Gemini</h3> </picture>
Pure Gemini.</p>
Proviamo qualcosa di meno "corporate".</p>

Deepseek</h3> </picture>
Anche Deepseek sembra leggere il contenuto.</p>

Allora cosa misurano questi punteggi?</h2>
Scomponiamoli.</p>

API, Auth, MCP & Skill Discovery</h3>
Si potrebbe parlare a lungo di questa sezione. Ma in breve: questo sito non espone API, non ha autenticazione, non ha funzionalità specifiche, quindi è tutto irrilevante per questo scopo.</p>