When a chatbot is wrong, you can usually notice and ask again. When an autonomous agent is wrong, the mistake can stack across steps, tools, and memory before anyone sees it. That gap is why a May 2026 survey of agent failures matters for anyone shipping agents on real data and money.

Twelve researchers led by Jinhu Qi (including Irwin King) published "Towards Trustworthy Agentic AI: A Comprehensive Survey of Safety, Robustness, Privacy, and System Security" (arXiv:2605.23989; Academia AI and Applications, 2026). They map how agentic systems fail, what defenses exist, and where the holes still are.

What changes when the system acts, not only answers

A standard model takes a prompt and returns text. An agent takes a goal and runs: plans, calls tools, stores intermediate results, chains actions, and adapts to what the environment returns.

That design creates failures prompt-response tests miss. One bad tool call can poison every later step. Memory can store a false belief and keep acting on it. Harmless-looking steps can combine into harm. The world changes as the agent acts, and those changes feed the next decision.

Safety and robustness

Here the risk is the agent's own trajectory. Attacks are not only user prompts. A malicious document the agent reads mid-task can steer the rest of the run without the user knowing. That is prompt injection from the environment.

Distribution shift is worse for agents than for chatbots. A chatbot that hits an unfamiliar case gives a worse answer. An agent in the same spot takes a sequence of confident actions that can make the situation worse with every step.

The metrics gap

Most agent benchmarks still ask whether the task finished. Far fewer ask whether constraints held along the way. A system can "succeed" while breaking rules on every run. The survey's unified metrics hub is useful because it tracks both outcome and process: task success, constraint violations, incomplete traces, attack success rates.

Privacy and system security

Here the adversary controls part of the environment. The survey documents real failures in open-source agent stacks, not only toy attacks.

Long-running memory is a privacy problem chatbots mostly avoid. An agent that researches across a session can accumulate secrets, then leak them through tool calls or injection. Memory poisoning (corrupting stored context to steer later behavior) has no clean single-turn equivalent.

Multi-agent setups widen the hole. One compromised agent can push junk through normal peer channels. Filters built for user input may trust peer agents by default.

What is still unsolved

1
Self-evolving agents. Systems that rewrite their own behavior from experience can leave their original safety properties behind. Fixed-system tests do not cover a moving target. Continuous verification is still thin.
2
Runtime monitoring. Most deployed agents lack continuous checks of execution traces against safety rules. Point-in-time release tests do not catch drift across sessions.
3
Useful memory without a leaky vault. Agents need context to help. Most current designs either drop memory (and lose utility) or keep memory that is easy to exploit.

The folk objection

The strongest pushback is that this is yesterday's software security with a new label: sandbox the tools, log the actions, ship. Partly true. Sandboxes and logs matter. The survey's point is that agents add long-horizon compounding, environment-sourced attacks, and peer trust that ordinary app security checklists still underweight. Treating agent risk as "just another API" is how teams miss the stack.

What to do with the map

Teams already putting agents on customer data, money, or external tools need process metrics, runtime monitoring, and independent review of tool and memory design, not only a release eval that asks whether the demo task completed.

For the Foundation, agent failure maps are a near-term layer. They do not replace the larger job. A world racing toward artificial superintelligence still needs binding limits, compute rules, and verification so capability does not outrun control. Use the survey to harden agents you deploy now. Use the treaty track so the end state is not an agent nobody can overrule. Full paper: arXiv:2605.23989.