TL;DR: quando un modello AI può operare su codice, rete e strumenti, verificare chi lo usa riduce gli abusi più semplici, ma non basta. Il controllo decisivo è osservare le azioni durante l’esecuzione e poterle interrompere. Per una PMI la scelta corretta è accesso nominativo come base, monitoraggio continuo come condizione per dare autonomia.

Il 7 agosto 2026 OpenAI ha dichiarato di non poter escludere che Astra, un modello ancora in sviluppo, raggiunga la soglia «Critical» per la cybersecurity. Nel suo Preparedness Framework applicato ad Astra, la soglia indica la capacità di trovare e sviluppare exploit zero-day funzionanti su molti sistemi reali irrobustiti senza intervento umano, oppure di eseguire strategie di attacco nuove partendo da un obiettivo ad alto livello.

È un caso estremo, ma pone una domanda concreta anche a chi usa agenti AI per WordPress, sviluppo web o automazioni: conviene controllare soprattutto chi può usare il sistema, oppure cosa fa il sistema dopo l’accesso?

Il criterio: ridurre il rischio senza bloccare il lavoro

Confronto i due approcci su un criterio operativo: quanto riescono a ridurre azioni non autorizzate lasciando praticabile il lavoro legittimo. Un controllo che ferma ogni scansione o modifica è sicuro solo sulla carta. Un controllo che non vede cosa accade dopo il login, invece, scambia l’identità per una garanzia.

OpenAI sta applicando entrambi. Per Astra cita ambienti isolati, accesso limitato a rete e strumenti, protezione dei pesi, cifratura, sandbox e monitoraggio universale delle azioni rischiose. Ha inoltre sospeso le attività interne che non rispettano i requisiti rafforzati. La combinazione conta più del singolo filtro.

Approccio A: accesso verificato e privilegi minimi

Il primo approccio decide chi entra e con quali permessi. OpenAI lo ha formalizzato con Trusted Access for Cyber: identità verificata per singoli utenti, accesso richiesto dall’azienda per il team e livelli più permissivi per ricercatori selezionati. Le policy e i controlli automatici restano attivi.

Il vantaggio è chiaro: account anonimi, credenziali condivise e utenti fuori ruolo restano lontani dalle capacità più delicate. Per una PMI significa SSO o MFA, account nominativi, service account separati e permessi diversi tra lettura, proposta e scrittura. Un agente che analizza log non deve avere automaticamente il diritto di installare plugin, cambiare DNS o pubblicare su WordPress.

Il limite è altrettanto concreto. Un utente verificato può sbagliare, farsi compromettere l’account o lanciare un workflow legittimo con parametri pericolosi. Anche l’intento è ambiguo: «trova vulnerabilità nel mio codice» può servire a correggere un prodotto o a preparare un attacco. OpenAI usa proprio questo esempio per spiegare perché i soli rifiuti rischiano di ostacolare i difensori senza distinguere bene il contesto.

Approccio B: monitoraggio continuo e interruzione

Il secondo approccio osserva la sessione mentre avviene. Non si limita al prompt: registra tool call, destinazioni di rete, file toccati, comandi eseguiti, volume delle richieste e risultati. Quando una sequenza supera una regola, il sistema chiede approvazione, revoca un permesso o ferma il job.

Su Astra, OpenAI afferma di aver introdotto monitoraggio universale delle azioni rischiose e del disallineamento in tutte le applicazioni agentiche, incluse training e valutazione. I monitor analizzano anche il ragionamento del modello e possono attivare una risposta di sicurezza per rivedere o interrompere l’attività.

Questo approccio vede il rischio reale, compreso quello che emerge dopo un accesso valido. Ma costa: servono log coerenti, soglie, una persona reperibile per gli alert importanti e una procedura di stop. Il rapporto NIST AI 800-4 sul monitoraggio dei sistemi AI segnala problemi pratici come logging frammentato nelle infrastrutture distribuite, difficoltà nel rilevare degrado e drift, e limiti nel far crescere la supervisione umana alla stessa velocità dei rollout.

Pro e contro, senza pareggi diplomatici

L’accesso verificato è economico da capire e semplice da auditare. Riduce la superficie d’attacco prima che l’agente parta. Però protegge male dagli errori interni e dalle credenziali compromesse.

Il monitoraggio continuo intercetta sequenze pericolose e produce prove utili dopo un incidente. Però un alert senza owner e senza kill switch è solo un log più costoso. Inoltre i falsi positivi possono fermare scansioni, deploy o patch urgenti.

Se devo scegliere quale controllo rende governabile un agente con accesso a strumenti reali, scelgo il monitoraggio con interruzione. L’identità dice chi ha avviato il job. La telemetria dice se il job sta ancora facendo ciò che era autorizzato a fare.

Cosa cambia per WordPress e automazioni

Un’azienda non deve replicare l’infrastruttura di un laboratorio frontier. Deve applicare la stessa logica in scala ridotta:

  • separare l’account che legge da quello che pubblica o modifica configurazioni;
  • limitare domini, repository, directory e endpoint raggiungibili dall’agente;
  • richiedere approvazione per update di plugin, scritture nel database, invii email e pubblicazioni;
  • registrare input, tool call, diff e risultato, evitando di salvare secret nei log;
  • impostare rate limit, budget e uno stop automatico quando cambia il perimetro.

Su WordPress, per esempio, una bozza generata via REST dovrebbe usare credenziali dedicate e restare in stato draft. Il passaggio a publish deve dipendere da controlli distinti. È lo stesso principio già utile quando si confrontano regole deterministiche e LLM judge per validare gli output AI: prima vincoli misurabili, poi valutazione contestuale.

La mia take: l’autonomia si concede per azione

Il modello «utente verificato, quindi accesso completo» appartiene al software tradizionale. Un agente può concatenare decine di azioni e cambiare il proprio profilo di rischio durante il task. Per questo l’autonomia va concessa per azione e per ambiente, non una volta sola all’ingresso.

La base minima è accesso nominativo, privilegi ridotti e ambienti separati. Il salto di qualità arriva quando ogni automazione ha telemetria, gate sulle scritture e un interruttore che funziona davvero. Senza questi tre elementi, chiamarla governance è prematuro.

Fonti