For years the most effective attackers have avoided bringing malware at all. Why smuggle in a payload your EDR will flag when the target machine already ships with everything you need? This is living off the land (LOTL): abusing legitimate, pre-installed tools — PowerShell, WMI, signed system binaries (“LOLBins”) — to operate. Because the tools are allowlisted and the activity looks normal, LOTL leaves no malware signature and blends into routine operations. By 2023, CrowdStrike reported that roughly 6 in 10 detections involved LOTL techniques rather than traditional malware. It works because the safest tool to attack with is one the defender has already decided to trust.

Now consider what just got installed on every endpoint and in every enterprise: an AI agent. It holds credentials. It can call tools, APIs, and databases. It operates inside your network with real access. And — unlike PowerShell — it is eager to please, following instructions wherever they come from. It is, in other words, the most powerful living-off-the-land tool ever deployed, and attackers have noticed.

Living off the agent

The 2026 term for this is “living off the agent.” The attacker brings no malware and exploits no memory-corruption bug. Instead, they hijack the agent’s own legitimate tools, permissions, and workflows, turning your trusted AI assistant into their instrument. The agent already has the access; the attacker just has to redirect it.

The mechanics, at a high level: an attacker plants instructions in content the agent will read — an email, a shared document, a support ticket, a web page, a code comment, a dependency’s docstring. When the agent ingests that content (its entire job is ingesting content), the hidden instructions hijack its plan, and it carries them out using its own sanctioned tools and credentials. This is the classic confused deputy problem: a privileged party (the agent) is tricked by an unprivileged one (the attacker’s text) into misusing its authority — except this deputy operates at machine speed and never gets suspicious.

The reason this is so hard to defend with traditional tooling is that the attack vector is language itself. You can sandbox a binary; you cannot sandbox a sentence. A firewall can block a known-bad domain, but it can’t reason about whether the paragraph in an incoming email is data or a command. And to the agent, there is no reliable difference — text is text.

The parallel-poisoned web

One emerging variant shows how proactive this gets. Researchers have demonstrated a “parallel-poisoned web”: a malicious site that serves benign content to human visitors and a different, instruction-laden version to any AI agent it detects. The attacker sets up one page and waits for agents to arrive. Because the malicious content is delivered dynamically and only to agents, it sails past email filters and malware scanners entirely — and the user, who sees only the clean version, has no idea. It’s a new form of living-off-the-land where, as the researchers put it, the victim’s own trusted AI agent is turned into the attack tool.

Persistence without a foothold

Traditional persistence means leaving something behind — a backdoor, a scheduled task, a modified binary. Agentic systems offer a quieter option: memory poisoning. If an agent has persistent memory, a single planted instruction can silently influence its behavior across future sessions, with no need for the attacker to maintain access. The poisoned memory entry is a backdoor that reloads itself every session, and it lives in your agent’s memory store, not on disk where a scanner would find it. The practical defensive consequence: treat memory writes as security events, log them, and review what an agent is allowed to persist.

Why your existing defences are blind to it

Here’s the uncomfortable part for security teams. Living off the agent defeats the conventional detection stack almost by construction:

• No malware artifacts. There are no file hashes, no dropped executables, no suspicious downloads for EDR to catch. The “weapon” is a string of text that’s already been deleted from the email.
• Legitimate activity. Every action the hijacked agent takes is an authorised API call by an authenticated identity using an allowlisted tool. To your logs, it looks like the agent doing its job.
• No traditional forensic trail. Incident responders accustomed to malware hashes and process trees find little to grab onto. Confirming an attack even happened can require AI-specific logging that most organisations don’t yet have.

The deeper shift is architectural. For a decade, the model was: watch the traffic between the endpoint and a centralised LLM chat app, monitor for sensitive data, and block at the firewall if needed. The perimeter was legible. That model is gone. The agent now operates inside the network, with real data and real tools, and the dangerous activity is indistinguishable from legitimate activity at the network layer.

What this means for how you defend

If the activity is legitimate and there’s no malware to find, detection has to move from artifacts to behaviour — specifically, to the agent’s decisions. You catch a hijacked agent not by scanning its outputs but by noticing that its sequence of actions is abnormal: a triage agent that suddenly reads credentials and opens a network connection is mid-incident, and only a decision-level trace reveals it. That means logging every tool call, delegation, and retrieval (not just final outputs), baselining what a normal tool-call sequence looks like, and alerting on deviation. It also means the harness controls from the previous post — least privilege, scoped credentials, egress allowlists, a tool gateway that enforces policy independent of the model — aren’t optional niceties. They’re the only things standing between “the agent was tricked” and “the agent was tricked into doing real damage.”

The trusted insider you onboarded without a background check

Enterprise AI assistants — Microsoft 365 Copilot, Salesforce Agentforce, ServiceNow Now Assist, Slack AI, Glean — share a profile that should make any security architect nervous. Each one ingests external content (emails, documents, CRM records, tickets, web data), holds privileged internal access (your SharePoint, your CRM, your databases), and can produce output that reaches the outside world (links, images, sent emails, written records). That’s Simon Willison’s lethal trifecta from the previous post — private data, untrusted content, and an exfiltration channel — assembled by default, at enterprise scale, in a system you deliberately gave broad access. As one analysis put it, these assistants are “trusted but indiscriminate insiders.”

In 2025 and 2026, researchers turned that structural exposure into a series of working, zero-click exploits. The pattern across all of them is identical, which is exactly why it matters.

EchoLeak: the zero-click breakthrough

The watershed was EchoLeak (CVE-2025-32711, CVSS 9.3), disclosed by Aim Labs in June 2025 — the first documented case of prompt injection weaponised for concrete data exfiltration in a production AI system, and it required zero clicks.

The anatomy, at the level a defender needs (the vulnerability is patched and the details public): an attacker sends an ordinary-looking email containing hidden instructions. When the victim later asks Copilot something unrelated, Copilot retrieves that email as part of the user’s context — and processes the hidden instructions as if they were commands. Aim Labs named the core failure an “LLM Scope Violation”: the assistant was tricked into crossing its own trust boundary, pulling the most sensitive data from the user’s context and embedding it into an outbound reference. The data then left automatically — through an auto-fetched image and a link proxied via an allowlisted Microsoft domain, which sidestepped the content-security policy. No click, no download, no malware.

What makes EchoLeak instructive isn’t the specific bypasses — Microsoft patched those server-side, and no in-the-wild exploitation was reported. It’s the structural lesson Aim Labs drew and Microsoft’s own response confirmed: patching the CVE does not remove the attack surface. Copilot still ingests external content and still processes it with the same model that has access to your internal data. That mixing of untrusted content and privileged data in one context is a property of how the assistant works, not a bug you can fully patch away. EchoLeak closed one chain of exploits; the class remains.

It was never just Microsoft

If EchoLeak were a Microsoft-specific flaw, you could patch and move on. The disclosures that followed proved it’s endemic to the entire category of RAG-based enterprise agents:

• ForcedLeak (CVSS 9.4) — Noma Security, September 2025, against Salesforce Agentforce. An attacker submitted a public Web-to-Lead form whose Description field carried injected instructions; when an employee’s agent later processed the lead, it exfiltrated CRM data to a domain that had been on Salesforce’s allowlist, expired, and was repurchasable for about $5. Noma’s framing was blunt: AI agents present “a fundamentally different and expanded attack surface compared to traditional prompt-response systems.” Aim Labs added that ForcedLeak is “a subset of these same EchoLeak primitives… endemic to RAG-based agents.”
• Copilot Studio (CVE-2026-21520) and PipeLeak — Capsule Security, late 2025 into 2026. Notably, Microsoft assigned a CVE to a prompt-injection flaw in an agentic platform — which researchers called “highly unusual,” and which carries a signal: if that precedent holds, every enterprise running agents inherits a new vulnerability class to track, one that, as the researchers note, “cannot be fully eliminated by patches alone.” When Salesforce added human-in-the-loop confirmation for email actions, Capsule reported the email channel remained exploitable on custom sub-agents — the majority of real deployments.

The agent-building platforms multiply the exposure further. A productivity assistant can leak what it can read; an agent built on the same platform can also take actions in external systems — send emails, create records, write to databases — which are far more capable exfiltration and impact channels than a chat response, and it does so across longer autonomous task chains before any human reviews the result.

Cross-agent hijacking: the insider recruits other insiders

A distinct and worsening variant appeared with multi-agent enterprise platforms like ServiceNow Now Assist. The systems were designed so that one agent can legitimately ask another to perform an action — so when it happens, no security control thinks it odd. The consequence: if one agent falls to a prompt injection, it can instruct other agents to do worse things, faster than any human could intervene. Researchers liken it to an LLM-powered insider threat — one part of the system undermining another from the inside, the agentic equivalent of lateral movement between microservices. Agent-to-agent trust, established for productivity, becomes a privilege-escalation path.

Why enterprise AI is uniquely exposed

Three properties make this class especially dangerous, and all three are features you paid for:

1. Service-account-level reach. The assistant operates with broad organisational access, so an injected instruction can pull data beyond the triggering user’s own privileges — the agent’s permissions, not the victim’s, set the blast radius.
2. Shared context. External content and privileged internal data sit in the same model context, with no hard isolation between “stuff to act on” and “stuff to act with.”
3. Forensic darkness. The exfiltration is silent and leaves no malware artifacts; standard EDR and SIEM tooling, built for files and processes, can miss it entirely. Confirming an incident can require AI-specific logging most teams haven’t deployed.

The defensive thesis

You cannot patch your way out of a structural attack surface, and you cannot prompt-filter your way out either — every one of these exploits bypassed the vendor’s injection classifier. The durable defences operate outside the model and around the data but the shape is already clear from the incidents: scope the assistant’s data access before it can reach sensitive material (not after the model has it), break the trifecta by separating the agent that reads untrusted content from the one that holds privileged access, lock down output channels (strict CSP, no auto-fetching of external images and links, output DLP, restrained markdown rendering — the exact mechanisms EchoLeak abused), and deploy AI-centric logging so a silent exfiltration isn’t also an invisible one.

We’ve established how attackers turn an agent against you. Now is about how far that reach extends — and it extends much further than most teams have mapped. The moment you connect an agent to your APIs, databases, and tools, you don’t add attack surface linearly. You add a new trust boundary at every connection, and a new privileged identity that legacy security was never designed to govern.

Agents are privileged non-human identities

Start with the identity problem, because it underlies everything else. Every agent you deploy is a non-human identity (NHI) that needs API access and machine-to-machine authentication — and legacy identity and access management was built for humans logging in, not for autonomous software acting continuously across systems. The result in most organisations is NHI sprawl: a growing population of agent identities, often over-permissioned, frequently unmanaged, sometimes entirely unsanctioned (shadow agents that employees wired up under deadline pressure). The correct mental model is uncompromising: an agent is a privileged identity, and you should govern it with the same rigour you apply to an admin account — least privilege, monitoring, audit, and short credential lifetimes.

MCP: capability without containment

The Model Context Protocol is how most agents now reach tools, APIs, and data — and each MCP server is an independently attackable trust boundary. MCP was designed for capability, not containment, and the security numbers reflect it: a February 2026 audit found 43% of publicly available MCP servers vulnerable to command-execution attacks, and one disclosure put up to 200,000 vulnerable MCP instances exposed across IDEs, internal tools, and cloud services. Two attack patterns deserve specific attention:

Tool poisoning — “the new prompt injection.” An attacker hides instructions inside a tool’s metadata or description — text the agent reads but the user never sees. Because the agent treats tool descriptions as trusted, a poisoned description can change how the agent behaves and even override how it uses other, previously safe tools. The model thinks it’s calling a benign search tool; the tool does something else. This is the supply-chain risk of the agent era, and it’s why tool definitions must be reviewed like code, not trusted like configuration.

The confused deputy at the data layer. Many MCP servers execute actions with their own elevated privileges, not the requesting user’s. Picture a database MCP server that holds admin credentials: a user with no database-admin rights asks the agent to “clean up old records,” and the server — which does have admin — dutifully runs it. The user’s lack of privilege was never checked; the server’s privilege was used on their behalf. This is the classic confused-deputy problem, and it’s endemic to tool servers that carry standing credentials.

Databases, APIs, and excessive agency

Beyond MCP, the direct connections matter. An agent that generates and runs database queries introduces text-to-SQL injection and over-broad reads — which is why practitioners now say “database activity monitoring is critical again,” this time watching a non-human identity. An agent with broad API access can be driven to chain individually benign calls into a harmful sequence — excessive agency (OWASP’s LLM06 / the agentic risk catalogue), where the danger isn’t any single permission but the breadth of what the agent can orchestrate. And configuration is not innocent: a 2026 round-up documented remote code execution where config fields in an AI orchestration platform turned out to be code paths, not just settings — a reminder that “settings” an agent can influence may be executable.

The defensive playbook

The throughline of this post is that these attacks abuse legitimate access by a trusted identity, so the defences live in identity, data scope, and behaviour — not in signatures or prompt filters. Here is the consolidated playbook; it is, deliberately, defence in depth, because every credible source agrees no single control is sufficient.

1. Identity and least privilege. Govern each agent as a privileged NHI: minimal tools and data, short-lived scoped credentials, identity binding, and context-aware authorisation (decisions based on who is asking, the sensitivity of the data, and the action attempted). Crucially, fix the confused deputy by having the agent act as the requesting user — propagating the user’s identity and permissions — rather than with a tool server’s standing privileges.

2. Scope data access at the source. The EchoLeak lesson: restrict what the agent can reach before it reaches it, not after. Provenance-based access control, retrieval firewalls, pre-ingestion validation, and prompt partitioning keep untrusted content and privileged data from sharing one unbounded context.

3. MCP and tool hygiene. Allowlist tools; pin and verify MCP server versions with the same rigor as any dependency; review tool descriptions and agent config paths in code review; block auto-approval of new MCP servers; sandbox servers and restrict outbound connectivity from orchestration hosts.

4. Output channel controls. Lock down exactly what the enterprise exploits abused: strict content-security policy, no auto-fetching of external images or links, output DLP for secrets and PII, and restrained markdown rendering.

5. Monitoring built for agents. EDR and SIEM watch files and processes; agent attacks hide in decisions. Log every tool call, delegation, and retrieval — the reasoning chain, not just the output — apply user-and-entity behaviour analytics to non-human identities, baseline normal tool-call sequences, and treat memory writes as security events. A hijacked agent reveals itself by an anomalous sequence, not a bad file.

6. Human-in-the-loop on what matters. Mandatory approval for high-impact, irreversible, and externally-facing actions — tiered by risk so the gate stays meaningful and doesn’t dissolve into approval fatigue.

Align the program to the frameworks now maturing for exactly this: the OWASP Top 10 for Agentic Applications (2026) — which names tool misuse, identity and privilege abuse, supply-chain, code execution, and excessive agency as distinct risks — plus MITRE ATLAS for adversary techniques and the NIST AI Agent Standards Initiative (launched February 2026) for governance.

The whole picture

The agent is a powerful new insider that lives inside your network, holding credentials and wielding tools, and eager to follow whatever instructions reach it. Attackers in the AI era don’t break in — they redirect what you already trust. They live off the agent, they hijack the enterprise assistants you’ve connected to everything, and they reach through the expanding web of APIs, databases, and MCP servers each agent touches. Not one of these attacks requires malware; nearly all of them are invisible to the defences built for the previous era.

That’s why the security has to be built into the workflow and the harness from day one — and why the defensive posture is the same one the industry adopted for malware a decade ago, now pointed at a new kind of insider: assume the agent can be turned against you, govern it like the privileged identity it is, watch its decisions rather than its files, and contain every blast radius so that a hijacked agent stays a contained incident rather than a breach. The capability is extraordinary, and worth having. The discipline is what lets you keep it.