Points clés à retenir
- Les systèmes d’IA agentique sont des systèmes à état qui fonctionnent en continu, ce qui rend les modèles de récupération traditionnels insuffisants.
- La couche mémoire (bases de données vectorielles et stockage de contexte) constitue une surface d’attaque critique mais insuffisamment surveillée.
- Les workflows de prise de décision en temps réel peuvent être modifiés sans déclencher les alertes de sécurité habituelles.
- Les lacunes en matière d’observabilité dans les interactions entre agents empêchent la plupart des organisations d’avoir une vision complète des risques.
- Une véritable récupération nécessite un enregistrement unifié et synchronisé dans le temps de toutes les couches du système afin de rétablir un état fiable.
Most enterprises entering the agentic AI era are managing resilience with the wrong mental model – and the data backs it up: Seule une entreprise sur cinq dispose d’un modèle abouti pour la gouvernance des agents d’IA autonomes. 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, seulement 17 % des 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.
Le problème relationnel qui relie ces quatre éléments entre eux
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. Le « point aveugle » agentique : pourquoi la résilience de l’IA nécessite un système d’enregistrement 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.
FAQ
Q: Why doesn’t traditional disaster recovery work for agentic AI?
R : Les procédures de restauration traditionnelles partent du principe que les systèmes sont sans état et peuvent être restaurés à partir de sauvegardes « propres ». Les systèmes d’IA agentique conservent leur mémoire, évoluent au fil du temps et reposent sur des interactions à plusieurs niveaux, ce qui rend une simple restauration insuffisante pour rétablir la confiance.
Q : Qu’est-ce qui rend la couche de mémoire de l’IA agentique vulnérable ?
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.
Q : Comment les pirates peuvent-ils exploiter les flux de travail d’exécution dans l’IA agentique ?
R : Les attaquants peuvent influencer les données d’entrée de planification, les invites ou les réponses des outils, ce qui conduit les agents à exécuter des actions malveillantes en utilisant des processus légitimes. Ces actions apparaissent souvent comme normales dans les journaux, ce qui rend leur détection difficile.
Q : Pourquoi l’observabilité constitue-t-elle un défi dans les systèmes multi-agents ?
R : Les systèmes basés sur des agents fonctionnent à la vitesse de la machine et impliquent des interactions continues entre les agents. Les systèmes de journalisation traditionnels ne sont pas conçus pour capturer ni traiter ce niveau d’activité dynamique et à haute fréquence.
Q : Qu’entend-on par « défaillances émergentes » dans les environnements multi-agents ?
R : Les défaillances émergentes surviennent lorsqu’une petite faille au niveau d’un agent ou d’une couche se propage à l’ensemble des agents interconnectés, entraînant des problèmes à grande échelle dont il est difficile de remonter à la source d’origine.
Q : À quoi ressemble une récupération efficace pour une IA agentique ?
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 est vice-président chargé de la gestion de portefeuille chez Commvault.
