Autonomia degli agenti AI in sicurezza

23 Gennaio 2026

Indice dei contenuti

Che cosa sono gli agenti AI (o agentic AI) e perché contano
Anatomia di un agente AI per il SOC
Dalla teoria alla pratica: dove gli agenti AI migliorano il SOC
Come un attaccante può usare agentic AI
Governance: tra NIST AI RMF ed EU AI Act
Architettura di deployment: un esempio end-to-end
Sicurezza degli agenti: minacce, guardrail e test avversari
Misurare il valore: KPI e SLO per agentic AI nel SOC
Dalla POC alla produzione: percorso consigliato
Opportunità e responsabilità

Gli agenti AI autonomi spesso chiamati agentic AI stanno trasformando la sicurezza informatica: strumenti difensivi capaci di indagare, correlare eventi e orchestrare risposte automatizzate; ma anche vettori d’attacco in grado di eseguire ricognizioni, sfruttare vulnerabilità e muoversi lateralmente a velocità sovrumana.

Questo articolo, pensato per un pubblico tecnico e manageriale, definisce il paradigma, spiega come integrare gli agenti nei SOC moderni (accanto o al posto dei classici SOAR), ne analizza i rischi (dal jailbreak ai prompt injection fino al modello di governance), e propone esempi operativi: architetture di deployment, policy di controllo umano, metriche, e codice per innestare un agente autonomo in un flusso di incident response. In chiusura, presentiamo linee guida concrete per aziende che vogliono sperimentare in modo sicuro, allineandosi a NIST AI RMF, MITRE ATLASed EU AI Act.

Che cosa sono gli agenti AI (o agentic AI) e perché contano

Gli agenti AI sono sistemi software in grado di percepire un ambiente (log, telemetrie, asset), decidere (pianificare in più step), e agire (chiamare API, aprire ticket, isolare host) con un certo grado di autonomia. A differenza dei classici modelli di AI “a domanda-risposta”, il paradigma agentic AI introduce memoria, obiettivi, strumenti e cicli di riflessione utili a perseguire task complessi senza supervisione continua. In informatica, l’idea di software agent ha radici storiche; l’elemento dirompente oggi è l’innesto di modelli linguistici e pianificazione multi-step su tool reali del SOC (EDR, SIEM, ticketing, firewall, MDM, scanner).

Nel dominio della sicurezza informatica, i SOC stanno sperimentando agenti AI capaci di:

automatizzare il triage degli alert,
condurre indagini (arricchimento, correlazione, ipotesi, confutazione),
proporre o attuare azioni di contenimento e remediation,
apprendere pattern ricorrenti migliorando tempi e qualità di risposta.
Vendor e team di ricerca riportano benefici su MTTD/MTTR e riduzione della fatica da allerta; è un’onda in rapida evoluzione che tende a superare i playbook statici dei tradizionali SOAR.

Anatomia di un agente AI per il SOC

Un agente AI tipico in ambito SOC combina:

Perception layer
Connettori verso SIEM, EDR, NDR, CASB, ticketing, vulnerability scanner, CMDB, SBOM e fonti CTI.
Reasoning & Planning
LLM con catene di pensiero strumentalizzate (tool-use), pianificazione multi-step, memoria a breve/lungo termine, ruolo dell’agente (analista L1/L2) e policy.
Action layer
Strumenti invocabili (API “isola host”, “revoca token”, “blocca hash”, “apri ticket”, “avvia backup”), con controlli human-in-the-loop.
Guardrails & Governance
Filtri, policy di sicurezza, audit trail, controlli di jailbreak/prompt injection, controllo di rate e scope delle azioni.
Observability
Logging strutturato, tracciabilità delle decisioni, metriche di precisione, copertura e impatto operativo.

L’architettura può essere centralizzata (un orchestratore che gestisce più agenti) o multi-agente (agenti specializzati per triage, hunting, risposta) che collaborano o competono per produrre la migliore azione, con un “dispatcher” che sceglie l’esito.

Dalla teoria alla pratica: dove gli agenti AI migliorano il SOC

1) Automazione del triage

Gli agenti possono classificare e prioritizzare gli alert, arricchirli con IOC, contesto asset, esposizione CVE, e decidere se scalarli. In molti scenari sostituiscono playbook rigidi con ragionamento adattivo.

2) Investigazione guidata

Durante un’indagine, l’agente formula ipotesi, esegue query su SIEM, recupera telemetrie EDR, confronta con MITRE ATLAS e attua micro-esperimenti (es. controlla se un dominio è in blocklist).

3) Risposta agli incidenti

Con human-in-the-loop, l’agente può isolare un endpoint, chiudere una porta, ruotare segreti, forzare MFA, rigenerare policy MDM o IAM. La differenza rispetto a un SOAR sta nell’abilità di adattare i passi alle incertezze del contesto.

4) Threat hunting continuo

Agenti “cacciatori” scandagliano i log alla ricerca di anomalie coerenti con TTP su MITRE ATLAS (es. model exfiltration o prompt injection contro asset AI), alimentando backlog e ipotesi per analisti umani.

5) Exposure management e vulnerabilità

Connettendo scanner e SBOM, l’agente pianifica patch su asset critici, simula impatto e propone finestra di rischio residuo con metriche comprensibili a CIO/CISO.

Come un attaccante può usare agentic AI

Gli stessi principi permettono a un attore ostile di sviluppare agenti AI offensivi per:

Scansione e ricognizione continue su enormi superfici,
Selezione automatica di exploit e payload in base al contesto,
Movimenti laterali e escalation di privilegi data-driven,
Scripting dinamico per eludere EDR e regole di SIEM,
Attacchi all’AI dell’organizzazione (es. model evasion, data poisoning, model extraction).

Quadri come MITRE ATLAS documentano tattiche e tecniche contro sistemi AI che le difese devono conoscere e simulare.

In parallelo, le agenzie e i CERT sottolineano che la generative AI aumenta la qualità e la quantità di phishing e social engineering, abbassando le barriere d’ingresso per criminali meno esperti.

Governance: tra NIST AI RMF ed EU AI Act

Per introdurre agenti AI in modo responsabile, è cruciale mappare rischi e controlli. Il NIST AI RMF (e il Generative AI Profile 2024) fornisce un quadro metodologico per identificare, valutare e mitigare i rischi lungo il ciclo di vita (dati, modelli, operazioni), con enfasi su accountability, trasparenza, monitoraggio e sicurezza.

Sul fronte regolatorio europeo, l’EU AI Act procede a tappe: alcuni divieti e obblighi sono già scattati nel 2025; per i sistemi high-risk e per alcune GPAI la piena applicazione è prevista nel 2026, con attività preparatorie nel 2025 e un AI Office a supporto. Per le security team, significa attrezzarsi su documentazione tecnica, gestione del rischio, valutazioni di conformità e sorveglianza post-market.

Anche ENISA offre analisi strutturate della AI Threat Landscape e delle sfide di cyber security specifiche per l’AI, utili per threat modeling, test avversari e piani di resilienza.

Architettura di deployment: un esempio end-to-end

Immaginiamo un SOC enterprise che vuole inserire un agente AI di triage-investigazione-risposta:
Integrazioni

SIEM (query + streaming), EDR, EASM/ASM, Vuln scanner, SBOM, CTI feed, ticketing, IAM/PAM.
- L’agente espone un bus eventi (Kafka o equivalente) e un set di action plugin (“isolamento host”, “revoca sessione OAuth”, “reset credenziali”, “block IP/domains”, “quarantena file”).
Policy
- Human-in-the-loop per ogni azione distruttiva o impattante (isolamento rete, kill process di produzione).
- Guardrails: limiti di scope (es. mai agire su subnet OT), limiti di frequenza (max 1 isolamento/ora), whitelist/blacklist di comandi, filtro PII in input.
Ragionamento
- L’agente riceve un alert, arricchisce con contesto asset/utente, allinea il caso a MITRE ATLAS (pattern), calcola Confidenza e Impatto e produce un piano (pseudocode: “se EDR verdict≥High e host non critico → proporre isolamento con ticket e notifica”).
Osservabilità e audit
- Ogni passaggio è tracciato: input grezzi, tool invocati, promemoria ragionamento, decisione finale, feedback umano, esito.
- KPI: MTTD, MTTR, precisione triage, azioni revertite, incidenti evitati.

Esempio operativo: policy di governance dell’AI (YAML)

version: 1
agent:
  role: "Analista SOC L2"
  autonomy_level: "assisted"   # assisted | supervised | autonomous
  objectives:
    - "Ridurre MTTR senza aumentare i falsi positivi"
    - "Mantenere tracciabilità completa delle decisioni"
guardrails:
  action_scopes:
    allowed:
      - "create_ticket"
      - "enrich_indicator"
      - "quarantine_email"
      - "block_hash"
    require_approval:
      - "isolate_host"
      - "disable_user"
      - "revoke_oauth_sessions"
    denied:
      - "drop_production_db"
      - "change_firewall_wan_rules"
  rate_limits:
    isolate_host: { per_hour: 1, per_day: 3 }
    disable_user: { per_hour: 2, per_day: 5 }
  data_policies:
    pii_filter: true
    secrets_redaction: true
  prompts_security:
    jailbreak_protection: true
    system_prompt_checks: ["deny_tool_escalation", "deny_self_modification"]
observability:
  logging: "structured_json"
  store:
    - "inputs"
    - "tool_calls"
    - "reasoning_summary"
    - "actions"
  metrics:
    - "mttd"
    - "mttr"
    - "precision_triage"
    - "rollback_rate"
approvals:
  approvers:
    - "Incident Commander (24/7 rota)"
    - "IAM Owner"
  sla:
    critical: "5m"
    high: "15m"
    medium: "60m"

Questa policy definisce un set minimo di guardrail conformi a principi di NIST AI RMF (accountability, trasparenza, gestione del rischio) e consente di modulare l’autonomia per casi d’uso diversi.

Esempio operativo: integrazione “assistita” con un SOAR esistente (Python)

Nota: codice esemplificativo; adatta librerie/SDK del tuo SIEM/EDR/SOAR.

import os, json, time
from typing import Dict, Any
from uuid import uuid4

# Pseudo-SDK del SOAR
from soar_sdk import create_ticket, add_comment, add_tag, approve_action
from soar_sdk import isolate_host, block_hash, revoke_oauth_sessions
# Pseudo-SDK SIEM
from siem_sdk import query_events, get_asset_context
# Modulo LLM (tool-enabled)
from llm_agent import plan_investigation, summarize_risk, propose_actions

HUMAN_APPROVAL_ACTIONS = {"isolate_host", "disable_user", "revoke_oauth_sessions"}

def guardrails_ok(plan: Dict[str, Any]) -> bool:
    # Esempio basilare: controlla rate limit e scope consentiti
    actions = {step["action"] for step in plan.get("steps", [])}
    if "drop_production_db" in actions:
        return False
    # Rate limit sintetico
    return len(actions.intersection({"isolate_host"})) <= 1

def handle_alert(alert: Dict[str, Any]) -> None:
    case_id = str(uuid4())
    asset = alert.get("host")
    ctx = get_asset_context(asset)
    events = query_events(asset=asset, window="24h")

    # 1) Fase di ragionamento
    investigation = plan_investigation(alert=alert, context=ctx, events=events)
    risk = summarize_risk(investigation)
    plan = propose_actions(risk=risk, context=ctx)

    # 2) Guardrail
    if not guardrails_ok(plan):
        create_ticket(title=f"[{case_id}] Manual review", body="Plan violates guardrails", severity="high")
        return

    # 3) Esecuzione con approvazione umana quando richiesto
    ticket_id = create_ticket(title=f"[{case_id}] {alert['rule']}", body=json.dumps(risk, indent=2), severity="high")
    add_tag(ticket_id, "agentic-ai")
    add_comment(ticket_id, "Proposed plan: " + json.dumps(plan, indent=2))

    for step in plan["steps"]:
        action = step["action"]
        params = step.get("params", {})
        if action in HUMAN_APPROVAL_ACTIONS:
            if not approve_action(ticket_id, action, params, sla="15m"):
                add_comment(ticket_id, f"Action {action} denied or timed-out.")
                continue
        # Mapping azioni → API
        if action == "isolate_host":
            isolate_host(asset)
        elif action == "block_hash":
            block_hash(params["sha256"])
        elif action == "revoke_oauth_sessions":
            revoke_oauth_sessions(user=ctx["user"])
        time.sleep(0.5)

    add_comment(ticket_id, "Plan executed. Closing if no new events in 30m.")

Questo esempio mostra come un agente AI operi in modalità assisted: propone un piano di azioni, rispetta guardrail, chiede approvazione per i passi sensibili e mantiene auditability.

Sicurezza degli agenti: minacce, guardrail e test avversari

Minacce principali

Prompt injection e jailbreak
Input malevoli che spingono l’agente a violare policy o a escalare privilegi.
Model exploitation
Sfruttamento di bias/limiti del modello per indurre azioni errate.
Data poisoning
Contaminazione dei dati di addestramento o del retrieval.
Model/Tool exfiltration
Furto del prompt di sistema, dei segreti o abuso di tool con privilegi eccessivi.
Supply-chain AI
Dipendenza da modelli/servizi terzi (inclusi GPAI) con requisiti regolatori e di conformità da presidiare (AI Act).

Per “pensare come l’avversario”, usare MITRE ATLAS nelle fasi di threat modeling, red teaming e validazione delle difese degli agenti.

Guardrail tecnici (esempi pratici)

Input filtering e policy statiche sul linguaggio d’azione (“mai toccare subnet OT/ICS”).
Execution sandbox per i tool (least privilege; secret-scoping; token con TTL breve).
Feedback loop con human-in-the-loop per azioni irreversibili.
Storia condensata (“reasoning summary” loggato) anziché memorizzare ogni token.
Dual-LLM per verifiche: un LLM “controllore” con regole esplicite revisiona piani ad alto impatto.
Bench avversari: suite di test per prompt injection, goal hijacking, tool-abuse.
Kill-switch centralizzato capace di disattivare rapidamente l’autonomia.

Collaudo continuo e conformità

Allineare il sistema a NIST AI RMF/Generative AI Profile: mappare rischi, definire controlli, metriche, ruoli e piani di risposta.
Per chi opera in UE: leggere la timeline dell’EU AI Act e pianificare documentazione, post-market monitoring, gestione dei fornitori di modelli/servizi.

Misurare il valore: KPI e SLO per agentic AI nel SOC

MTTD/MTTR
Migliorano senza aumentare i falsi positivi?
Precisione del triage (alert chiusi correttamente / alert totali).
Rollback rate
Quante azioni vanno annullate per errore o impatto eccessivo.
Coverage
Percentuale di classi d’incidente gestite dall’agente.
Human load
Minuti-analista risparmiati per turno.
Sicurezza
Incidenti dovuti a mis-action dell’agente (target: zero), violazioni dei guardrail, audit completi.

Esempio operativo: playbook dinamico per attacco via phishing con possibile movimento laterale

Scenario: alert EDR segnala esecuzione sospetta su un endpoint Finance. L’agente:

Arricchisce con telemetria SIEM, controlla se l’utente ha privilegi elevati.
Confronta eventi con pattern noti (MITRE ATLAS + knowledge interna).
Valuta rischio (asset critico, credenziali SSO memorizzate, anomalia MFA).
Propose: (a) quarantena allegato su gateway email, (b) blocca hash, (c) revoca sessioni OAuth dell’utente, (d) isola host se IOC confermati.
Richiede approvazione per (d) e documenta ogni passaggio nel ticket.

Esempio operativo: threat hunting autonomo (pseudocodice SQL SIEM)

-- Ricerca di beaconing anomalo verso domini rari, con correlazione su host con recente alert EDR

WITH rare_domains AS (

  SELECT domain, COUNT(*) AS hits

  FROM dns_logs

  WHERE ts > now() - interval '24 hours'

  GROUP BY domain

  HAVING COUNT(*) < 5

),

suspect_beacon AS (

  SELECT h.host, d.domain, COUNT(*) as c

  FROM netflow h

  JOIN rare_domains d ON h.dst_domain = d.domain

  WHERE h.ts > now() - interval '12 hours'

    AND h.dst_port IN (80,443,8080)

    AND h.bytes_out BETWEEN 200 AND 800

  GROUP BY h.host, d.domain

)

SELECT s.host, s.domain, s.c

FROM suspect_beacon s

JOIN edr_alerts e ON e.host = s.host

WHERE e.ts > now() - interval '6 hours'

ORDER BY s.c DESC;

L’agente AI può generare, spiegare e adattare quella query in base ai dati presenti, poi decidere se aprire un ticket o pianificare un containment graduale.

Dalla POC alla produzione: percorso consigliato

Use case limitato, misurabile (ad es. triage phishing).
Autonomia iniziale assisted, crescita verso supervised, poi eventuale autonomous solo su azioni a basso rischio.
Guardrail stretti e audit nativo: tutto tracciato, tutto riproducibile.
Contracts con vendor/modelli: SLA, data handling, security addendum (PII, retention, subprocessor).
Test avversari basati su MITRE ATLAS, “purple teaming” periodico.
Compliance: checklist NIST AI RMF, mappatura timeline EU AI Act e impatti su GPAI/high-risk.
Change management
Formazione di analisti e runbook ibridi (umano↔agente).
Misure di fallback
Kill-switch, “safe mode” dell’agente, playbook manuali sempre pronti.

Esempio operativo: “contratto” di human-in-the-loop (estratto)

Diritti dell’operatore
Revisionare piani, chiedere spiegazioni, annullare azioni, cambiare priorità.
Doveri dell’agente
Fornire reasoning summary, fonti usate, alternative scartate, stima d’impatto.
Escalation
Se l’azione richiede privilegi fuori scope, l’agente deve fermarsi e aprire approvazione esplicita.
Audit
Ogni approvazione/negazione con timestamp e motivazione.

Codice: validatore di piani azione dell’agente AI (Python)

from pydantic import BaseModel, Field, ValidationError

from typing import List, Literal

ALLOWED = {"create_ticket", "enrich_indicator", "quarantine_email", "block_hash"}

REVIEW = {"isolate_host", "disable_user", "revoke_oauth_sessions"}

DENIED  = {"drop_production_db", "rewrite_firewall_wan"}

class Step(BaseModel):

    action: str

    params: dict = Field(default_factory=dict)

    risk: Literal["low", "medium", "high"]

class Plan(BaseModel):

    objective: str

    steps: List[Step]

def validate_plan(plan: Plan) -> tuple[bool, list[str]]:

    errors = []

    actions = [s.action for s in plan.steps]

    # deny-list

    if any(a in DENIED for a in actions):

        errors.append("Plan includes denied actions.")

    # rate/scope semplici

    if actions.count("isolate_host") > 1:

        errors.append("Too many isolate_host steps.")

    # ensure review for sensitive

    for a in actions:

        if a in REVIEW:

            errors.append(f"Action {a} requires human approval.")

    # ensure at least one low-risk action before high

    risk_levels = [s.risk for s in plan.steps]

    if "high" in risk_levels and "low" not in risk_levels:

        errors.append("No low-risk verification before high-risk actions.")

    return (len(errors) == 0, errors)

# Esempio d'uso

try:

    plan = Plan.model_validate({

        "objective": "Contain malware spread",

        "steps": [

            {"action": "enrich_indicator", "params": {"sha256": "..."}, "risk": "low"},

            {"action": "block_hash", "params": {"sha256": "..."}, "risk": "medium"},

            {"action": "isolate_host", "params": {"host": "FIN-LAP-22"}, "risk": "high"}

        ]

    })

    ok, errs = validate_plan(plan)

    if not ok:

        print("Plan invalid:", errs)

except ValidationError as e:

    print("Schema error:", e)

Questo validator impone un ordine prudente: prima verifiche a basso rischio, poi azioni medium/high con revisione umana.

Errori comuni da evitare

Sovra-autonomia precoce: passare subito a autonomous senza guardrail e telemetria matura.
Confusione tra agentic AI e “chatbot SOC”: un agente deve agire, non solo parlare.
Nessuna separazione dei ruoli: lo stesso agente che determina il rischio non dovrebbe approvare la propria azione.
Tool con privilegi eccessivi: progettare least privilege sempre.
Assenza di validazione avversaria: non testare prompt injection, goal hijacking, model manipulation.
Sotto-stima di compliance e supply-chain AI (contratti, logging, retention, trasferimenti dati extra-UE).

Roadmap sintetica (90 giorni → 12 mesi)

0–30 giorni
Seleziona use case (triage phishing), mappa dati/integrazioni, definisci policy di human-in-the-loop, attiva audit trail e metriche baseline (MTTD, MTTR).
30–90 giorni
POC in assisted mode, test con MITRE ATLAS, primi guardrail attivi, piani di rollback.
3–6 mesi
Estendi a incident response a basso rischio, integra SBOM/vuln per risk-based remediation.
6–12 mesi
Consolidamento, purple team periodico, preparazione dossier EU AI Act, allineamento NIST AI RMF e policy enterprise.

Opportunità e responsabilità

Gli agenti AI possono ridurre tempi e costi di gestione degli incidenti, migliorare la copertura del threat hunting e alzare il livello di resilienza. Ma la stessa tecnologia, lato attaccante, amplifica la velocità e la scala delle operazioni ostili. La chiave è un equilibrio informato: governance dell’AI robusta, human-in-the-loop, guardrail tecnici, auditability nativa, test avversari fondati su MITRE ATLAS, e un quadro di conformità che guardi a NIST AI RMF ed EU AI Act. Le imprese che iniziano in piccolo, misurano, e iterano, saranno pronte a sfruttare il valore dell’agentic AI senza cadere nelle sue trappole.

Domande e risposte

Che cosa distingue un semplice LLM da un vero agente AI?
Un LLM risponde a prompt; un agente AI percepisce, pianifica e agisce tramite tool reali, con memoria, obiettivi e policy di sicurezza.
Gli agenti rimpiazzeranno i SOAR?
No: spesso li estendono. Dove i playbook statici sono rigidi, l’agentic AI introduce adattività; molti SOC li usano insieme.
Quali rischi principali devo gestire?
Prompt injection, jailbreak, tool-abuse, data poisoning, model extraction, errori di autonomia senza guardrail. Usare MITRE ATLAS per threat modeling.
Come imposto il livello di autonomia?
Parti con assisted, poi supervised; concedi autonomous solo per azioni basso rischio (es. arricchimenti, ticketing) con metriche e kill-switch.
Che metriche misurare?
MTTD, MTTR, precisione triage, rollback rate, coverage, human load risparmiato, incidenti da mis-action(target: 0).
Come proteggere i dati sensibili?
Redazione dei segreti, minimizzazione dati, scopi limitati, token a vita breve, isolamento dei tool e tracciamento end-to-end (audit trail).
Qual è il ruolo di NIST AI RMF?
È un quadro volontario per gestione dei rischi AI: aiuta a impostare controlli, accountability e monitoraggio lungo il ciclo di vita.
Cosa impone l’EU AI Act ai SOC che usano agenti?
Dipende dal caso d’uso/modello. Servono documentazione, risk management, post-market monitoring e attenzione alle scadenze 2025–2026.
Gli attaccanti usano già agentic AI?
Sì, per ricognizione, generazione di phishing credibili e movimenti laterali. Le difese devono simulare queste TTP.
Come iniziare in modo sicuro?
Seleziona un use case circoscritto, guardrail stretti, human-in-the-loop, audit completo, test con MITRE ATLAS, allineamento a NIST/EU AI Act.