Pontos principais
- Os sistemas de IA agênica são sensíveis ao estado e operam continuamente, o que torna os modelos tradicionais de recuperação insuficientes.
- A camada de memória (bancos de dados vetoriais e armazenamento de contexto) é uma superfície de ataque crítica, mas pouco monitorada.
- Os fluxos de trabalho de tomada de decisão em tempo de execução podem ser manipulados sem acionar os alertas de segurança tradicionais.
- As lacunas de observabilidade nas interações entre agentes fazem com que a maioria das organizações tenha uma visibilidade incompleta dos riscos.
- A verdadeira recuperação exige um registro unificado e sincronizado de todas as camadas do sistema para restaurar um estado confiável.
Most enterprises entering the agentic AI era are managing resilience with the wrong mental model – and the data backs it up: apenas 1 em cada 5 empresas possui um modelo maduro para governar agentes de IA autônomos. They’re thinking about AI the way they think about applications: discrete, stateless, recoverable by restoring clean data to a clean environment.
Agentic AI doesn’t work that way. These systems are stateful, continuously operating, and architecturally layered in ways that create failure modes most security and resilience frameworks weren’t designed to address. The gap isn’t in tooling. It’s in understanding what’s actually running – and what “recovery” has to mean for systems built this way.
There are four architectural layers that define the problem. Each one is distinct. Each one is underprotected. And together, they explain why an agentic AI system can appear recoverable while remaining fundamentally compromised.
Layer 1: Agent Memory – The Attack Surface You’re Not Watching
Traditional enterprise applications don’t remember anything between sessions. Agentic AI does. The memory layer – primarily vector databases storing embeddings, but also session state and retrieved context – is what gives agents continuity across interactions. It’s what allows an agent to pick up where it left off, to draw on prior context, to build a coherent picture of a complex workflow over time.
It is also one of the most consequential attack surfaces in the modern enterprise stack – and one of the least monitored.
The attack vector is subtle enough to evade most conventional security tooling. An adversary who can influence what gets written to a vector database can shape what the agent believes to be true. Injected or manipulated embeddings don’t need to look malicious – they need to look authoritative.
A compromised memory store can redirect agent behavior, exfiltrate data through agent actions, or cause an agent to make decisions that appear legitimate but serve an attacker’s objectives. None of this requires touching the model itself.
The detection problem is compounded by the volume and velocity of vector database writes in active agentic deployments. Anomaly detection tools built for structured data don’t translate well to embedding space. The signal is there – but most organizations aren’t equipped to read it.
What resilience requires here: continuous integrity monitoring of vector databases, not just backup. Version-controlled embeddings with a provable chain of custody. The ability to identify, at any point in time, exactly what the memory layer contained – and to restore to a verified clean state, not just a recent one.
Layer 2: Runtime Control – When the Workflow Is the Threat
Agentic AI doesn’t execute fixed scripts. It plans. At runtime, an agent receives a goal, determines the steps required to achieve it, selects the tools it needs, and executes – often spawning subagents to handle parallel workstreams. The workflow is dynamic, constructed in the moment, and frequently long-running.
This is what makes agentic AI genuinely useful. It’s also what makes it genuinely difficult to protect.
In a conventional automation environment, a compromised workflow is bounded. It does what it was configured to do, and it stops. A compromised agentic workflow is different: It adapts.
If an attacker can influence the planning layer – through a poisoned prompt, a manipulated tool response, or a corrupted planning model – the agent will pursue the attacker’s objective using whatever legitimate tools and access it has. It will look like normal operation. The logs, to the extent they exist, will show authorized tool calls.
Consider a procurement agent tasked with validating vendor invoices against contract terms. Under normal operation, it checks invoice amounts, cross-references approval thresholds, and flags exceptions for human review.
An attacker who can influence the planning layer – through a manipulated tool response from the contract database – doesn’t need to touch the approval logic directly. They simply give the agent a contract record with altered thresholds.
The agent plans correctly against corrupted inputs. Every tool call it makes is legitimate. Every decision it reaches is wrong. By the time the anomaly surfaces in a finance reconciliation, the workflow has processed weeks of invoices and the audit trail shows nothing but authorized actions.
The window between compromise and detection in these scenarios is not measured in seconds. Agentic workflows operate continuously. By the time anomalous outcomes surface, the workflow may have touched dozens of systems, made hundreds of decisions, and left changes across production environments that are difficult to enumerate and harder to reverse.
What resilience requires here: runtime monitoring that watches what agents are deciding, not just what they’re doing. Intervention mechanisms that can halt a running workflow cleanly without cascading failures. Recovery playbooks built for long-running agentic processes – not just for discrete transactions.
Layer 3: Agentic Observability – The Logging Gap at Machine Speed
Enterprise logging infrastructure was built for human-scale operations. It captures what systems do, at a granularity and latency designed for human review. Agentic AI operates at a different speed entirely.
In an active multi-agent deployment, agents are spawning subagents, passing context between one another, making tool calls, and synthesizing outputs – continuously, in parallel, faster than conventional logging pipelines were designed to capture.
The interactions that matter most for security – agent-to-agent communications, context handoffs, tool invocations that cross trust boundaries – are exactly the interactions that existing monitoring frameworks leave most underobserved.
Today, apenas 17% continuously monitor agent-to-agent interactions. The other 83% are governing agentic AI based on a partial picture – one that captures what individual agents do in isolation but misses the interaction layer where the most consequential security events occur.
This isn’t a gap that more logging volume solves. The problem isn’t the quantity of data being captured – it’s that the data structures and latency requirements of agentic interactions don’t fit well into observability frameworks designed for slower, more structured systems. Closing this gap requires purpose-built agentic observability tooling, or significant adaptation of existing infrastructure.
What resilience requires here: end-to-end visibility into agent-to-agent interactions, not just individual agent outputs. Logging architectures that can operate at agentic speed without dropping events. The ability to reconstruct, after the fact, the full sequence of agent decisions and interactions for any given workflow.
Layer 4: Multi-Agent Coordination – Where Emergent Failures Hide
The most architecturally novel risk in agentic AI doesn’t come from any single compromised agent. It comes from how agents depend on one another – and how failures propagate across those dependencies before anyone realizes something is wrong.
In a multi-agent architecture, agents share context. An orchestrator agent passes a task brief to a subagent; the subagent returns a result that the orchestrator incorporates into its next decision.
If the subagent’s output is corrupted – through a compromised memory layer, a manipulated tool response, or a poisoned planning model – the orchestrator has no native way to detect it. It treats the output as authoritative. It incorporates it. It acts on it. And it passes its own now-compromised output downstream.
This is the emergent failure mode: a corruption that originates in one layer, propagates through agent interactions, and surfaces as an anomalous outcome in a system several steps removed from the original compromise. By the time it’s visible, the causal chain is long and the blast radius is significant.
Consider a threat intelligence pipeline where a data-gathering agent ingests feeds from external sources, a classification agent categorizes and scores them, and an orchestrator incorporates the scored intelligence into security posture recommendations pushed to downstream teams.
If the data-gathering agent’s memory layer is compromised – subtly, through injected embeddings that cause it to weight certain threat actors as low-risk – the classification agent receives inputs it has no reason to question. It classifies accurately against what it’s given.
The orchestrator incorporates the results confidently. Security teams downstream deprioritize the relevant threat category based on what looks like a coherent, multi-source consensus. The failure originated in Layer 1. It expressed itself in Layer 4. Nothing in between flagged an anomaly because nothing in between had visibility across the full chain.
The governance frameworks most enterprises apply to AI were designed for model outputs – what the AI says. Multi-agent coordination failures are not model output failures. They are systems failures, arising from the interaction layer between models, and they require a different kind of governance: one that monitors and controls not just individual agent behavior but the trust relationships between agents, the integrity of context as it passes between them, and the access rights that govern what any agent can request of any other.
What resilience requires here: agent identity management that treats inter-agent trust as a first-class security concern. Integrity verification for context as it moves across agent boundaries. Governance policies that cover autonomous agent behavior – not just the outputs of individual models.
O problema relacional que une os quatro
These four layers are distinct in their failure modes, but they share a common vulnerability: none of them has a shared record of how they relate to each other at a specific point in time.
The model registry knows what version is running. The vector database knows what’s in memory. The orchestration layer knows what workflow is active. The identity system knows what agents have what access. Each can confirm its own slice of the picture. None can confirm whether those slices belong together – whether they reflect the same operational state, the same moment, the same trustworthy configuration.
That’s the context gap. And it’s why recovery from an agentic AI compromise isn’t a data restoration problem. It’s a coherence problem – one that requires a unified record of the relationships between layers, not just the components themselves.
Close this gap before an incident, or spend an incident trying to close it.
The architecture challenges covered here are only part of what security and resilience leaders need to understand about agentic AI risk. O artigo “O ponto cego da IA agentiva: por que a resiliência da IA exige um sistema de registro” goes further, examining where most enterprises actually stand on AI resilience readiness, what the governance gaps look like in practice, and what it takes to make “our AI is trustworthy” a provable claim, not just an assertion.
Perguntas frequentes
Q: Why doesn’t traditional disaster recovery work for agentic AI?
R: A recuperação tradicional pressupõe que os sistemas não mantêm estado e podem ser restaurados a partir de backups limpos. Os sistemas de IA baseados em agentes retêm memória, evoluem ao longo do tempo e dependem de interações em camadas, o que torna a simples restauração insuficiente para recuperar a confiança.
P: O que torna a camada de memória na IA agentiva vulnerável?
A: The memory layer stores embeddings and contextual data that influence agent decisions. If compromised, attackers can subtly manipulate what the agent “believes,” leading to incorrect but seemingly legitimate actions.
P: Como os invasores podem explorar os fluxos de trabalho em tempo de execução na IA baseada em agentes?
R: Os invasores podem influenciar os dados de planejamento, as instruções ou as respostas das ferramentas, fazendo com que os agentes executem ações prejudiciais por meio de processos legítimos. Essas ações geralmente parecem normais nos registros, o que dificulta a detecção.
P: Por que a observabilidade é um desafio em sistemas multiagentes?
R: Os sistemas baseados em agentes operam na velocidade da máquina, com interações contínuas entre os agentes. Os sistemas tradicionais de registro não foram projetados para capturar ou processar esse nível de atividade dinâmica e de alta frequência.
P: O que são falhas emergentes em ambientes multiagentes?
R: As falhas emergentes ocorrem quando uma pequena vulnerabilidade em um agente ou camada se propaga por agentes interconectados, resultando em problemas em grande escala cuja origem é difícil de identificar.
P: Como seria uma recuperação eficaz para uma IA autônoma?
A: Effective recovery requires more than restoring data – it demands a coherent snapshot of all system layers, including memory, workflows, identities, and interactions, aligned to a verified trustworthy state.
Tim Zonca é vice-presidente de Gestão de Portfólio na Commvault.
