Why intent data integrations need closer access controls

A marketing tool can give a company intelligence about buyers while gaining access to the company’s own data. When the tool connects to systems containing customer records, pipeline data, service tickets, emails, or internal communications, those permissions become part of the procurement decision. Executives need to assess the commercial value of the information a vendor can access alongside the value of the service they are buying.

Clark Barron, founder of Blackout, alleges that some marketing technology vendors use customers’ CRM and internal information in commercial data products. Blackout provides GTM threat intelligence through forensic analysis of marketing software, so the company benefits commercially when buyers see hidden software behavior as a risk requiring investigation. Barron’s allegation is serious enough to examine, but it requires evidence tracing data from a customer system through the vendor and into a product available to another customer.

The data cost of a marketing integration

Marketing procurement starts with an expected business outcome. Each purchase raises a practical question about what information or action the software provides. An integration raises another question: what company information must the vendor access? A CRM connection can expose customer and pipeline fields within its permissions, while connections to support or communication systems can expose information within the scopes granted to the application. Procurement should identify the purpose of each material permission and the rules governing subsequent use.

The issue extends beyond personal data. Pipeline status, customer requests, support issues, and internal discussions can have commercial value when a connected system has permission to read them. Executives therefore need to classify sensitive business information during an integration review. The actual permissions granted to each application determine the exposure.

Martech access is a security and competitive-intelligence decision

Chris Penn, co-founder and chief data scientist at Trust Insights, describes a gap in how marketers think about connected software. “[Marketers] don’t ever think, ‘Gosh, this thing is interacting with my data. I wonder what it’s doing with my data,’” Penn said. His observation draws a useful distinction between choosing a vendor and governing the data access granted to its software.

Barron questions why an intent-data provider would require extensive access to a customer’s own data to provide its service. The question does not demonstrate misuse. It gives procurement a concrete test: each significant permission should have an operational purpose the buyer can identify.

The verification gap makes risk difficult to price

Vendor documentation and contracts describe promised or permitted behavior. A buyer still needs evidence about what an installed integration actually sends or receives. Barron says Blackout uses forensic analysis to compare vendor descriptions with software behavior after installation. He claims to have analyzed “over 700 vendors.”

He also makes a sweeping claim about the market: “There are a few analytics platforms, not attribution, but analytics platforms that are as clean as it gets, but when you venture into the realm of actual marketing software, like ABM vendors, intent data providers, all of that, de-anonymization, absolutely not. No. No one’s clean.” That market-wide characterization should not be treated as a finding without evidence supporting the tested population, methodology, and meaning of “clean.” The claim can justify further investigation only after its factual basis is examined.

Barron gives a more specific example involving an unnamed de-anonymization vendor. He says he found source code that contacted two different servers depending on whether the software detected signs of inspection. He alleges that tracking was disabled during automated analysis or compliance auditing and operated when the code detected what appeared to be an ordinary visitor. Barron called it “an actual defeat device in the source code.” Such behavior, if independently established, would make some inspection results less representative of ordinary operation.

Barron makes a broader downstream allegation. “[They’re] taking all of your CRM data, all of your internal communications, every single byte of data that they can get on your company, laundering it through their own aggregation machines, and then just selling it back to your competitors,” he said of intent-data providers. Establishing that allegation would require evidence tracing customer information through aggregation and into a commercial product available to a competitor.

Barron also says, “Their attribution dashboards start lying to them. Their customer acquisition costs start going through the roof, and they don’t know why.” He further argues that companies can end up subsidizing competitors’ customer-acquisition costs. Executives need evidence connecting specific data practices to attribution errors or customer-acquisition costs before treating the asserted effects as established.

The narrower procurement issue does not depend on those broader allegations. When an integration can access commercially sensitive information, the buyer needs to understand its permissions, permitted uses, and observable behavior. Those facts determine the exposure created by the integration. Barron’s claims raise questions for investigation; they do not supply the answers.

AI connections extend the access question

Model Context Protocol (MCP) is a protocol for connecting AI applications with external tools and data sources. “When you install an MCP, you are connecting to somebody else’s computer,” Penn said. Penn argues that unknown MCP instructions can create a risk of data exfiltration, meaning data leaves an environment without the intended authorization. His warning identifies a scenario for security review rather than evidence that such exfiltration is widespread.

AI integrations make access review part of both technology governance and procurement. A buyer evaluating an AI connection needs evidence about what the connection can reach and what it actually exchanges. That evidence determines whether the integration’s business value is worth the information access granted to it.

Main highlights

Audit the data cost of integrations: Procurement teams should map each martech permission to a clear business purpose and classify the CRM, pipeline, support, and communications data it exposes.
Treat martech access as a security decision: Security and procurement teams should examine whether an integration’s requested access is necessary for the service delivered and how the vendor is permitted to use that information.
Verify software behavior independently: Contracts and documentation describe expected behavior, while technical inspection can test what an integration actually sends and receives. Broad claims about data misuse require evidence tracing information from customer systems into downstream products.
Apply the same scrutiny to AI connections: Technology teams assessing MCP and other AI integrations should determine what systems each connection can reach and what data it exchanges before granting production access.