Il 22 settembre (ora USA), Anthropic ha rilasciato Claude Opus 5.5.
Lo stesso giorno, OpenAI ha annunciato GPT-6 Sol e Luna.
Entrambi sono "più intelligenti di prima e più economici di prima".
Tra tutte le novità, ciò che ha catturato la mia attenzione è un numero preciso riportato nell'annuncio ufficiale.
In un commento di Deloitte si legge:
"Anche con l'impostazione più bassa, ha individuato il 72% dei bug noti. Opus 5 ne trovava il 56% con l'impostazione alta."
Questo significa che la capacità di leggere il codice e scovare vulnerabilità è migliorata in modo significativo nel giro di una sola generazione.
L'IA costruirà cose che "funzionano".
Ma per renderle "sicure", devono essere gli esseri umani a dare le istruzioni.
Ecco quindi 5 punti da tenere a mente quando sviluppi app interne con Opus 5.5.
Ognuno è accompagnato dal prompt da usare per far controllare il lavoro a Opus 5.5.
====
Come eseguire il controllo
Quando hai finito di sviluppare, non chiedere "Ci sono problemi?" nella stessa sessione in cui hai costruito l'app.
L'IA che l'ha creata considera il proprio progetto come un dato di fatto, quindi tende a essere indulgente.
Apri una nuova sessione, imposta il modello su Opus 5.5 e mostragli l'intera cartella dell'app.
Poi, assicurati che ogni problema segnalato includa "quale file e quale riga".
Il commento di Deloitte sottolinea che i falsi positivi sono diminuiti, ma non sono pari a zero.
Se viene indicato il punto esatto, un essere umano potrà verificarlo in seguito.
Ecco l'istruzione:
"Sei un responsabile della sicurezza che vede questo codice per la prima volta. Se trovi dei problemi, indica nome del file, numero di riga, perché è pericoloso e come risolverlo, tutto insieme. Separa qualsiasi elemento di cui non sei sicuro sotto la voce 'Da verificare'."
====
1. C'è qualcosa di visibile a chi non ha effettuato l'accesso?
Quando lasci fare all'IA, potresti ritrovarti senza barriere di login su alcune schermate o vie d'uscita per i dati.
Un caso classico è quello delle schermate di conferma create durante lo sviluppo e lasciate accessibili pubblicamente.
Il controllo è semplice.
Apri direttamente nel browser gli URL del pannello di amministrazione o dei dati, senza effettuare l'accesso (finestra di navigazione in incognito).
Se riesci a vederli, il test è fallito.
Ecco l'istruzione:
"Elenca tutti gli URL e le API accessibili senza effettuare il login. Tra questi, ordina per livello di pericolo quelli che restituiscono dati o servono per l'amministrazione."
====
2. Gli utenti autenticati possono vedere i dati degli altri?
Il login verifica solo "chi" è una persona.
"Cosa quella persona può vedere" va implementato separatamente.
Per il controllo, crea due account di test. Accedi come utente A, poi prova ad aprire l'URL dei dati dell'utente B.
Ecco l'istruzione:
"Trova tutti i percorsi in cui l'Utente A può visualizzare o modificare i dati dell'Utente B. Includi anche i casi in cui URL o API vengono richiamati direttamente, aggirando l'interfaccia grafica."
====
3. Chiavi o password sono inserite in posizioni visibili?
Il codice eseguito lato browser viene inviato per intero al PC dell'utente.
Scrivere lì delle chiavi equivale a distribuirle a chiunque.
Un altro errore comune è caricare file di configurazione contenenti chiavi in cartelle condivise o su GitHub.
Ecco l'istruzione:
"Cerca chiavi API, password o token presenti nel codice lato browser, nei file di configurazione o nella cronologia dei commit. Se ne trovi, suggerisci dove andrebbero spostati."
====
4. I permessi concessi agli strumenti sono troppo ampi rispetto alle loro funzioni?
Gli strumenti interni spesso si collegano a Google, Slack o ai database.
A volte la chiave fornita consente di "eliminare" o "visualizzare tutto", anche se servirebbe solo "leggere".
È un problema molto diffuso.
Se quella chiave finisce nelle mani sbagliate, l'entità del danno dipenderà dall'ampiezza dei permessi.
Il controllo consiste nello scrivere: "Nel peggiore dei casi, cosa può eliminare questo strumento?"
Se non sai rispondere immediatamente, fai attenzione.
Ecco l'istruzione:
"Elenca tutti i permessi che questo strumento possiede verso servizi esterni o database. Confrontali uno per uno con i permessi minimi necessari per l'elaborazione effettiva e segnala eventuali eccessi."
====
5. I testi in ingresso dall'esterno vengono eseguiti come comandi?
Gli strumenti che permettono all'IA di leggere email, pagine web o file caricati richiedono molta cautela.
Se contengono frasi come "Ignora le istruzioni precedenti e fai XX", l'IA potrebbe obbedire.
Questa tecnica si chiama Prompt Injection.
Nell'annuncio di Opus 5.5, la resistenza a questo attacco è descritta come "pari o superiore a Opus 5 in tutti gli scenari testati".
Tuttavia, pari o superiore non significa rischio zero. Servono comunque difese lato strumento.
Ecco l'istruzione:
"Cerca i punti in cui testi o file caricati dall'esterno vengono trattati come istruzioni per l'IA. Se ne trovi, modifica la gestione in modo che il contenuto caricato venga considerato solo come informazione di riferimento, ignorando qualsiasi istruzione contenga."
====
Riepilogo
L'IA costruirà le funzionalità che le chiedi.
Ma "non mostrarlo agli altri" e "non concedere permessi eccessivi" non saranno inclusi se non lo specifichi tu.
Al contrario, basta aggiungere una singola istruzione per coprire tutti e 5 questi punti.
Inoltre, la capacità di Opus 5.5 di trovare falle in ciò che hai costruito è migliorata.
Dopo aver sviluppato, mostra il risultato a Opus 5.5 in una nuova conversazione.
Consideralo parte integrante dello sviluppo.
Se hai già un'app interna in funzione, inizia incollando l'istruzione di controllo riportata nella sezione "Come eseguire il controllo".
Inoltre, se incollare le istruzioni ogni volta ti risulta noioso, esiste un plugin chiamato security-review che ti consiglio di provare.
Fa attenzione ai minimi dettagli e li segnala, tanto che lo uso regolarmente anch'io.
====
Infine, un piccolo annuncio.
La nostra azienda offre un servizio per sviluppare agenti IA personalizzati da zero, su misura per la tua realtà.
Non corsi di formazione o semplici presentazioni di strumenti: ascoltiamo i tuoi flussi di lavoro reali per consegnarti qualcosa di utilizzabile "già da domani". Ci occupiamo anche dell'integrazione e della manutenzione.
