Internet è un universo sconfinato e in continua espansione. A metà 2025 ospita oltre 1,25 miliardi di siti web e ogni anno produce circa 149 zettabyte di dati. Più della metà del traffico arriva ormai da bot, molti dei quali malevoli. In questo scenario, aiutare le organizzazioni a proteggere la propria impronta digitale è più che mai essenziale.
In DoiT abbiamo collaborato con un cliente specializzato in Attack Surface Management (ASM) per capire come l'AI di nuova generazione possa automatizzare e scalare alcune fasi di questo processo. L'obiettivo: un agente capace di navigare il web, analizzare gli asset esposti di un cliente e individuare potenziali vulnerabilità, il tutto su AWS.
La progettazione della soluzione
Abbiamo progettato un sistema basato su Amazon Bedrock e Strands Agents, che mette insieme modelli di reasoning, automazione del browser, retrieval-augmented generation e una observability completa di livello produttivo.
Ecco i principali componenti AWS impiegati:
Ed ecco come si incastrano tra loro:
Approfondiamo ciascuno di questi elementi nelle sezioni seguenti.
Modelli di reasoning e framework dell'agente
Partiamo dalle fondamenta: come "pensa" l'agente. AWS Bedrock dà accesso in modo semplice a modelli di reasoning avanzati come la famiglia Nova di Amazon, i modelli Claude di Anthropic e numerosi modelli open source quali Mistral, DeepSeek o Llama. Questi modelli supportano già il reasoning di tipo chain-of-thought, permettendo all'agente di produrre passaggi intermedi di "ragionamento" prima di trarre conclusioni e passare all'azione. Una capacità essenziale, perché ogni azione di navigazione e ogni osservazione si basa sulla precedente.
Per l'orchestrazione, Strands Agents fornisce un'astrazione elegante del loop dell'agente: un ciclo di reasoning, uso dei tool e generazione della risposta. Si integra senza attriti con i modelli Bedrock e offre primitive di livello produttivo per la gestione dello stato di sessione, il coordinamento multi-agent e la gestione del contesto.
Un breve estratto di codice dell'agente per dare un'idea di quanto Strands semplifichi lo sviluppo:
Questo loop consente all'agente di navigare in autonomia, ragionare sui risultati e mantenere lo stato tra un passaggio e l'altro.
Agire tramite tool e MCP
Il reasoning, da solo, non basta: l'agente deve poter interagire con il mondo esterno.
Abbiamo abilitato il tooling tramite il Model Context Protocol (MCP), uno standard aperto che collega gli LLM a sistemi esterni. Ogni server MCP espone un catalogo di "tool" con definizioni e schemi chiari, che l'agente può richiamare dinamicamente a runtime.
Per il nostro caso d'uso abbiamo combinato tre fonti di tool:
- retrieve: per query semantiche sul database delle vulnerabilità.
- Playwright MCP: per la navigazione web e l'interazione con i siti.
- Filesystem MCP: per uno storage persistente essenziale e per il logging.
Mentre eravamo in fase di sviluppo, ad agosto 2025 AWS ha presentato AgentCore , dotato di un proprio Browser Tool, che elimina la necessità di gestire un'infrastruttura Playwright proprietaria. Offre un ambiente browser completamente gestito e isolato, con integrazione IAM e observability tramite CloudTrail, e si è inserito senza sforzo nel codice esistente:
La modularità di Strands ha reso immediato il passaggio dal tooling browser self-hosted a un servizio gestito più sicuro e scalabile.
Grounding con Bedrock Knowledge Bases
Per consentire all'agente di ragionare su dati reali, lo abbiamo ancorato al database del CVE™ Program , un repository di vulnerabilità note.
Con Amazon Bedrock Knowledge Bases abbiamo caricato il dataset CVE, che AWS ha automaticamente suddiviso in chunk, vettorializzato e indicizzato in OpenSearch Serverless, pronto per essere interrogato.
Il tool retrieve ha quindi permesso all'agente di interrogare questo vector store a runtime, fornendogli informazioni aggiornate sulle vulnerabilità rilevanti per ciascun asset cliente analizzato. La pipeline gestita di ingestion e retrieval di Bedrock Knowledge Bases ci ha fatto risparmiare un notevole sforzo di engineering rispetto alla costruzione da zero di un flusso RAG personalizzato.
Deployment dell'agente su AWS
Validato il prototipo in locale, abbiamo portato la soluzione in produzione utilizzando due runtime gestiti:
1. AWS Fargate
Un deployment containerizzato pacchettizzato con Docker e orchestrato tramite AWS CDK. Questa configurazione garantisce pieno controllo su scaling e networking, ed è ideale quando si desidera maggiore controllo o si hanno dipendenze specifiche (come i server MCP).
2. Amazon Bedrock AgentCore
AgentCore offre un livello di astrazione ancora più alto: si definisce l'agente con la sua configurazione e AWS lo esegue al posto suo.
Con qualche piccolo adattamento al codice, principalmente il passaggio dallo storage su filesystem al sistema di stato di Strands, lo stesso agente è stato eseguito in modalità completamente gestita, senza bisogno di configurare CDK o VPC: è bastato usare agentcore configure e agentcore launch dallo starter kit di Agentcore. Per iterazioni rapide e overhead operativo minimo, questo approccio si è rivelato imbattibile.
Observability e valutazione
Monitorare il comportamento dell'agente è importante quanto progettarlo.
Per i team che preferiscono soluzioni di analytics esterne, LangFuse si integra senza sforzo tramite OpenTelemetry, offrendo una timeline dettagliata di loop, chiamate ai modelli e invocazioni dei tool. Una visione passo-passo di ciò che l'agente sta "pensando" e dei tool che decide di usare: un aspetto cruciale per il debugging e il miglioramento continuo.
Dopo il lancio di AgentCore, è arrivato anche AgentCore Observability, che si integra in modo trasparente con CloudWatch , ora dotato di una GenAI Observability dashboard che raccoglie trace, metriche e log per ogni invocazione. Gli sviluppatori possono visualizzare il consumo di token, i tassi di errore e ispezionare le sessioni, trasformando la black box del reasoning degli LLM in dati misurabili.
Monitori la spesa del suo agente con DoiT Cloud Intelligence
In stretta correlazione con l'observability, anche capire l'impatto sui costi prima del deployment in produzione dovrebbe essere una priorità.
In DoiT abbiamo lanciato GenAI Lens, parte della piattaforma DoiT Cloud Intelligence™, pensata per analizzare i pattern di spesa dei workloads di AI generativa.
Si integra direttamente con Amazon Bedrock, oltre che con Anthropic e OpenAI, mostrando con chiarezza quali modelli e workloads incidono di più sui costi.
Per analisi più approfondite, DataHub permette di integrare l'ingestion dei dati direttamente nella propria applicazione. Grazie a labeling e dashboard personalizzati è possibile tracciare i costi per dominio o per cliente, e perfino calcolare un costo per vulnerabilità individuata, trasformando gli insight di sicurezza in ROI misurabile.
Uno sguardo al futuro
Dall'ingestion dei dati al reasoning fino all'observability, l'ecosistema AWS ha fornito tutti i tasselli per dare vita a questo agente ASM autonomo, in modo sicuro, scalabile e con una gestione minima dell'infrastruttura, soprattutto ora che AgentCore è in GA.
Abbiamo eseguito test su testphp.vulnweb.com, dai quali è emerso che il sistema è in grado di rilevare scenari di SQL Injection, Reflected e Stored XSS, Authentication Bypass e perfino di compromissione attiva del sito. I risultati confermano che l'agente è capace di percorrere autonomamente i flussi web, iniettare payload, interpretare le evidenze di esecuzione e correlare gli esiti con il database CVE, il tutto con una supervisione umana minima. Oltre all'accuratezza tecnica, il progetto ha dimostrato il valore di unire reasoning autonomo, retrieval in tempo reale e observability, trasformando scansioni grezze di vulnerabilità in intelligence strutturata e spiegabile.
Gli sviluppi possibili sono ancora molti: affinare le capacità di reporting, misurare le performance su benchmark riconosciuti e integrare ulteriori database di vulnerabilità. Ma già nella sua forma attuale, il progetto mostra come AWS Bedrock + Strands Agents possano tradurre la promessa dell'AI generativa in valore operativo concreto per la cybersecurity.
Tutto il codice sorgente e i dettagli implementativi sono disponibili su GitHub; una versione più estesa è consultabile qui.
—
Semplifichi il suo percorso FinOps insieme a noi: ci contatti su doit.com/services!