Endpoint Detection and Response has spent two decades answering one question well: is this process doing something malicious code would do? It checks signatures, watches for anomalous behaviour, and flags unauthorized privilege escalation. An AI agent with tool access breaks the premise of that question, not by being malicious code, but by being a trusted program that can be talked into misusing its own, entirely legitimate, access.
The pre-AI version of this problem already has a name
Using a legitimate, signed program to do something malicious is not new. MITRE ATT&CK catalogues it as System Binary Proxy Execution (T1218): “binaries signed with trusted digital certificates can typically execute on Windows systems protected by digital signature validation,” which is exactly why allowlisting and signature checks struggle once the trusted binary itself is the thing doing the acting. An AI agent extends the same weakness to a program that does not need to be pre-loaded with malicious code at all: it can be redirected at runtime, by text it reads.
A hijacked agent is a confused deputy
The applicable term here is the confused deputy problem: “a computer program that is tricked by another program (with fewer privileges or less rights) into misusing its authority.” Give an agent real tools, then let it read content you did not vet, and it can be instructed by that content. This is exactly the pattern OWASP’s Prompt Injection entry describes, and it has already been demonstrated, not just theorized: Invariant Labs’ 26 May 2025 report showed a coding agent, reading an ordinary-looking GitHub issue in a public repository, following hidden instructions in it to expose private-repository data, using tools it was legitimately granted. The researchers’ own conclusion: “this is not a flaw in the GitHub MCP server code itself, but rather a fundamental architectural issue that must be addressed at the agent system level.”
process: python3 agent_worker.py --tool-socket 8443
user: developer (normal UID, no privilege escalation)
network: HTTPS POST to a domain the process has contacted before
signature: none matched, no known-bad hash
behaviour: consistent with routine developer tooling
# The same log line is produced whether agent_worker.py just fetched
# documentation the developer asked for, or was redirected by injected
# instructions to read a private file and POST it out.That is the actual blind spot: not a gap in any one product, but the fact that the log entry for “agent did its normal job” and “agent was hijacked into misusing its normal job” can be identical at the process level. Nothing about the binary changed. Nothing about the system call pattern is new. Only the intent behind the request changed, and intent is not a field in a process log.
What actually reduces this, and what does not
It is worth being precise about what the person who named this pattern actually recommends. Simon Willison, who described the “lethal trifecta” of private-data access, untrusted-content exposure and external communication together in one agent, is explicit that avoiding that combination is the real fix, not a add-on guardrail: “the only way to stay safe there is to avoid that lethal trifecta combination entirely.” He is openly skeptical of products that claim to reliably catch injected instructions after the fact, noting that “we still don’t know how to 100 percent reliably prevent this from happening” and that a 95 percent catch rate is “very much a failing grade” for a security control.
- Design first: give an agent the narrowest tools and data access its task needs, so there is less for a successful injection to abuse (the architectural fix both Willison and Invariant Labs point to).
- Treat any content the agent reads that you did not write or vet, issues, fetched pages, downloaded files, as untrusted input, on principle, every time.
- Where design and review are not enough, the one step a data-exfiltration attempt cannot skip is a network connection out. Watching or restricting that, per process, does not prevent an agent from being fooled, but it is a real, independent layer that does not depend on recognizing the injected instruction in the first place.
How FireAI and HisnLabs fit in
No firewall makes a hijacked agent safe on its own, but the data it tries to send out still has to leave through a socket, and that is the one step FireAI watches regardless of which trusted binary the agent is running inside of.
FireAI is HisnLabs’ own product: an on-device AI firewall for Mac. It shows every connection your apps make, in plain language, and lets you decide what leaves your Mac — its AI runs locally, so your traffic is never sent to us or anyone else. HisnLabs’ security research team is the group that keeps that decision-making accurate: cataloguing which domains are ordinary telemetry versus a real product, tracking the country and network behind a connection, and training the on-device model (its Autopilot feature) on real traffic patterns, all without any of it leaving your Mac.
You can read the technical decisions behind it, or try FireAI for 17 days, at FireAI, by HisnLabs.