Yes. In early 2026, security researchers showed that visiting one malicious website could let an attacker take control of a popular open-source AI agent running on a user’s own machine. Weeks later, a poisoned release of a widely used AI developer library, downloaded about 95 million times a month, was built to steal credentials from computers that installed it.
A note on the legal and regulatory points here: they summarise public sources as of November 2026 and should not be relied on. Rules for AI agents are still being written, and some of what is described here is proposed or coming soon rather than settled. Check the current position, or ask a qualified professional, before acting on it. Incident details are as publicly reported at the time, and some are disputed.
What does it mean to hijack a local agent?
Hijacking a local agent means an outsider gets your agent to act for them, using the access you gave it. A local agent is AI software that runs on your own computer rather than in someone else’s cloud. To be useful, it often gets broad reach: your files, your terminal, your messages, your browser and sometimes your wallet or exchange keys.
That reach is what makes it a target. An attacker who controls the agent does not need to break into each of those things one by one. The agent already holds the keys.
There are three main routes in:
| Route | How it works | Example from 2026 |
|---|---|---|
| Through the browser | A web page talks to the agent’s local control service | A flaw that let a malicious site take admin control |
| Through the supply chain | Malicious code arrives inside software the agent depends on | A poisoned release of an AI developer library |
| Through what it reads | Hidden instructions in content the agent processes | Prompt injection, covered in our previous guide |
The third route has its own guide. This one covers the first two, which reach the machine itself.
How could a website take over an agent on my computer?
A website could do it because the agent trusted any connection that came from the same computer, and a browser tab counts as one. The flaw, disclosed by a security firm in early 2026, worked in four steps:
- The agent ran a local control service, reachable only from the user’s own machine and protected by a password.
- A malicious web page used ordinary JavaScript to open a connection to that local service. Browsers did not block this kind of connection to the local machine.
- The service did not limit login attempts from the local machine, so the page could guess the password at hundreds of attempts per second, without the failures being logged.
- Once in, the page registered itself as a trusted device. The service approved local devices automatically, with no prompt to the user.
From there, the researchers said, an attacker could read logs and settings, pull stored credentials, search message histories, take files from connected devices and run commands. In practice, that can amount to full control of the workstation, triggered by one visit to the wrong page.
The project fixed the flaw within 24 hours of disclosure, in a release dated February 26, 2026. Users who updated were protected. Users who did not stayed exposed.
How does a poisoned code library end up on my machine?
It arrives as a normal update. Developers who build agents rarely write everything themselves; they install shared libraries from public package indexes, and those libraries update often.
On March 24, 2026, an attacker published two malicious versions of a widely used library that connects applications to many AI models. According to a research note on the incident, the attacker obtained the project’s publishing token after a security scanning tool used in its build pipeline was itself compromised days earlier. Another analysis described that route as likely rather than confirmed. The malicious versions bypassed the project’s normal release process.
What the code did, as reported by security researchers:
- One version ran its payload only when part of the library was used. The second added a file that ran every time the programming language started on that machine, whether or not the library was called.
- It searched for SSH keys (used to log in to servers), cloud account credentials, AI service keys and configuration files holding secrets.
- One independent analysis of the code reported it also looked for crypto wallet files for about ten different cryptocurrencies.
- It encrypted what it found and sent it to a lookalike web address controlled by the attacker.
The package index quarantined the versions about 46 minutes after the first one appeared. Because cached copies stayed reachable in some environments, the project’s advisory put the effective exposure window at about five hours. Researchers also warned that updating alone did not remove the startup file.
Why are AI agents such attractive targets?
Agents are attractive because they combine broad access with a willingness to follow instructions. A normal app does one job with narrow permissions. An agent is often given wide permissions precisely so it can handle tasks nobody planned for.
The models inside agents are also not hard to mislead. In a March 2026 public red-teaming competition reported by NIST, the US standards body, more than 400 participants made more than 250,000 attack attempts against 13 frontier AI models working as agents, including coding and computer-use agents. At least one successful attack was found against every model (NIST’s write-up of the agent security red-teaming competition).
Put those together and the risk is clear. Your agent is only as safe as the software around it, and that software changes every week.
What could go wrong?
The worst case is an agent running on the same machine that holds your wallet keys, seed phrase or exchange API keys. In both 2026 incidents, the attacker’s first goal was credentials. Anything stored in a file, a settings folder or an environment variable on that machine should be treated as reachable.
Three assumptions failed in these cases, and each is common:
- “Local means safe.” The browser flaw worked precisely because the agent trusted local connections.
- “Updates protect me.” Updates fixed the browser flaw, but a malicious update caused the library compromise. Both are true at once.
- “I’d notice.” Neither attack needed the user to click a warning or approve anything.
There is also a limit to what you can control. Most people cannot audit the code their agent depends on. That makes isolation and key hygiene more important than vigilance.
The trust takeaway
Treat a local AI agent like a new employee with a master key: useful, but kept away from the vault. In our view, the safest setup assumes the agent’s machine will be compromised one day, and makes sure that day is survivable.
Before you run an agent on your own computer, check:
- Are your keys somewhere else? Never keep seed phrases or wallet private keys on the machine the agent runs on; use a hardware wallet or separate device.
- Is the agent isolated? Run it in a separate user account, container or machine with only the access it needs.
- Are exchange keys limited? Give any agent trade-only keys with no withdrawal rights, and restrict them by IP address where possible.
- Is the control panel locked down? Use a long, unique password and turn off automatic device approval if the setting exists.
- Do you update promptly, and pin carefully? Apply security fixes quickly, and if you build agents, pin dependency versions and check advisories before upgrading.
- Do you know what to rotate? If a component you use is compromised, change every key and password that machine could see.