The Data Your AI Agent Reads Can Hijack It: What RIAs Need to Know After SalesBleed

Does SalesBleed mean my RIA’s Salesforce environment is vulnerable?

Not necessarily. The specific vulnerabilities disclosed by Zenity were remediated before the research became public, and Salesforce already provides security mechanisms such as Trusted URLs and confirmation controls intended to reduce prompt-injection risk. Salesforce has also recommended requiring confirmation for sensitive custom Agentforce actions.

What SalesBleed exposes is a broader architectural problem that every organization deploying AI agents; from RIAs to Credit Unions, to manufacturing companies; should understand. An agent becomes more consequential when it can read information from outside the organization, retrieve sensitive internal information, use connected tools, and take actions on a user’s behalf. A CRM lead, incoming email, uploaded document, webpage, support ticket, or other piece of external content can become part of the context the model uses to decide what to do next.

That makes the problem much bigger than Agentforce. Your firm may already have AI embedded in Microsoft 365, a CRM, research platforms, meeting tools, email, browser extensions, workflow systems, or vendor applications that received new AI functionality through an ordinary software update. TorchLight’s earlier guide to AI regulation for RIAs and wealth managers addresses that visibility problem from the regulatory side. SalesBleed shows what can happen when the technical side is not fully understood.

How can a web form hijack an AI agent?

This class of attack is called indirect prompt injection. Instead of typing malicious instructions directly into an AI chatbot, the attacker places those instructions inside information the AI is expected to consume: a webpage, document, email, CRM record, or other external data source.

With SalesBleed, Zenity submitted a poisoned lead through Salesforce’s public Web-to-Lead functionality. When an employee later asked Agentforce to help with recent leads, the agent encountered the compromising content during its normal workflow. The research showed that the injected instructions could then cause the agent to query information the employee had not requested and use an output path to exfiltrate it. Critically, Zenity noted that the attack did not need to escalate privileges because the relevant Agentforce subagent already possessed access to both the lead data and account data.

That matters for governance. Prompt injection becomes far more dangerous when the AI already has permission to reach valuable information or perform consequential actions. So, rather than making the model “smart enough” to recognize every malicious instruction, the security goal is to design the surrounding environment so that one bad instruction can’t automatically become a serious business event.

What does AI memory change?

Current research does not establish that an AI agent becomes progressively easier to fool simply because it has completed more legitimate conversations. The real concern is persistence.

In research published by Palo Alto Networks Unit 42, an indirect prompt injection was able to manipulate the long-term memory of an AI agent. In the proof of concept, malicious instructions became part of the agent’s stored memory and were incorporated into later orchestration prompts, allowing the effect to continue across subsequent sessions. Unit 42 was careful to explain that this was not a vulnerability unique to the Amazon Bedrock platform used in the demonstration. It illustrated a broader problem created when agent memory and untrusted content meet.

For executives, the practical implication is pretty straightforward. Memory can increase the value of an AI system because employees do not need to rebuild context every time they use it, but persistent context also needs to be treated as part of the system’s attack surface. Firms should know what an agent remembers, how long that information persists, where it is stored, what can influence it, and how suspicious or incorrect information can be identified and removed.

What does the SEC actually say about AI?

To find out what the SEC’s 2026 Examination Priorities say about AI, check out TorchLight’s RIAs, Wealth Managers & Investment Firms: AI Regulation in 2026.

The SEC has not created a standalone “AI rule” requiring every RIA to maintain a specific AI policy, committee, or standardized technology stack. The Division of Examinations’ FY2026 priorities do, however, make AI a clear exam focus.

For a broader regulatory discussion, we covered the relationship between AI and existing adviser obligations in RIAs, Wealth Managers & Investment Firms: AI Regulation in 2026 and the current Regulation S-P environment in The Reg S-P Clock Ran Out: Then The Breaches Began. The important distinction is that an AI inventory, permission review, and governance framework are practical ways to demonstrate control. They should not be misrepresented as a three-item checklist written by the SEC.

What should your firm review now?

Start with the actual AI footprint, not the policy binder. Identify approved AI platforms, AI features embedded inside existing applications, connected agents and workflows, and known employee use that may sit outside formal procurement. For each system, determine what company data it can reach and whether that access includes customer information, email, documents, CRM records, financial information, or other regulated data.

Next, trace the identity and permissions behind each agent. Determine whose authority the system is operating under, which applications it can reach, whether those connections permit reading or writing, and whether the access is broader than the business purpose requires. SalesBleed is particularly instructive here because the demonstrated attack didn’t need a new privilege; it used access the agent already possessed. Narrowing those permissions will not eliminate prompt injection, but it can materially reduce what a successful injection is capable of doing.

Then examine approval boundaries and external actions. An AI system that summarizes a document presents a different level of risk from one that can send messages, alter records, provision access, delete information, or initiate other consequential actions. TorchLight’s AI and Workflow Automation guidance approaches human review as an operating control: the more difficult an action is to reverse, the stronger the case for deliberate approval before an agent executes it.

Finally, determine whether you can prove what is happening. Useful governance evidence can include approved-use documentation, access and permission reviews, vendor assessments, configuration records, logs, exception handling, training records, incident procedures, and periodic revalidation. A policy stating that an agent should not access sensitive information is much less useful if nobody has confirmed whether the underlying connector can access it anyway.

The Technical Side

SalesBleed is a useful example because the components were ordinary.

1. A public business form accepted external data.
2. An AI agent later consumed that data.
3. The agent already possessed access to additional CRM records.
4. A weakness in output controls then created a path for information to leave the environment.

We are not saying that every CRM form is dangerous or that every AI agent should be disconnected from business data. We are saying that security has to exist around the model as well as inside it. External inputs should be treated as untrusted, agent identities should follow least privilege, consequential actions should have appropriate approval boundaries, outbound destinations should be controlled, and production activity should be logged and monitored. Salesforce’s own security guidance reflects several of these principles through Trusted URL restrictions and confirmation requirements for sensitive actions.

Memory introduces another control surface. If an agent retains information across sessions, organizations need to understand what enters that memory, how long it remains, how it affects future behavior, and how administrators investigate or remove unwanted state. Unit 42’s memory-poisoning research is important precisely because it shows how a successful injection can outlive the chat it first appeared in.

An AI policy can’t tell you what your AI stack can actually do

This is where AI governance becomes a technical exercise instead of a paperwork exercise. A written rule might say that client information cannot be shared with unauthorized AI tools, but leadership still needs to know whether a CRM copilot can retrieve that information, whether an agent inherited overly broad permissions, whether an employee enabled a new connector, whether memory is retaining sensitive context, and whether anyone would see an unusual action after it occurred.

TorchLight’s AI Governance framework begins with that current-state picture: where AI is operating, what data and identities sit behind it, what authority each workflow has, how activity is monitored, and what evidence exists around the controls. From there, governance can be mapped to the firm’s actual environment, not written around assumptions.

For RIAs, that review can also connect the technical findings back to the firm’s broader compliance program, Regulation S-P controls, and annual review process. Firms that need ongoing executive-level ownership can extend that work through TorchLight’s vCISO and vCIO advisory services rather than treating AI as an isolated technology project.