Los cuatro vectores de ataque para los que tu marco de seguridad de IA no está preparado | Blog

Puntos Clave

La IA agentiva plantea nuevos riesgos de seguridad porque planifica, recuerda y actúa en distintos sistemas, en lugar de limitarse a un único ciclo de pregunta-respuesta.
Los datos de entrenamiento «envenenados» pueden influir de forma imperceptible en el comportamiento del modelo a gran escala, incluso cuando el modelo parece seguir funcionando con normalidad en las pruebas estándar.
Las bases de datos de vectores comprometidas pueden influir en las decisiones de los agentes al alterar el contexto en el que se basa el modelo, haciendo que un comportamiento incorrecto parezca legítimo.
La identidad de los agentes no controlados plantea un problema de control de acceso a la velocidad de las máquinas que los sistemas de identidad tradicionales, centrados en las personas, no están diseñados para gestionar.
Las decisiones en cadena basadas en un estado erróneo pueden propagar errores por varios agentes y flujos de trabajo, lo que complica mucho más la reversión y la recuperación.

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. Datos de entrenamiento contaminados

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. Bases de datos vectoriales comprometidas

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. Identidad de agente no regulado

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. Decisiones en cadena basadas en una situación errónea

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?

Qué significa esto para tu estrategia de seguridad

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:

Más a fondo, en las capas de datos e identidad que se encuentran debajo del modelo.
Broader, to cover agent-to-agent interactions that existing monitoring doesn’t observe.
Desde el punto de vista relacional, para reflejar no solo el estado de cada componente, sino también cómo encajan entre sí en cualquier momento dado.

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 «El punto ciego agencial: por qué la resiliencia de la IA exige un sistema de registro» para descubrir por qué necesitas un SOR que te ayude a proteger la coherencia y la precisión de tus datos de IA.

Preguntas frecuentes

P: ¿Por qué los sistemas de IA con capacidad de acción son más arriesgados que las herramientas tradicionales de IA generativa?

R: Los sistemas basados en agentes hacen mucho más que responder a indicaciones. Mantienen el estado, se coordinan con otros agentes y llevan a cabo acciones en entornos de producción, lo que amplía la superficie de ataque mucho más allá de la simple manipulación de indicaciones.

P: ¿Por qué es tan difícil detectar los datos de entrenamiento «envenenados»?

R: La manipulación puede ser muy selectiva, afectando solo a situaciones concretas y dejando intactos los puntos de referencia normales. Eso significa que un modelo puede parecer que funciona bien hasta que el comportamiento malicioso se manifiesta en el uso real.

P: ¿Cómo puede una base de datos vectorial convertirse en un problema de seguridad?

R: Una base de datos vectorial define el contexto que utiliza un agente antes de actuar. Si ese contexto se altera, el agente puede tomar decisiones que, a primera vista, parezcan razonables, pero que en realidad están guiadas por datos maliciosos.

P: ¿Por qué la identidad de un agente es diferente de la identidad de una persona?

R: La identidad de un agente está ligada a las acciones autónomas, la delegación y la ejecución a la velocidad de una máquina. La gestión tradicional de identidades está pensada para las personas, por lo que a menudo no detecta si un agente está actuando fuera del contexto previsto.

P: ¿Por qué la propagación en cascada de estados erróneos es un problema tan grave en los sistemas multiagente?

R: En cuanto un agente procesa datos erróneos, ese error puede propagarse a los agentes y flujos de trabajo posteriores. El resultado no es solo una mala decisión, sino una cadena de fallos encadenados.

P: ¿Cómo pueden las organizaciones mejorar la seguridad de la IA?

R: Ampliar la gobernanza hasta las capas de datos e identidad, supervisar las interacciones entre agentes y realizar un seguimiento relacional del estado de la IA para que puedan reconstruir lo que ocurrió durante un incidente.

Michael Thelander es director sénior de marketing de producto en Commvault.