Security risks of AI agents: the lethal trifecta and the OWASP list

A user asks an AI agent to draft an out-of-office reply. The agent goes through the inbox, runs into an email with a hidden instruction and sends a resignation letter to the CEO instead. That is not an invented case but a demonstration that OpenAI published itself (22 December 2025) while hardening its browser agent, found by its own automated attacker. It shows what changes: a chatbot gives a wrong answer, an agent takes a wrong action.

Why are AI agents riskier than chatbots?

A chatbot gives an answer and a person decides what to do with it. An agent reads, chooses and acts, with the rights you gave it: sending emails, changing files, preparing payments. OWASP writes in the Top 10 for LLM Applications 2026 (August 2026) that once a confident answer drives a decision or a tool call, "a wrong answer turns into a wrong action". As the root cause of Excessive Agency, too much room to act, OWASP usually names too many functions, too many permissions or too much autonomy.

What is the lethal trifecta for AI agents?

Simon Willison, who coined the term prompt injection, described the lethal trifecta on 16 June 2025. These are three things you should not give an agent at the same time:

• access to your private data;
• exposure to untrusted content: anything through which text or images from an attacker can reach the model, such as an email, a web page or someone else's document;
• the ability to communicate externally in a way that could let data leak out.

If an agent has all three, an attacker can, according to Willison, easily trick it into fetching your data and sending it to them. The third element is broader than it looks: any web request can carry data out, including an API call, loading an image or a link someone clicks. An agent that reads your mailbox (private data, and anyone can email you) and can send mail or open pages itself already has the full set.

The rule of thumb: remove one of the three. Willison himself sees avoiding that combination as the only safe way. If that is not possible, we recommend an additional measure: have a person approve every action that can send data out, not only an outgoing email but also a web request, a link or an image. Praxikon's Agent-check (it calls this the dangerous triangle) tests per agent whether all three are present, and the guide to AI agents and the law puts the rest in order.

Why will prompt injection probably never be fully solved?

With SQL injection, the well-known website vulnerability, the problem can be fixed at the root because a database can keep data and instructions apart. A language model cannot. The UK National Cyber Security Centre (NCSC) wrote on 8 December 2025 that a language model knows only the "next token", with no distinction between data and instructions, and that it is "very possible" that prompt injection will never be mitigated as fully as SQL injection. The NCSC sees a language model as an "inherently confusable deputy": a stand-in that can always be misled.

OpenAI wrote on 22 December 2025, about its browser agent, that prompt injection, much like scams and social engineering on the web, is "unlikely to ever be fully 'solved'". On 23 March 2026 the US NIST (CAISI) reported the results of a public competition in which participants tried to hijack agents (red teaming): from more than 250,000 attack attempts by more than 400 participants against 13 leading models, at least one successful hijacking was found against every model. In RAN 6 (5 March 2026), the Dutch Data Protection Authority (AP) concluded that, as robust solutions are lacking, limiting agents' access to external sources may be advisable. OWASP sums it up: build the system so that "when the model is fooled, and it will be, nothing important breaks".

What is in the OWASP list for AI agents?

The OWASP Top 10 for Agentic Applications for 2026 appeared on 9 December 2025. It is not law but the standard checklist. OWASP adds the concept of Least-Agency: no autonomy where it is not needed, because it widens the attack surface without adding value. The ten risks, with OWASP's own example where it gives one:

The examples come from OWASP's announcement; we discuss three of them (EchoLeak, GitHub MCP and Replit) below. ASI09 is why "a person is watching" is no guarantee: approving without checking is only rubber-stamping.

In the OWASP Top 10 for LLM Applications 2026 (August 2026), Excessive Agency, too much room to act, rose from sixth place (LLM06:2025) to third (LLM03:2026), "because the vote and the record agree that agentic deployments are where the damage is landing". Prompt injection stays in first place.

What has actually happened, and what was only a demonstration?

A demonstration proves that an attack is possible, not that it happened.

The Hugging Face case was a lab test with the filters off and does not prove that ordinary business agents do the same. It does show that an agent that escapes its test environment mostly exploits everyday weaknesses at other organisations, such as overly broad access and long-lived credentials. And at Replit, a code freeze given to the agent as an instruction did not stop it.

Which controls limit the damage?

Because deception cannot be ruled out, the controls limit what a deceived agent can do. The same line runs through the OWASP lists, the UK NCSC advice of 15 May 2026 and the joint guidance of six cyber agencies (1 May 2026):

• Least privilege. Only the tools and data the task needs, for as short a time as possible, with short-lived keys. An agent that summarises emails does not need to be able to send or delete them.
• Approval enforced in software. A person approves deleting, paying and anything that sends data out, including web requests; this is enforced technically, not just requested in the prompt. According to the joint guidance, designers or operators decide when approval is needed, not the agent. Keep approval real (meaningful human oversight): in the GitHub MCP demonstration the researchers note that many users choose "Always Allow" and stop monitoring individual actions, and at Meta a person simply carried out the agent's advice.
• Immutable logs. Record every tool call, out of the agent's reach; the guidance recommends agents without write access to logs.
• A tested kill switch. Who stops the agent, and how do you withdraw its access? The NCSC wants clarity in advance on "ultimately who can stop it".
• Isolated test environments. No production keys and outbound traffic closed by default. Hugging Face names strict isolation around evaluations, short-lived credentials and blocked access to cloud metadata as priorities.
• Vetting plug-ins and MCP servers. Admit only approved, pinned versions from a trusted registry (see buying an AI agent).
• Red teaming. Have someone attack your own agent, with your own tools and data, and repeat it after every major change.

Record, per agent, which controls apply, in an agent register.

What do the GDPR, the AI Act and the Dutch Cybersecurity Act require?

GDPR. Article 25 GDPR requires data protection by design and by default: in principle only the data necessary for each specific purpose, including as regards its accessibility (paragraph 2), so limit what the agent may see. Article 32 GDPR requires a level of security appropriate to the risk and, where appropriate, a process for regularly testing the measures (paragraph 1(d)); that is the legal hook for least privilege, logging and red teaming. A personal data breach must be notified to the supervisory authority, in the Netherlands the AP, without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the people concerned (Article 33 GDPR). An agent that accidentally deletes personal data or shows it to unauthorised people can cause such a breach (Article 4(12) GDPR). Without logs you do not know what happened, and so not whether you must notify. More in our article on AI agents and the GDPR.

AI Act. If the agent is a high-risk system (for example in recruitment, Annex III), Article 15(5) of the AI Act requires it to be resilient against attempts by unauthorised third parties to alter its use, outputs or performance by exploiting system vulnerabilities. The list of attacks includes "inputs designed to cause the AI model to make a mistake"; prompt injection is not named, but in our reading it comes close. It is a design requirement on the provider (Article 16(a)), applying to Annex III systems from 2 December 2027 and to Annex I systems from 2 August 2028; for systems placed on the market or put into service before that date, the requirements only apply after a significant change in their design, and systems intended for use by public authorities must comply by 2 August 2030 (Article 111(2)). Most agents are not high-risk systems. For them the security duties lie mainly in the GDPR (where personal data is involved) and, where it applies, the Cybersecurity Act.

Dutch Cybersecurity Act. If your organisation falls under the Dutch Cybersecurity Act as an essential or important entity, the Dutch implementation of NIS2 (in force since 15 August 2026), Art. 21 of the Dutch Cybersecurity Act requires appropriate and proportionate technical, operational and organisational measures for your network and information systems, including incident handling, supply chain security and access policy (paragraph 3(b), (d) and (i)). The Act does not mention agents; in our reading, an agent with access to your systems, and the third-party plug-ins it uses, fall within its scope. More in our article on AI agents and the Cybersecurity Act.

Where do you start?

Start with three steps: list every agent and mark which of the three it has, remove permissions and enforce approval in software wherever data can go out, and test the kill switch before you need it. If you want someone to look at the security and governance of your agents with you, you can hire Zahed Ashkara as an AI and privacy legal adviser.