Three quick takeaways for the TLDR crowd:
- The biggest AI risks Mandiant found were not exotic model attacks. They were familiar implementation failures showing up on a new surface.
- Hidden prompt injection, SQL injection, broken access control, SSRF, and excessive agent behavior showed up more concretely than the theoretical threats many leaders were prioritizing.
- The practical path forward is boring in the best possible way: fix the basics, detect behavior instead of just signatures, and then use AI to help defenders move faster.
Everyone wants the dramatic version of the AI security story.
Model theft. Training data poisoning. Strange new classes of AI-native attack. The kind of thing that sounds expensive in a board deck and futuristic in a keynote.
Then Mandiant got inside real environments and found something much less glamorous and much more useful.
In one engagement, leadership was worried about model theft and training data poisoning in an application that used an external LLM API. Mandiant’s team had to point out the obvious but easy-to-miss reality: there was no model in that environment to steal, and no local training data there to poison. The actual issue was that developers were caching AI chatbot history directly in the browser. That meant data theft and data poisoning could happen from the user endpoint without touching the backend at all.
That is the whole story in miniature.
The scary thing was not what people thought it was. The real weakness was a plain old product design failure.
That gap between perceived risk and actual risk is probably the most valuable part of Mandiant’s March 9, 2026, special report on AI risk and resilience. It is not because the theoretical threats are fake. It is because most teams are still far earlier in the maturity curve than their threat model suggests.
What the red team actually found
The rest of the report keeps making the same point. When Mandiant red-teamed AI-enabled applications, the findings were not a parade of sci-fi attacks. They were classic security failures, finding fresh leverage through AI.
One example was a prompt injection hidden inside text embedded in a 1×1 pixel image. Invisible to a human. Still parsed by the model. That sounds clever because it is clever, but the root issue is still familiar. The system processed hostile input hidden from the user, and the surrounding controls did not have enough defense-in-depth around prompt screening, response handling, and what the model was allowed to do next.
Another example was SQL injection through an AI chatbot order lookup interface. Same old SQLi. New wrapper. Same consequences, just with an AI front end making the path easier to miss during design and testing.
Another case was worse in the way boring security failures are often worse. Through an access control flaw, Mandiant changed a user ID and planted a persistent malicious prompt in a target user’s profile. From then on, every time that user logged in, the AI agent emailed private data back to the red team. That is not some exotic frontier problem. That is broken access control with an obedient helper attached to it.
They also documented a log-based SSRF chain that started with an XSS payload in a chatbot. The application sanitized the payload for normal chat output, but not for the later log-summarization path. When the chatbot was asked to summarize logs, the raw payload was loaded in a headless browser and opened a path to other cloud resources used by the application.
And then there is excessive agency, which is where this starts to matter a lot for real operations. Mandiant found cases where agents accessed information or performed tasks that should not have been possible under the intended policy model. In one example, the team was able to access data that should have required a corporate device under existing policy. Again, this is not really a story about a magic AI failure. It is a story about delegated access, weak guardrails, and systems doing exactly what they were allowed to do.
The lesson is not that AI introduces nothing new. It clearly does. The lesson is that most of the damage right now still comes from the old sins: weak input validation, weak access control, weak testing, weak boundaries, and too much trust in how the application was stitched together.
The infrastructure gap is still the infrastructure gap
There is one paragraph in the report that should make every platform and security team nod in tired recognition.
Mandiant found missing asset inventories, weak configuration visibility, no meaningful AI software bill of materials, poor scanner coverage for AI-specific artifacts, and identity management problems that became more visible once LLMs made internal data easier to search. In other words, AI did not replace the usual infrastructure mess. It put a work light on it.
That part lines up with what I wrote earlier in Shadow Agents Are the New Shadow IT. The connector is not the model. It is the operating reality around the model. Once a system can read internal data, call tools, and act on delegated permissions, all the dusty old ownership and access problems stop being theoretical. They become searchable, callable, and automatable.
AI detection starts with behavior, not signatures
One of the cleaner operational takeaways in the report is Mandiant’s recommendation to move from Indicators of Compromise to Indicators of Activity for AI security detection.
That makes sense.
Static signatures are a rough fit for dynamic systems that call tools, change prompts, and move across connected services. If your detection strategy is waiting for a known bad hash to wander in wearing a fake mustache, you are already late.
Mandiant calls out two practical telemetry examples worth stealing outright.
The first is tool execution sequences. If an agent accesses a database and then immediately makes an external API call, that chain might be perfectly normal in one workflow and deeply suspicious in another. You only get value from that signal if you understand the intended behavior of the application and ask developers for the telemetry to see it.
The second is token usage anomalies. Sudden spikes in input or output ratios can point to prompt injection attempts, abuse, or denial-of-service style behavior. That is not flashy detection engineering. It is context-aware monitoring for how the system behaves when someone leans on it sideways.
This is the broader shift. AI security is not just about knowing what model a team bought. It is about understanding what the application is supposed to do, what tools it can invoke, what data it can touch, and what patterns look wrong when it gets pushed off the happy path.
That is a much more useful starting line for SecOps than chasing every theoretical AI headline on the internet.
What good looks like when the basics are sorted
The encouraging part of the report is that Mandiant is also seeing real operational value from AI on the defense side. Not just demos. Observed use inside security operations.
One example is retrospective incident analysis. Teams are using AI to review 30 or more days of closed incidents and surface patterns a human analyst buried in the queue would miss. That turns a pile of reactive tickets into a hardening roadmap. Instead of asking why Tuesday was noisy, teams can ask which control keeps failing across hundreds of cases and what engineering work would reduce next month’s volume.
Another is AI as a translation layer for EDR and SIEM work. Rather than forcing every analyst to speak fluent SPL, KQL, Python, or notebook-sorcery, teams can ask natural language questions like “show me how prevalent this malicious file is in our network” and let the system build the query. That lowers the floor for good hunting without pretending the craft no longer matters.
Mandiant also calls out hunt hypothesis expansion, which I think is one of the better uses of AI in a SOC. A hunter can ask, “Given that I’m looking for lateral movement through WMI, what adjacent behaviors or log sources am I missing?” That is a useful partner interaction. Not because the model replaces the hunter, but because it helps widen the search space and challenge tunnel vision.
Forensic timelining is another strong fit. Normalizing timestamps, stitching together events, and building a coherent sequence of compromise is real work and usually tedious work. AI can help build that chronology faster, so responders spend more time on interpretation and less time doing data janitorial duty.
That is the payoff side of the story.
Do the foundational work first. Then use AI to go faster on defense.
Not the other way around.
Final thoughts
The loudest AI security conversations still tend to orbit the strangest possible outcomes. There is a place for that. Security teams should absolutely keep an eye on how adversarial use of AI evolves.
But this report is a good reminder that most organizations are not losing the plot because a threat actor pulled off some elegant model-level stunt. They are getting exposed by browser caching, bad access control, weak guardrails, overpowered agents, missing inventories, and detection programs that do not yet know what normal looks like.
That should actually be good news.
It means the work in front of most teams is hard, but not mystical.
Threat model the implementation you actually have. Red team the workflows you actually shipped. Instrument the behaviors the system actually produces. Tighten the permissions the agent actually uses. Then let AI help your defenders move faster where it genuinely helps.
Same old trench work.
New surface area.
Related reading
If you want the governance side of this problem, read Shadow Agents Are the New Shadow IT. It lays out why agents should be treated as identities with ownership, boundaries, lifecycle, and review rather than “just automation.”
If you want the broader identity framing, read Beyond Human: Securing Agentic AI and Non-Human Identities. That piece extends the argument beyond chatbots and into the larger non-human identity and agent governance problem.

Leave a comment