The Trojan horse in your CRM: how companies get hacked through one AI-readable field

A few years ago the main AI risk was easy to explain: the model said something dumb, and a human decided whether to trust it. That was already annoying. The newer problem is bigger, because the agent is no longer just talking. It can read inboxes, inspect CRM records, browse the web, write files, run commands and sometimes chain those actions on its own.

That changes the whole failure mode. A wrong answer is one thing. An agent with access, context and somewhere to send data is a very different kind of problem.

The dangerous part is that the workflow often looks completely normal. A sales rep asks for a lead summary. A manager asks Copilot to review the morning inbox. A developer asks a coding agent to inspect a README and fix local config. Nothing about those prompts sounds reckless. Trouble starts when the agent reads attacker-controlled content and treats it like instructions instead of data.

Once an agent can read private data, absorb hostile content and act through connected tools, it stops feeling like a helper and starts feeling like an insider with bad judgment.

The shift: from assistant to operator

This is the part many teams still underestimate. Modern agents are moving from interface to actor.

The real issue is not only model quality. It is agency. The moment an agent can:

access internal systems
read untrusted external content
send data or trigger actions back out

you get a risky combination. OWASP still puts prompt injection near the top of the GenAI risk list, and that makes sense. The impact grows fast once the model is connected to business tools instead of living inside a chat window. Recent research goes even further and argues that prompt injection may stay with us as a persistent failure mode for agents, not something that disappears once prompts are written more cleanly.

Three attack paths matter most in practice

If I were reviewing an agent rollout today, these are the three patterns I would assume are relevant even before an incident shows up internally.

Attack path	What the attacker controls	What the agent gets wrong
Indirect prompt injection	Email, PDF, CRM field, webpage, ticket description	Treats hostile content as instructions rather than data
Silent egress via metadata or previews	URL previews, HTML title, meta description, Open Graph tags	Leaks data through a side-channel the user never meant to trigger
Memory poisoning / sleeper behavior	Long-lived memory, saved preferences, persistent notes	Carries attacker influence into later tasks

The first pattern is the one most teams already know: someone hides malicious instructions in content the agent will later read. The second is quieter. The 2026 Silent Egress paper showed that agents can be influenced through things users barely notice, like HTML titles, meta descriptions and Open Graph data. A simple link preview can become part of the attack surface.

The third pattern is what makes this feel less like a chatbot problem and more like an insider problem. Long-term memory is useful, but it also gives attackers somewhere to leave residue. If an agent remembers a poisoned preference, a copied address or a fake "always do this" rule, the attack does not need to pay off right away.

These cases are already real

This is not just a lab discussion anymore. Public cases have already shown the pattern in real products.

EchoLeak: inbox summary becomes exfiltration

Microsoft tracks CVE-2025-32711 in Microsoft 365 Copilot. Public reporting described a zero-click-style exfiltration chain: the attacker sends crafted email content, the user asks Copilot to summarize the inbox, and the agent processes hostile instructions hidden inside that email context. The brand matters less than the shape of the failure. Untrusted content entered a trusted workflow.

ForcedLeak: the CRM lead field becomes the payload

Noma Security's ForcedLeak research on Salesforce Agentforce showed the same idea in a sales workflow. Instead of attacking a chat box directly, the attacker used a lead description field. When the rep asked the agent to analyze the lead, the malicious prompt came along with normal CRM data. At that point the agent had exactly what it needed: business context plus connected access.

CurXecute: coding agents can become execution paths

CVE-2025-54135, documented in the NVD and analyzed publicly by Cato Networks, pushed the problem into developer tooling. In that chain, prompt injection plus unsafe configuration behavior created a route to remote code execution in Cursor workflows. The core lesson is simple: this is not about an AI saying something silly. It is about an agent having enough write power that manipulated input can change the system itself.

Why this is a business problem, not only a security problem

Security teams will care first, but they should not be the only ones.

First, the same agent that saves time can also increase blast radius. If it can touch customer data, finance flows, internal docs or source code, mistakes get expensive very quickly.

Second, these failures are not always obvious at the start. A poisoned CRM summary or a bad memory entry can look like normal workflow behavior until the data has already moved somewhere it should not have.

Third, the compliance side is no longer theoretical. The European Commission announced that enforcement of additional AI Act rules and transparency requirements begins on August 2, 2026. That does not put every agent deployment into the same bucket, but it does mean logging, oversight and governance are getting harder to treat as optional cleanup work.

What I would lock down first

Prompt guardrails are useful, but they are not enough by themselves. The real controls need to sit deeper in the stack.

1. Put authorization at the data and tool layer

If a user is not allowed to access a dataset, the agent should not be able to fetch it just because the request sounds plausible. Prompt checks help, but they should never be the last line of defense.

2. Require human confirmation for high-impact actions

Money movement, deletion, permission changes, outbound sending and sensitive exports should stop for explicit human approval. The more autonomy you give an agent, the more important those stop-points become.

3. Isolate execution environments

Coding agents, browsing agents and workflow agents should not all share broad network access and long-lived credentials. Sandboxes, scoped secrets and segmentation matter more than beautifully written prompts.

4. Treat external content as hostile by default

Emails, PDFs, tickets, websites, pasted links, metadata and lead descriptions should all be modeled as untrusted input. The real question is not whether they look harmless. The question is whether the agent is allowed to treat them as instructions.

5. Audit memory and persistent state

If the agent can remember things, memory becomes part of the security boundary. You need visibility into what gets saved, what can shape future tasks and when that state is cleared.

The question every team should ask now

Do we still know where control lives?

That is the real management question behind agent adoption. Not which model sounds smartest. Not which demo feels the most polished. Control.

If the agent can read private information, browse hostile content and write or send on your behalf, then you are not rolling out a small convenience feature anymore. You are adding a semi-autonomous operator to your stack.

That is why the risk is worth stating plainly in 2026: a convenient AI workflow can become a Trojan horse inside systems the business already trusts. Not because the agent is evil on its own, but because routine inputs can be turned against it.