In July, HubSpot's MCP server asked the AI model a question. Not the customer. The model. According to Chris Penn of Trust Insights, the question was, roughly, what else are you working on. And the agent, being an agent, being helpful, answered.
There was no breach. No exfiltration endpoint, no stolen credential, no field mapping in a data processing agreement anybody could point at. There was a sentence, and a cooperative model holding your credentials, and a vendor who thought to ask. HubSpot reversed the underlying terms change days after it became public, which is to its credit and beside the point.
The point is the mechanism.
The pipe became a sentence
For thirty years, the way a vendor got your data was a pipe: a defined API, named fields, a contract that listed them. You could audit a pipe. You could draw it on a whiteboard. What replaced the pipe is a paragraph of natural language you have never seen, sitting inside a product you have already paid for, instructing a model that has already been granted your access.
Penn puts the whole thing in nine words: "When you install an MCP, you are connecting to somebody else's computer."
Connecting an MCP server is not adding another tool. It is introducing an external system to your AI environment and letting the two of them talk. Three things travel across that connection, and only one of them is data.
The first is access, which is the part everyone already thinks about, badly. The second is actions, meaning what the integration is permitted to actually do rather than merely read. The third, the new one, is instructions. Somewhere in that vendor's server is text telling the model what to do, what to ask for, what to volunteer. That text is a product decision made by a company whose revenue does not come from your discretion, and it is invisible by default.
Marketing has no reflex for this, and it is not marketing's fault. Nothing in the discipline's history prepared anyone to read a system prompt. As Clark Barron of Blackout put it, marketers and sales professionals "are not technical enough to know that there are red flags even happening that they should be aware of." That is a description of a training gap, not a character flaw. The problem is that the gap now sits directly upstream of every customer record the company owns.
And note where the authorization actually happens. It is not in procurement. It is not in a security review. It is a marketing manager, on a Tuesday, four seconds after a consent screen appears, clicking the blue button so the demo can continue. That click may be the single highest-privilege decision anyone at the company makes that week, and it is the only one with no approver, no ticket, and no record.
Software that knows when it is being watched
Barron's research is the uncomfortable part, and it should be read with his commercial interest fully in view: he founded Blackout, which sells forensic analysis of marketing software, so he is a man who profits from you being alarmed. Weigh it accordingly. Then weigh what he says he found.
He describes finding, in a vendor's source code, what he calls "an actual defeat device" / code that checked whether it was being inspected, called one server if it detected automated analysis or a compliance audit, and called a different one if it decided it was looking at a normal visitor. Volkswagen, but for tracking scripts. He says he has analyzed over 700 vendors "and it's growing by the day, and no one's clean."
Set aside whether that number holds across the whole market. The structural claim is what matters, because it invalidates a defense most companies are quietly relying on. If software can behave differently when it believes it is being observed, then "we tested it and it looked fine" is not evidence of anything. Point-in-time verification stops being proof and becomes a mood. What survives is the boring stuff: what you granted, what the vendor committed to in writing, what you can revoke, and what you logged.
Barron's business argument is sharper than the security one. His claim is that vendors take far more than the product requires, aggregate it, and sell derivatives back into the market, including to your competitors. His words: intent data is "your own data just being repackaged and sold back to you." The failure mode is not a headline. It is your attribution dashboards slowly beginning to lie, your acquisition costs climbing, and nobody able to name the reason. There is no incident report for that. There is no day it happened.
What is in the box
Penn's recommendation is the most useful sentence in the entire package, and it is almost embarrassingly simple. Ask the vendor for the prompt.
"So what companies, marketers, and everybody should be saying is, 'What is in the box, and can I get a copy of it?'" Penn said. Tell the vendor: "You have to send me the prompts for your MCP that you're running. You just have to. It's part of governance."
Nobody in marketing asks this. It is not on any vendor questionnaire we have ever been sent, and we have been sent a lot of them. It should be on all of them, for a reason that has nothing to do with the answer: the request itself is the test. A vendor that hands over its MCP instructions and its tool list without drama is telling you exactly what kind of company it is. A vendor that treats the question as unreasonable is also telling you, more usefully and at no cost to you.
For the actual review, Penn points at the OWASP Top 10 for Large Language Model Applications as the baseline checklist, and makes the point that you can run the first pass with the same AI you are worried about. Feed it the vendor documentation, the prompt if you got one, and the OWASP list, and let it flag the obvious. His estimate: "If you don't have a security team of any kind, this at least gets you like 70% of the way there. It helps you eliminate the obvious risks."
Seventy percent is not a security program. It is also infinitely more than zero, which is the current number at most marketing departments, and it costs an afternoon.
Verify first, then trust
Barron's phrasing inverts the industry's default posture and is worth stealing outright: "Verify first, and then trust. When it comes to authorizing connections to your database, all of these vendors that are asking for access to your company's information / ask them. Push them. And actually get it in writing."
Get it in writing is the load-bearing clause. A sales engineer's verbal assurance on a call is not a control. Six checks he recommends starting every vendor review with, translated into what they actually mean on a Tuesday:
Restrict read and write on CRM objects like pipelines and deals unless the product genuinely cannot function without them. Write access is the one that gets waved through because it makes the demo smoother.
Block access to employee and executive records. They usually live in the same system as customer records, which means one grant scoped at the object level and not the record level hands over the org chart.
Review the Gmail and Outlook extensions that bridge inboxes to the CRM. These are the quietest and the widest. An inbox grant is a grant to every conversation anyone has ever considered private.
Monitor persistent access tokens. A token with no expiry is a permanent relationship with a company you may have stopped paying twelve months ago.
Restrict support tickets and internal service records. This is where customers describe their problems in their own words, which is precisely why it is valuable to somebody building a data product.
Scrutinize any vendor bypassing the official marketplace with a custom OAuth implementation. There are legitimate reasons. There is also a reason marketplaces have review processes, and the vendor who routes around them has chosen to skip that review.
None of that is exotic. All of it is unowned.
Why this lands on marketing
Finance does not work this way. Nobody in accounts payable connects a new system to the general ledger on a Tuesday afternoon because a webinar was persuasive. HR does not grant a vendor read access to personnel files on the strength of a free trial. Both of those functions long ago accepted that their systems are infrastructure and that infrastructure has gatekeepers.
Marketing never made that transition, because marketing's tools arrived as apps rather than as systems, one at a time, each individually small, each purchased on a card and connected in a minute. The stack got critical without ever getting reclassified. The consent screen is a purchase order that skips procurement, and it always has been. AI did not create that gap. It just raised the stakes of standing in it, because the thing on the other side of the grant can now read, decide, and act.
The fix is structural and slightly boring: every application that touches CRM, customer data, or an AI environment gets reviewed by marketing, security, procurement and legal against the same short question list. What data does it reach. What permissions does it want. Does it use subprocessors. If it is an AI integration, what are the instructions in its MCP server. If those cannot be answered, it does not get connected until they can. That does not slow adoption down. It makes adoption a decision the company made, rather than one an individual made on its behalf.
What it looks like when it is built in
We have built the inverse of this problem, so the position is not theoretical. On the Autonomi platform, the dealer owns the ad accounts, the analytics property and the tag container, and the platform operates through delegated access against accounts it does not own and cannot take with it. Floof Digital was the platform engineering partner on that build, so treat this as a vendor describing its own work. The design decision worth generalizing is that the grant is scoped, revocable by the customer at any time and without our cooperation, and every action against it lands in an audit trail the customer can read. Revocation is the test. If a vendor's product stops working when you revoke and nothing else breaks, that is what correct looks like.
The same rule points back at us. Our own internal assistant reads mail, drafts replies and files notes across four businesses, and it ships with outbound sending held by default, with the tools that can take an action gated separately from the tools that can only read a fact. That is not caution about the model. An assistant with read access is a productivity tool. An assistant with unattended write access is a vendor with a key. We wrote the prompt, and we still gate it.
The playbook
DMAIC at the strategic layer, disciplined delivery underneath. Six moves, in the order we would run them. These are about grants you extend to third parties, which is a different problem from governing the applications you generate internally / that one we covered in Data Never Leaves.
Make the consent screen a purchase order. Any grant to a system holding customer data, employee data or an AI environment goes through the same approval path as spend of equivalent risk. One form, four signatures, four questions. The point is not the friction. The point is that the decision acquires an owner and a date.
Inventory the grants you already made, and test the revoke. Pull the connected-apps list from every platform. For each one: who authorized it, when, why, what it reaches, and is anyone still using it. Expect to find integrations from tools you stopped paying for. Then do the part nobody does and actually revoke three of them, to find out whether you can and what breaks. An untested revoke is a theory.
Ask for the prompt and the tool list, in writing, before you connect. For any MCP or agentic integration: the system prompt, the enumerated tools, and what the model is instructed to request or volunteer. Attach it to the contract file. Run it against the OWASP LLM Top 10. If the vendor will not provide it, you have your answer and you got it for free.
Scope by record, not by application. Read-only until write is proven necessary. Employee and executive records excluded by default. Support tickets excluded by default. Where the platform allows field-level or object-level scoping, use it, and accept that the integration will be slightly less magical. Magical is a synonym for broadly permissioned.
Put an expiry on every token. Persistent access with no renewal date is the default and it is the wrong default. Give every grant an expiry and a re-consent cadence, so that continued access requires someone to actively decide it should continue. Access that survives on inertia is the entire attack surface described here.
Re-audit on change, not on the calendar. Quarterly reviews find quarterly problems. Permissions change, terms of service change, MCP servers get updated, and features get added between your reviews. Set the trigger on the event rather than the date: a permission scope change, a terms of service update, a new AI capability in a tool you already connected. Require the vendor to explain any expansion before it takes effect, and make that a contract term rather than a hope.
Our position
The industry spent a decade telling marketers that first-party data was their most valuable asset, and it was right. It then built an integration culture in which that asset is handed out through a four-second consent screen by whoever happens to be running the trial, and nobody thought the two facts were related.
What is different now is not that vendors became less trustworthy. It is that the interface between your systems and theirs stopped being a pipe you could inspect and became a conversation you were not invited to. When the connection carries instructions as well as data, the vendor's prompt is a term of the agreement, whether or not anyone negotiated it.
So negotiate it. Ask what is in the box. Ask for a copy. Put the answer in the file next to the data processing agreement where it belongs, and treat a refusal as the disclosure it actually is.
As Penn says, there is no excuse anymore: "There is no excuse for any marketer to install unsafe software anymore without at least a cursory audit with things like the OWASP Top 10 LLM risks." The tools to do this are on your desk. The only thing missing is the decision that it is somebody's job.
Reporting by Constantine von Hoffman for MarTech (August 7, 2026) and MarTech (August 5, 2026). All quotes from Clark Barron of Blackout and Chris Penn of Trust Insights are as published there. MarTech is owned by Semrush.