Die wichtigsten Erkenntnisse
- Agentische KI-Systeme sind zustandsbehaftet und arbeiten kontinuierlich, weshalb herkömmliche Wiederherstellungsmodelle nicht ausreichen.
- Die Speicherebene (Vektordatenbanken und Kontextspeicher) ist eine kritische, aber nur unzureichend überwachte Angriffsfläche.
- Workflows zur Entscheidungsfindung zur Laufzeit können angepasst werden, ohne dass dabei herkömmliche Sicherheitswarnungen ausgelöst werden.
- Aufgrund von Lücken in der Beobachtbarkeit bei Interaktionen zwischen Agenten haben die meisten Unternehmen nur einen unvollständigen Überblick über die Risiken.
- Eine echte Wiederherstellung erfordert eine einheitliche, zeitlich abgestimmte Aufzeichnung aller Systemebenen, um einen vertrauenswürdigen Zustand wiederherzustellen.
Most enterprises entering the agentic AI era are managing resilience with the wrong mental model – and the data backs it up: Nur jedes fünfte Unternehmen verfügt über ein ausgereiftes Modell zur Steuerung autonomer KI-Agenten. 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, nur 17 % der Unternehmen 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.
Das Beziehungsproblem, das alle vier miteinander verbindet
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. „The Agentic Blind Spot: Why AI Resilience Demands a System of Record“ 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.
FAQs
Q: Why doesn’t traditional disaster recovery work for agentic AI?
A: Bei der herkömmlichen Wiederherstellung wird davon ausgegangen, dass Systeme zustandslos sind und anhand sauberer Backups wiederhergestellt werden können. Agentische KI-Systeme behalten ihr Gedächtnis, entwickeln sich im Laufe der Zeit weiter und basieren auf vielschichtigen Interaktionen, sodass eine einfache Wiederherstellung nicht ausreicht, um das Vertrauen wiederherzustellen.
F: Was macht die Gedächtnisschicht in der agentenbasierten KI anfällig?
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.
F: Wie können Angreifer Laufzeit-Workflows in agentenbasierter KI ausnutzen?
A: Angreifer können Planungsdaten, Eingabeaufforderungen oder Tool-Antworten manipulieren, wodurch Agenten dazu veranlasst werden, mithilfe legitimer Prozesse schädliche Aktionen auszuführen. Diese Aktionen erscheinen in den Protokollen oft als normal, was ihre Erkennung erschwert.
F: Warum stellt die Beobachtbarkeit in Multi-Agenten-Systemen eine Herausforderung dar?
A: Agentenbasierte Systeme arbeiten mit Maschinen-Geschwindigkeit und zeichnen sich durch kontinuierliche Interaktionen zwischen den Agenten aus. Herkömmliche Protokollierungssysteme sind nicht dafür ausgelegt, diese Art von dynamischer, hochfrequenter Aktivität zu erfassen oder zu verarbeiten.
F: Was sind emergente Fehler in Multi-Agenten-Umgebungen?
A: Emergent-Ausfälle treten auf, wenn sich eine kleine Beeinträchtigung in einem Agenten oder einer Schicht auf miteinander verbundene Agenten ausbreitet, was zu großflächigen Problemen führt, deren ursprüngliche Ursache sich nur schwer zurückverfolgen lässt.
F: Wie sieht eine effektive Wiederherstellung bei einer agentischen KI aus?
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 ist Vizepräsident für das Portfoliomanagement bei Commvault.
