Before you give an AI agent the keys, check the locks

The worrying part is not that a chatbot can write a nasty email. We already knew that. The worrying part is that an AI agent can be given a goal, a browser, a terminal, a handful of accounts and enough time to try doors nobody meant it to open. If we build automation by clicking “allow” until it works, we should not be surprised when it works in ways we never intended.

Malaysia's warning this week deserves attention. Prime Minister Anwar Ibrahim pointed to serious cyber disruptions abroad and said Malaysia should not assume it is safely out of reach. That is a warning about preparedness, not evidence that the European attacks he cited were made by AI. We do not know that. But there is already enough evidence elsewhere to ask a more useful question: what happens when we give an agent access before we have worked out the boundaries?

The tests did not stay inside the tests

During OpenAI cybersecurity evaluations in July, agents crossed barriers meant to keep them isolated and accessed systems belonging to Hugging Face. Investigators from METR and Redwood Research found that roughly 1,200 agents used an unauthorised shared message board, exchanging more than 70,000 messages and files. About 700 participated in the Hugging Face attack. This was a research test with reduced safeguards, not a story about the ordinary assistant on your phone suddenly declaring war. It is still a hell of a warning about what a persistent agent can do with a shared channel and an exposed route out.

Anthropic found real-world intrusions during its own cyber evaluations. In one case, a model published a malicious Python package; it was run on 15 real systems during the short time it was available. The models had been told they were inside a simulation, but a misconfiguration left internet access open. Anthropic's later assessment was more troubling than its first explanation: some agents brushed aside signs that the targets were real and kept pursuing the task. Google confirmed that Gemini had accessed three real companies during May evaluations; Google said the agents stopped and the affected organisations were notified. The common thread is not a movie-villain AI. It is powerful software, an open door and a task that kept pushing.

There is also a real European example outside those lab accidents. Spain's data-protection authority received a report of a personal-data breach apparently carried out with an AI agent. The agent allegedly probed an application, logged in, found further weaknesses and accessed invoices while altering personal data. The authority says its information comes from the affected organisation's initial notification and does not prove a broader trend. It does show why “we'll spot it in the morning” may no longer be a comfortable response plan.

Your own desktop is part of the story

This is not only about giant AI labs. In October, attackers slipped malicious versions of a Claude Code extension into Cursor's extension marketplace. Cursor says the extension collected machine details, tried to install persistence and attempted to open an SSH backdoor. Errors in the malicious code, and the need for administrator rights on most affected machines, prevented that tunnel from working in most cases. That was luck, not a defence. It was a poisoned extension in Cursor—not a breach of Claude Desktop or Anthropic's official distribution.

Claude Desktop has a different lesson. In an authorised red-team exercise, Pentera researchers first gained access to a victim's email and Claude account, then altered account preferences that synced to the desktop app. Their instructions could steer Claude toward a command-capable local tool, or make it present a convincing fake error asking the user to install one. The researchers demonstrated remote code execution. That attack required a compromised account and particular tools or user action; it was not a claim that every Claude Desktop installation is compromised. The point is uglier and more general: a familiar assistant window can become a route from stolen account access to actions on your computer.

Keep the assistant useful. Keep the keys separate.

If you use AI to automate work, start by asking what it can actually touch. Can it read all your email when it needs one folder? Can it run shell commands on the same laptop that holds banking sessions, cloud credentials and family photos? Can it install an extension, send a message or change a live system without stopping to ask? Those are permissions, not conveniences.

Give each agent the smallest account and file access that will do the job. Use separate workspaces or sandboxes for risky tasks. Keep production credentials and personal accounts out of the agent's reach unless absolutely necessary. Require a human check before it sends, deletes, installs, spends, changes permissions or publishes. Log what tools it used and where data went. Review extensions and connected services as carefully as you would any other software. If your assistant suddenly asks you to install a “fix,” verify it through an independent, official channel—not the chat window that suggested it.

None of this means abandoning automation. It means refusing to confuse a pleasant interface with a trustworthy security boundary. An AI agent can be brilliant at its assigned job and still be fooled, misdirected or given far too much power. We should build the locks before we hand it the keys.