Pontos principais
- A IA agentiva traz novos riscos à segurança, pois planeja, memoriza e age em diversos sistemas, em vez de se limitar a um único ciclo de solicitação-resposta.
- Dados de treinamento contaminados podem influenciar discretamente o comportamento do modelo em grande escala, mesmo quando o modelo ainda parece apresentar um desempenho normal em testes padrão.
- Bancos de dados de vetores comprometidos podem influenciar as decisões dos agentes ao corromper o contexto no qual o modelo se baseia, fazendo com que comportamentos inadequados pareçam legítimos.
- A identidade de agentes não controlados gera um problema de controle de acesso na velocidade das máquinas que os sistemas tradicionais de identidade, centrados no ser humano, não foram projetados para lidar.
- Decisões em cascata baseadas em um estado incorreto podem espalhar a corrupção por vários agentes e fluxos de trabalho, tornando a reversão e a recuperação muito mais difíceis.
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. Dados de treinamento 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. Bancos de dados de vetores comprometidos
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. Identidade do agente não regulamentado
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. Decisões em cascata baseadas em informações incorretas
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?
O que isso significa para sua estratégia de segurança
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:
- Mais a fundo, nas camadas de dados e identidade que se encontram abaixo do modelo.
- Broader, to cover agent-to-agent interactions that existing monitoring doesn’t observe.
- Do ponto de vista relacional, para capturar não apenas o estado de cada componente, mas também como eles se articulam entre si a qualquer 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 O artigo “O ponto cego da IA agentiva: por que a resiliência da IA exige um sistema de registro”” para descobrir por que você precisa de um SOR para ajudar a proteger a consistência e a precisão dos seus dados de IA.
Perguntas frequentes
P: Por que os sistemas de IA com capacidade de ação são mais arriscados do que as ferramentas tradicionais de IA generativa?
R: Os sistemas baseados em agentes fazem mais do que apenas responder a comandos. Eles mantêm o estado, coordenam-se com outros agentes e realizam ações em ambientes de produção, o que amplia a superfície de ataque muito além da simples manipulação de comandos.
P: O que torna os dados de treinamento contaminados tão difíceis de detectar?
R: A manipulação pode ser altamente direcionada, afetando apenas situações específicas e deixando os benchmarks normais intactos. Isso significa que um modelo pode parecer estável até que o comportamento malicioso se manifeste no uso real.
P: Como um banco de dados vetorial pode se tornar um problema de segurança?
R: Um banco de dados vetorial define o contexto que um agente utiliza antes de agir. Se esse contexto for alterado, o agente pode tomar decisões que, à primeira vista, pareçam razoáveis, mas que, na verdade, estejam sendo guiadas por dados maliciosos.
P: Por que a identidade do agente é diferente da identidade humana?
R: A identidade do agente está ligada a ações autônomas, delegação e execução na velocidade de uma máquina. A governança de identidade tradicional foi projetada para pessoas; por isso, muitas vezes não percebe se um agente está agindo fora do contexto pretendido.
P: Por que a propagação de estados indesejáveis é um problema tão grave em sistemas multiagentes?
R: Quando um agente processa uma saída corrompida, esse erro pode se espalhar para os agentes e fluxos de trabalho a jusante. O resultado não é apenas uma decisão errada, mas uma cadeia de falhas interligadas.
P: Como as organizações podem melhorar a segurança da IA?
R: Ampliar a governança para as camadas de dados e identidade, monitorar as interações entre agentes e acompanhar o estado da IA de forma relacional, a fim de permitir a reconstrução do que ocorreu durante um incidente.
Michael Thelander é diretor sênior de marketing de produto na Commvault.
Blogs relacionados
-
- Protegendo a IA com governança unificada do acesso aos dados
- Dados mais inteligentes, IA mais ecológica
- Data Activate: Desbloqueando o potencial dos dados confiáveis para a inovação em IA
- AI Agents Are Everywhere. Do You Know What They’re Doing?
- Da experimentação à operação: criando agentes de IA em quem você pode realmente confiar