Key Takeaways
- Agentic AI introduces new security risks because it plans, remembers, and acts across systems instead of stopping after a single prompt-response cycle.
- Poisoned training data can quietly influence model behavior at scale, even when the model still appears to perform normally in standard testing.
- Compromised vector databases can steer agent decisions by corrupting the context the model relies on, making bad behavior look legitimate.
- Ungoverned agent identity creates a machine-speed access-control problem that traditional human-centric identity systems are not built to handle.
- Cascading decisions built on bad state can spread corruption across multiple agents and workflows, making rollback and recovery much harder.
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. Poisoned Training Data
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. Compromised Vector Databases
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. Ungoverned Agent Identity
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. Cascading Decisions Built on Bad State
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?
What This Means for Your Security Strategy
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:
- Deeper, into the data and identity layers that sit below the model.
- Broader, to cover agent-to-agent interactions that existing monitoring doesn’t observe.
- Relationally, to capture not just the state of individual components, but how they fit together at any point in time.
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 The Agentic Blind Spot: Why AI Resilience Demands a System of Record to learn why you need an SOR to help protect the consistency and accuracy of your AI data.
FAQs
Q: Why are agentic AI systems riskier than traditional generative AI tools?
A: Agentic systems do more than answer prompts. They maintain state, coordinate with other agents, and take actions in production environments, which expands the attack surface far beyond simple prompt manipulation.
Q: What makes poisoned training data so difficult to detect?
A: The manipulation can be highly targeted, affecting only specific situations while leaving normal benchmarks intact. That means a model may look healthy until the poisoned behavior appears in real use.
Q: How can a vector database become a security problem?
A: A vector database shapes the context an agent uses before acting. If that context is altered, the agent may make decisions that seem reasonable on the surface but are really being guided by malicious data.
Q: Why is agent identity different from human identity?
A: Agent identity is tied to autonomous actions, delegation, and machine-speed execution. Traditional identity governance is designed for people, so it often misses whether an agent is acting outside its intended context.
Q: Why is cascading bad state such a serious issue in multi-agent systems?
A: Once one agent consumes corrupted output, that error can spread to downstream agents and workflows. The result is not just one bad decision, but a chain of connected failures.
Q: How can organizations improve AI security?
A: Extend governance deeper into data and identity layers, monitor agent-to-agent interactions, and track AI state relationally to enable them to reconstruct what happened during an incident.
Michael Thelander is Senior Director, Product Marketing, at Commvault.
