Salesforce agent flaws reveal the hidden cost of AI autonomy

Giving an AI agent access to your CRM feels like a productivity win. Then a researcher finds it will hand that data to anyone who asks in the right way.

In September 2026, security researchers at Zenity Labs revealed that Salesforce's Agentforce platform contained vulnerabilities serious enough to earn the name SalesBleed. The flaws have since been patched, but the incident raises a question every Operations Manager, IT Manager, and Managing Director deploying AI agents should sit with: what exactly can your agent do, on whose instruction, and with what data?

What the SalesBleed vulnerabilities actually did

The Agentforce flaws were a class of attack called indirect prompt injection. An AI agent processes external data as part of its job. A malicious instruction is hidden inside that data. The agent reads it, treats it as a legitimate command, and acts on it.

In the SalesBleed case, the hidden instruction arrived through a public web lead form. An agent with access to the CRM could then be directed to extract contact records and send them outbound, or to craft and deliver phishing messages via connected channels such as Slack. The victim did not need to click anything. The agent did the work automatically, which is precisely what it was built to do.

The vulnerabilities were disclosed responsibly and Salesforce patched them. That is the right outcome. But the attack pattern itself is not unique to Agentforce. It is a structural characteristic of any AI agent that reads untrusted external content and holds permissions to act on connected systems.

Why autonomous agents create a different kind of exposure

Traditional software does what it is coded to do. An AI agent does what it is instructed to do, and the source of those instructions can be ambiguous. That ambiguity is the attack surface.

When a human reviews an email before forwarding it, they apply judgement. When an agent processes the same email as part of an automated workflow, it processes the content of that email as data. If that content contains a hidden instruction, the agent has no inherent reason to distrust it.

This is not a flaw in AI. It is a characteristic of how large language models process text. The flaw is in assuming that an agent operating correctly is the same as an agent operating safely. It is not. An agent can do exactly what it was designed to do and still cause significant harm if the permissions around it are not carefully scoped.

For UK SMEs, the practical implication is this: efficiency gains from AI agents are real, but they arrive alongside a risk profile that traditional IT security frameworks were not designed to address.

What this means for UK businesses connecting AI to live data

Most UK SMEs are not running Agentforce. But many are building comparable setups using other platforms, connecting AI assistants to CRM data, customer communication tools, and internal databases. The attack pattern that SalesBleed demonstrated applies to any of those configurations.

An Operations Manager at a fire safety installer running an AI-powered quoting workflow, or a membership team whose agent reads web form submissions, faces the same structural question: what can this agent read, what can it send, and who can instruct it? If the agent processes inbound emails or web form submissions as part of its workflow, those are potential injection points.

An IT Manager approving a new agent integration with Slack or Microsoft Teams needs to ask whether the agent can be directed via messages in those channels, and what its permissions allow it to do if it is. A Managing Director signing off on an AI agent rollout needs assurance that the efficiency case accounts for the access controls, not just the workflow diagram.

The 80% of AI adoption that is not about technology is about these conversations happening before deployment, not after an incident. The SalesBleed case is useful precisely because it happened publicly, was patched, and is now documented. Many equivalent risks in smaller deployments will not surface in a security research report.

Three practical steps to take this week

1. Map what your active AI agents can access. List every data source, platform connection, and communication channel each agent touches. This does not require technical expertise. It requires someone asking the question and writing down the answer. If you cannot produce that list, you do not yet have the visibility you need.

2. Apply the principle of minimum necessary access. An agent built to summarise inbound enquiries does not need write access to your CRM. An agent that drafts quotes does not need permission to send emails autonomously. Review each agent's permissions against its specific function and remove anything that is not strictly required. This is a 90-minute task for an IT Manager working alongside whoever built the agent.

3. Identify where your agents process external content. Any point where an agent reads data originating outside your organisation is a potential injection point. Inbound emails, web form submissions, third-party data feeds, and public web content all qualify. Flag these points and consider whether a human review step is appropriate before the agent acts on that content.

None of these steps require specialist security expertise. They require the kind of structured thinking that should accompany any significant business process change.

The limitations of patching as a security model

It is worth being direct about something the SalesBleed disclosure illustrates. Salesforce patched the vulnerabilities. That is good. But a patch-and-move-on posture is not sufficient when the underlying architecture connects autonomous agents to sensitive data and outbound communication channels.

Patches address known vulnerabilities. Indirect prompt injection as an attack class will continue to evolve. New injection vectors will emerge as agents are connected to more data sources. Waiting for a vendor to issue a patch is not a security strategy for a business whose agents are processing customer data or operating within a communications platform.

This is also not a reason to avoid AI agents. It is a reason to build them with structural guardrails from the start, rather than adding security thinking after the workflow is already live. The efficiency case for AI agents is genuine. The risk case is equally genuine. Both deserve the same rigour.

Building agents with guardrails, not just outputs

gecco builds AI Agents that combine assistants and automations into end-to-end workflows with quality gates and structured handoffs. Agent design follows the GRAFT methodology, which defines the goal, role, audience, format, and tone of each assistant before it is connected to any data source. Each agent's access is then scoped to its task, which limits what it can read and act on and reduces the surface area for unintended behaviour.

If your team is assessing where AI agents actually fit in your operations, and what the access controls around them should look like, the AI Readiness survey is built to surface exactly that. Taking the survey gives you access to 65+ free resources and a custom AI Readiness report, followed by a free 30-minute showcase to walk through the results with a gecco adviser.

Website · LinkedIn · Case Studies · Newsletter