OWASP’s GenAI exploit roundup for the first quarter of 2026 lists eight major security incidents involving AI and agentic systems. The cases range from a Claude-assisted compromise of Mexican government infrastructure to a remote code execution vulnerability in Flowise. Together they make a strong case for treating AI agents as high-risk architecture components, not chatbot accessories.
What the incidents have in common
The eight incidents share a common theme: the AI system was given access to perform actions, and an attacker found a way to influence those actions. In some cases the entry point was prompt injection. In others it was a vulnerable integration, excessive permissions or insufficient isolation between trusted and untrusted content.
The Mexican government breach reportedly involved an attacker using Claude to assist in moving through systems after initial access. The Flowise RCE exposed how a low-code agent platform can become a critical vulnerability when it executes code or commands. Both illustrate that the risk is not theoretical; it is being exploited in operational environments.
Why agent architecture matters
Most security principles still apply, but agentic systems introduce new failure modes. A traditional application receives input and produces output. An agent receives input, reasons, selects tools and acts on external systems. That extra layer of autonomy expands the blast radius of any weakness.
If an attacker can control the reasoning input or subvert the tool-selection logic, they can cause data exfiltration, privilege escalation, unauthorised transactions or lateral movement. Defending against this requires architecture, not just input validation.
A secure AI agent architecture checklist
Treat the model as untrusted. Do not assume that outputs are safe because the model is internal. Validate, parse and constrain outputs before acting on them.
Apply least-privilege tool access. Each tool available to an agent should have the minimum permissions required. A research agent does not need write access to a database. A coding agent does not need access to production secrets.
Separate trusted and untrusted instructions. System prompts should be protected from user input. Untrusted content such as emails, web pages and documents should not be able to override the agent’s mandate.
Require human approval for consequential actions. Payments, data exports, account changes and code deployments should not happen without explicit confirmation. This is inconvenient but it is one of the most effective controls available.
Log and monitor agent behaviour. Record the full chain: user request, model reasoning, tool calls, outputs and errors. Anomalous patterns should trigger review or automatic suspension.
Sandbox execution. If the agent can generate or execute code, run it in an isolated environment with strict resource and network controls.
Review third-party platforms. Low-code and no-code agent builders can accelerate deployment, but they also centralise risk. Understand their execution model, patch cadence and data handling before building critical workflows on them.
The bottom line
OWASP’s roundup is a reminder that the security community is already learning from real incidents. Organisations building or deploying AI agents should use these cases as design inputs. The goal is not to eliminate every risk but to make exploitation require more effort and leave more traces. That starts with treating agent architecture as a first-class security concern.