I quattro vettori di attacco per cui il tuo framework di sicurezza AI non è predisposto | Blog

Punti di forza

L’IA agentica comporta nuovi rischi per la sicurezza perché pianifica, memorizza e agisce su più sistemi, anziché limitarsi a un singolo ciclo di richiesta-risposta.
I dati di addestramento “avvelenati” possono influenzare in modo impercettibile il comportamento del modello su larga scala, anche quando il modello sembra funzionare normalmente nei test standard.
I database dei vettori compromessi possono influenzare le decisioni degli agenti alterando il contesto su cui si basa il modello, facendo apparire legittimo un comportamento scorretto.
L’identità degli agenti non controllati crea un problema di controllo degli accessi alla velocità delle macchine che i tradizionali sistemi di identità incentrati sull’uomo non sono in grado di gestire.
Le decisioni a cascata basate su uno stato errato possono diffondere errori in più agenti e flussi di lavoro, rendendo molto più difficili il rollback e il ripristino.

The tools, controls, and governance policies most enterprises have in place were designed for systems that answer questions – retrieval tools, copilots, generative assistants. Systems that respond to a prompt and stop. When something went wrong, the failure was discrete. Fix the prompt, adjust the configuration, move on.

Agentic AI doesn’t work that way. These systems plan, remember, and execute across the enterprise without step-by-step human instruction. They maintain state. They coordinate with other agents. They act on production systems – writing to databases, triggering workflows, making decisions at machine speed.

That architectural shift introduces four threat vectors that existing security frameworks were never designed to address. If your AI governance strategy doesn’t account for them, you likely have exposure you probably can’t see.

1. Dati di addestramento contaminati

An AI system is only as trustworthy as the data it was trained on. That statement has always been true. What’s changed is the attack surface.

In agentic AI deployments, training pipelines are larger, more complex, and frequently assembled from multiple sources – internal data, third-party feeds, vendor-provided datasets. Each dependency in that chain is a potential injection point. An adversarial actor who can influence training data – through supply chain compromise, insider access, or contamination of a shared data source – can shape model behavior at scale.

What makes this particularly dangerous is that poisoned models often perform normally on standard benchmarks. The manipulation may be surgical: designed to produce specific outputs in specific contexts while behaving correctly everywhere else.

By the time the effect surfaces in production, the model has been in use for weeks or months, and tracing the contamination back to its source requires exactly the kind of relational data provenance most organizations don’t have.

The question to ask: Can you produce a complete, verifiable record of what data your models were trained on – at a specific point in time?

2. Banche dati vettoriali compromesse

Vector databases are the memory layer of agentic systems. Before an agent acts, it queries a vector store to retrieve relevant context – past interactions, domain knowledge, reference data – that shapes what it does next.

Most security teams aren’t thinking about vector databases the way they think about other sensitive data stores. They should be.

A compromised vector database doesn’t just return wrong answers. It shapes the decisions that follow. Injected embeddings – malicious content inserted into the vector store – can redirect agent behavior in ways that appear completely legitimate from the outside.

An agent asked to approve a transaction retrieves context that subtly reframes the approval criteria. An agent managing customer communications pulls context that steers responses in an attacker’s preferred direction. The action looks correct. The reasoning looks sound. But the underlying context has been manipulated.

This attack vector is particularly hard to detect because it operates below the model layer. Standard model monitoring won’t catch it. The model is behaving exactly as trained – it’s the context it’s reasoning from that’s been corrupted.

The question to ask: Is your vector database treated as a sensitive, governed data asset – with access controls, integrity monitoring, and audit logging comparable to your most critical production databases?

3. Identità degli agenti non governati

In a multi-agent architecture, agents don’t just interact with data – they interact with each other. They spawn subagents, delegate tasks, request outputs, and synthesize results from agents they’ve never been explicitly connected to. To do this, they authenticate, present credentials, and establish trust.

Agent identity is the access control layer for the autonomous enterprise – and it’s a gap that identity security vendors and identity providers (IDPs) don’t close. Their governance frameworks are built for human identity.

Agent identities created within those same rules appear completely legitimate: They were provisioned correctly, they followed policy. The IDP isn’t failing – it simply has no framework for determining whether an agent is acting outside the context it was created for, has been quietly escalated, or is coordinating where it shouldn’t be.

The exposure is qualitatively different from traditional credential compromise. When a human user’s credentials are stolen, the attacker operates within that user’s permissions, at human speed.

When an agent’s identity is compromised, the attacker gains access to the autonomous decision-making layer – the ability to trigger workflows, approve actions, coordinate with other agents, and exfiltrate data at machine speed, at scale, through channels that appear entirely normal.

Identity-layer failures are also among the hardest to detect after the fact. Agent actions taken under a compromised identity don’t look anomalous – they look like legitimate agent behavior. And because they’re generated by a system rather than a human, the volume can be enormous before anyone notices.

Recovery compounds the problem. Most AI recovery playbooks focus on restoring data: training sets, model weights, pipeline configurations. Identity is rarely on the list. A system recovered with clean data but misaligned identity configurations isn’t actually recovered. It’s a clean system with a poisoned access layer.

The question to ask: Is agent identity managed with the same rigor as human identity – with lifecycle management, least-privilege access, and inclusion in recovery playbooks?

4. Decisioni a cascata basate su una situazione errata

The first three attack vectors are discrete. This one is systemic – and in many ways it can be the most difficult to contain.

Multi-agent architectures are designed for coordination. Agents share context, pass outputs to one another, and build on each other’s work. That coordination is what makes them powerful. It’s also what makes failures propagate.

An agent operating on corrupted memory doesn’t fail cleanly. It produces outputs – decisions, actions, data – that other agents consume. Those agents produce their own outputs. By the time the original corruption surfaces as something observable, bad state may have touched dozens of downstream processes, across multiple agents, with no clean rollback path.

This is what makes the context gap so significant. At any given moment, your AI system consists of a model version, a set of training data, an artifact store, a pipeline configuration, and a set of active agent interactions – all of which need to reflect the same operational state to constitute a trustworthy, recoverable system. When they don’t, you don’t just have an error. You have a system that is coherent in pieces and incoherent as a whole.

Point tools can each confirm their own slice. None can confirm the pieces belong together. That’s not a monitoring problem you can solve by adding another tool. It’s a structural gap – and the only way to close it is with a system that captures AI state relationally: what was running, against what data, with what configuration, at what moment.

The question to ask: If your AI infrastructure were compromised today, could you identify exactly what state every component was in before the incident – and prove it?

Cosa significa questo per la vostra strategia di sicurezza

Each of these four vectors requires a different defensive response. But they share a common implication: The governance and resilience frameworks designed for the previous era of AI don’t cover the failure modes of the agentic era.

Securing agentic AI requires extending your framework in three directions:

Più in profondità, nei livelli dei dati e dell’identità che si trovano al di sotto del modello.
Broader, to cover agent-to-agent interactions that existing monitoring doesn’t observe.
Dal punto di vista relazionale, per cogliere non solo lo stato dei singoli componenti, ma anche il modo in cui questi si integrano tra loro in qualsiasi momento.

That last requirement is the one most organizations haven’t yet confronted. And it’s the one that will determine whether, when something goes wrong, you have a recoverable system or a collection of accurate-looking reports describing something that no longer exists.

Read “L’angolo cieco dell’IA agentica: perché la resilienza dell’IA richiede un sistema di registrazione”per scoprire perché è necessario un SOR per garantire la coerenza e l’accuratezza dei tuoi dati di IA.

Domande frequenti

D: Perché i sistemi di IA agentica sono più rischiosi rispetto ai tradizionali strumenti di IA generativa?

A: I sistemi agentici non si limitano a rispondere ai prompt. Gestiscono lo stato, si coordinano con altri agenti e intraprendono azioni negli ambienti di produzione, il che amplia la superficie di attacco ben oltre la semplice manipolazione dei prompt.

D: Perché è così difficile individuare i dati di addestramento contaminati?

A: La manipolazione può essere altamente mirata, influenzando solo situazioni specifiche senza alterare i normali valori di riferimento. Ciò significa che un modello può sembrare funzionante fino a quando il comportamento dannoso non si manifesta nell’uso reale.

D: In che modo un database vettoriale può rappresentare un problema di sicurezza?

A: Un database vettoriale definisce il contesto su cui si basa un agente prima di agire. Se tale contesto viene alterato, l’agente potrebbe prendere decisioni che a prima vista sembrano ragionevoli, ma che in realtà sono influenzate da dati dannosi.

D: Perché l’identità di un agente è diversa dall’identità umana?

A: L’identità di un agente è legata alle azioni autonome, alla delega e all’esecuzione alla velocità di una macchina. La governance tradizionale dell’identità è concepita per le persone, quindi spesso non rileva se un agente stia agendo al di fuori del contesto previsto.

D: Perché la propagazione a cascata di stati anomali rappresenta un problema così grave nei sistemi multi-agente?

A: Quando un agente elabora un output corrotto, l’errore può propagarsi agli agenti e ai flussi di lavoro a valle. Il risultato non è solo una decisione errata, ma una catena di errori concatenati.

D: In che modo le organizzazioni possono migliorare la sicurezza dell’IA?

A: Estendere la governance fino ai livelli dei dati e delle identità, monitorare le interazioni tra agenti e tenere traccia dello stato dell’IA in modo relazionale, per consentire loro di ricostruire ciò che è accaduto durante un incidente.

Michael Thelander è direttore senior del marketing di prodotto presso Commvault.