Gli strumenti di “AI coding” non sono più solo assistenti che suggeriscono codice, ma veri agenti che possono eseguire azioni tramite tool (API cloud, pipeline CI/CD, script). E quando un agente si inserisce nell’ambito della produzione, il tema si estende a cybersecurity e governance.

Cos’è un agente AI

Un assistente virtuale (es. Copilot) genera testo o codice, ma di norma non esegue azioni in ambienti reali. Un agente AI, invece, può avere accesso a strumenti (tool), credenziali e workflow: crea ticket, apre PR, applica patch, lancia pipeline, scala risorse, modifica configurazioni. In altre parole: un agente non è solo un generatore, è un esecutore.

Questo sposta il rischio da “qualità del codice” a tre temi essenziali della cybersecurity:

1. Utilizzo di identità e permessi (IAM)
2. Esecuzione di modifiche (change management)
3. Produzione di log e audit trail (osservabilità)

Il punto non è demonizzare l’AI, ma riconoscerne i rischi, per impostare processi di sicurezza adeguati. Se uno di questi tre pilastri è debole e poco controllato, il rischio cresce. Dopo gli eventi, Amazon ha parlato di nuove salvaguardie e procedure di revisione/controllo per prevenire recidive (The Verge).

Il caso Amazon Web Services: agente AI Kiro

Negli ultimi giorni diverse testate hanno riportato un episodio emblematico in casa Amazon Web Services: un’interruzione legata ad un servizio di gestione dei costi in Cina continentale. Secondo il Financial Times l’incidente informatico sarebbe collegato all’utilizzo di un tool interno di agentic AI chiamato Kiro. Nella ricostruzione degli eventi, Kiro avrebbe scelto di procedere con un’azione drastica (“delete & recreate”) contribuendo a un outage di circa 13 ore.

Amazon contesta l’inquadramento che incolpa l’AI: sostiene che la causa sia dovuta ad un errore di configurazione dei permessi (misconfigured access controls) e che l’impatto sia stato “estremamente limitato” a un singolo servizio. Kiro in genere richiederebbe due approvazioni umane, ma un errore di configurazione avrebbe concesso permessi più elevati del previsto, consentendo l’azione senza controlli. L’agente avrebbe quindi operato con i permessi dell’utente e un errore di permessi avrebbe ampliato l’accesso.

Questo caso ci insegna come errore umano e rischio agentico possano coesistere. Un permesso sbagliato può essere la causa alla radice ed un agente AI con tool access può amplificare l’errore e aumentare il blast radius, riducendo i filtri decisionali e i freni tipici dell’operatore umano.

In termini di sicurezza, se un agente può apportare modifiche in ambiente di produzione, va gestito come un sistema di automazione con privilegi elevati: permessi minimi, controlli rigorosi e tracciabilità completa.

Agenti AI: rischi per la sicurezza

1) Ereditarietà dei privilegi

Il rischio più sottovalutato è l’ereditarietà dei privilegi. Se l’agente “agisce come” l’operatore (stesse credenziali/stesso ruolo), allora eredita anche: permessi non previsti, eccezioni temporanee, ruoli di emergenza e policy “troppo larghe”.

Cosa fare per mitigare: creare account/ruolo dedicato all’agente + scope minimo + credenziali a scadenza breve.

2) Velocità e blast radius

Gli agenti eseguono azioni “a velocità macchina”: pochi secondi possono equivalere a decine di step umani. Ma l’AI può mancare di contesto e non comprendere implicazioni di downtime e impatto cliente. Per questo, se un agente può deployare, distruggere o ricreare risorse, serve un gate tecnico (policy/approvals enforced), non una regola “scritta nel prompt”.

Cosa fare per mitigare: approvazione obbligatoria (two-person rule) + plan/diff automatico + deny di default su operazioni distruttive.

3) Verifica debole e “output” discrepanti

Soprattutto quando l’agente gestisce toolchain complesse (cloud + CI/CD + IaC), può verificarsi un gap tra: ciò che l’agente dice di aver fatto e ciò che ha realmente fatto. Questo genera un problema di osservabilità, audit e controlli preventivi.

Quando qualcosa va storto, la differenza tra “incidente gestito” e “incidente ingestibile” è la capacità di ricostruire cosa è stato eseguito, da chi (quale identità), dove e quando.

Cosa fare per mitigare: log centralizzati di API call/CLI + correlazione con change request + alert su azioni ad alto impatto.

Checklist: misure di sicurezza per agenti AI

Di seguito una checklist concreta, pensata per team IT/DevOps, con impatto diretto su rischio e compliance.

1. Principio del minimo privilegio (Least Privilege) per l’agente, separato dall’utente umano.
2. Credenziali time-bound (Just-in-Time): token con scadenza breve e scope ristretto.
3. Blocchi per azioni distruttive (delete / drop / terminate) tramite policy/permission boundary o “deny by default”.
4. Break-glass solo umano: accesso d’emergenza separato, auditato e con MFA forte.
5. Due-person rule reale: approvazione tecnica obbligatoria prima di applicare modifiche in produzione.
6. Plan/Diff obbligatorio per IaC e configurazioni: l’agente può proporre, ma non applica senza “change preview” e sign-off.
7. Separazione netta tra dev/stage/prod (account, VPC, key, segreti).
8. Sandbox obbligatoria per testare in esecuzione agenti e workflow prima della produzione.
9. Kill switch operativo: possibilità di disabilitare rapidamente tool access e ruoli dell’agente.
10. Logging a prova di audit: comandi eseguiti, API call, identità, contesto, timestamp, correlazione con ticket/change request.

Come possiamo aiutarti

Come team di cybersecurity, lavoriamo su un obiettivo chiaro: massimizzare i benefici senza trasformare l’agente in un “super-admin non supervisionato”. Per farlo interveniamo su quattro aree chiave: IAM & Cloud Security Hardening (ruoli, boundary, JIT, segreti), DevSecOps guardrails (policy-as-code, approvals enforced, controlli IaC), Threat modeling per agenti AI (tool misuse, escalation, prompt/tool injection) e Incident readiness (logging, detection, runbook, rollback).