Poisoned pipelines: securing the B2B AI supply chain in RevOps

Revenue teams know the word pipeline as a number. It is also a description of how their systems are built. A lead arrives through a form, is enriched by one vendor, scored with data from another, and written to the CRM, where another system reads it and drafts a message. Each step trusts what the previous step produced.

That was tolerable when the last step was a person. A sales rep who sees a strange note in a lead record ignores it. An AI agent reads the same note as text to be processed, and if the note is written as an instruction, the agent may follow it. The agent also holds credentials, so it can act on what it read.

The systems did not get worse. The reader at the end of the pipeline changed, and the inputs were never designed for that reader.

What the AI supply chain is in a revenue stack

In software, a supply chain is everything you ship that you did not write. For an AI agent doing revenue work, it is everything the agent depends on that someone else supplied. There are five links, and each has its own way of being poisoned.

The categories come from the OWASP Top 10 for LLM Applications, whose 2025 edition lists prompt injection first, supply chain third, data and model poisoning fourth, and excessive agency sixth. NIST covers the same ground in its adversarial machine learning taxonomy, published in March 2025. Neither document is written for revenue teams. Both describe their stack precisely.

The links fail independently, but the damage travels. A poisoned input at link two does nothing until it reaches a credential at link four and an action at link five. That is where the defense lives: the contamination has to stop before it becomes an action.

Three incidents, three links in the chain

Three disclosures from the second half of 2025 each attacked a different link, and each landed in the revenue stack. The vendors involved are not named here. They are identified in the linked sources, which also report that each issue was remediated.

Credentials: tokens stolen from a supplier

In August 2025, Google’s Threat Intelligence Group reported that an actor it tracks as UNC6395 had used OAuth tokens belonging to a third-party sales application to reach the CRM instances of that application’s customers. The activity ran from August 8 to August 18. The actor queried accounts, opportunities, users, and cases, then searched the exported data for cloud access keys, passwords, and data warehouse tokens.

The advisory stated that the issue did not stem from a vulnerability in the core CRM platform. Nothing was broken. The tokens were valid and the queries were permitted. Two days later the scope widened, and customers were advised to treat every token connected to the application as potentially compromised. People paste credentials into CRM records, and the actor knew it.

Data: instructions hidden in a web form

In September 2025, Noma Security disclosed a vulnerability chain in a CRM-native AI agent, rated 9.4 on the CVSS scale. The researchers submitted a web lead form with instructions written into the description field, which accepted up to 42,000 characters. Nothing happened until an employee asked the agent to review that lead. The agent treated the hidden text as part of its task and returned CRM data inside an image address pointing at a domain on the platform’s allowlist.

That domain was still trusted, but its registration had lapsed. The researchers bought it for five dollars. The vendor enforced trusted-address controls before public disclosure. The attacker needed no access, only a form that anyone can fill in. Every B2B company has one.

Tools: a connector that changed its behavior

Also in September 2025, Snyk reported a package on a public registry that presented itself as an email-sending connector built for the Model Context Protocol, which agents use to call tools. Fifteen versions worked as described. The sixteenth added a blind-copy field, which sent a copy of every outgoing email to an address controlled by the publisher. An agent using it would have sent exactly the emails it was asked to send, and every test would have passed.

Registries: code that arrives as data

Public registries are downloaded from on trust. In February 2024, JFrog reported about 100 models in a public model repository that carried harmful payloads. Most were built with a framework that stores models in Python’s pickle format, which can run code when a file is loaded. In December 2025, JFrog disclosed three vulnerabilities, each rated 9.3, that let a malicious model pass a widely used open-source scanner. A fix had shipped three months earlier.

In February 2026, Koi Security audited 2,857 skills in a public registry for an AI agent and found 341 that were malicious. Most belonged to one campaign and posed as finance and productivity tools. The payload was not in the code. The documentation told the user to install a prerequisite, and the prerequisite was the malware.

Models: the link that is hardest to inspect

Poisoning can also happen before a model file exists. In October 2025, researchers from Anthropic, the UK AI Security Institute, and the Alan Turing Institute reported that a small, roughly constant number of malicious documents was enough to plant a backdoor in a language model, regardless of its size.

The caveats belong with the number. The backdoor tested made a model produce meaningless text on a trigger phrase, and the authors say it is unclear whether the pattern holds for larger models or more harmful behaviors. It matters if you fine-tune a model on records that outsiders can write into.

Why the revenue stack is the soft target

The revenue stack has three properties that make it attractive. It is built to accept input from strangers. A lead form, a reply-to address, and an event list upload all exist to let people you have never met put text into your systems.

It holds broad credentials. A typical revenue stack is a CRM with a long tail of connected applications, each granted access when someone needed a feature and rarely reviewed afterwards.

It acts in public. A poisoned instruction in a back-office analytics job produces a wrong chart. The same instruction in a revenue workflow produces a message to a customer under your domain, or a quiet change to the data your forecast is built on.

Exposure to untrusted content, access to private data, and the ability to communicate externally: any two are manageable. All three in one workflow is how the web form incident worked.

Poisoning without a breach

Not every poisoned pipeline involves an attacker. Intent data is derived from behavior, and behavior can be manufactured. Review content, firmographic records, and job postings all feed scoring, and all are written by parties with their own interests. When they are wrong, an agent prioritizes the wrong accounts and the sending domain’s reputation pays for it. Nothing was breached, so nothing alerts.

Two design choices limit this. Compute scores with deterministic code, so a score can be traced to the records that produced it. Source signals through licensed providers, so someone is accountable for provenance. CRM data debt used to cost effort. With an agent reading the record, it is a control problem.

Seven controls, mapped to the chain

None of these controls is new. What is new is that they apply to the revenue stack, and that RevOps owns several of them.

Inventory. For each connected application, record what it does, who asked for it, which scopes it holds, and when it was last used. Remove what nobody can explain. This control decides whether an incident at a supplier costs you an afternoon or a quarter.

Identity. An agent running under a shared service account cannot be revoked without collateral damage. OWASP lists least-privilege access among its mitigations for prompt injection, because an injected instruction can only use the access the agent already has.

Inputs and tools. Form fields, replies, and enrichment records are content, not instructions. Test the separation with a harmless instruction in a sandbox. Pin connector versions and review updates before production: the change in the connector incident arrived in a routine release. For model files, prefer a format that cannot run code on load, such as Safetensors, and do not rely on a single scanner.

Egress. Exfiltration needs a destination. Review the list of addresses agent output can reach, and check it for lapsed domains.

Authority. OWASP recommends human approval for high-risk actions. Revenue teams need two modes, because approving every action does not scale and approving none is not a control.

Approval has limits. A reviewer can reject a message that looks wrong. They cannot see data leaving through a channel nobody reviews, which is why this control sits beside egress and not in place of it.

Evidence. A record reconstructed after an incident is an estimate. A ledger written at the moment of each action is evidence. Then run the drill: revoke one integration, rotate what it touched, and time it.

Who owns it: RevOps and the CISO

The controls fail at the boundary between two teams, so the boundary has to be written down. Security owns the standard and the review of any new integration. RevOps owns the inventory and the governance decisions, because it is the only team that knows which integrations exist and why. Neither usually holds a current list of what is connected to the CRM, with what scope, on whose authority. When a supplier’s tokens are stolen, that list is the difference between an afternoon of revocation and a search.

The vendor owns what happens inside its own platform. You cannot operate those controls, but you can ask for them in writing. The governance questions to ask an AI agent vendor and the items a security review actually checks are a working list.

One meeting settles most of this. Put the head of RevOps and the CISO in a room with the connected-applications export, and go through it line by line.

A 30-day plan

Days 1 to 7: inventory. Export connected applications and tokens from the CRM and the email platform. Record scope, owner, and last use. Revoke what is unused. Search case and note fields for pasted credentials and rotate any you find.

Days 8 to 15: inputs and tools. List every place an outsider can put text into your systems. For each AI feature or agent that reads those fields, ask the vendor how external content is separated. Pin connector versions and record publishers.

Days 16 to 23: authority. List the action classes your agents can take. For each, decide the governance mode and name the owner. Narrow any scope that is wider than the task.

Days 24 to 30: evidence. Confirm that actions are logged as they happen, with before-and-after state. Run one timed revocation drill. Write down what took longest, and fix that first.

Where governed digital labor fits, and where it does not

MatrixLabX builds PrescientIQ™, so it is fair to ask what our own platform does about the chain. Each agent runs under its own least-privilege identity. Scores are computed by sandboxed deterministic code. External systems are reached through typed, scoped tool integrations, and inbound surfaces are treated as untrusted input. Every action, in either mode, is recorded to the audit ledger with its rationale, before-and-after state, and the approver or policy behind it.

A platform like ours is also a link in your supply chain. If you connect it to your CRM, it holds credentials to your system of record, and everything in this article applies to us. Ask for the scopes, the sub-processors, and the data-handling terms in writing.

PrescientIQ is hosted and operated by MatrixLabX on Google Cloud. SOC 2, ISO 27001, and PCI DSS attestations are held by Google Cloud, which operates the underlying infrastructure. They are not MatrixLabX certifications. MatrixLabX application-layer SOC 2 is in progress.

No platform removes supplier risk, and governance does not detect a poisoned input on its own. It changes how far the contamination travels. What we claim, and what we do not, is on the AI trust and governance page. The Agentic Readiness Audit scores governance, non-human identity, data readiness, and the evidence trail, which are the dimensions these controls fall under.

The revenue stack became a supply chain gradually, one integration at a time, and nobody decided it should be one. The work now is to treat it as what it is.