Written by Jeremy Souffir Founder, JTS Tech Services
The short version: on 9 September 2026, at its K:BOS customer conference, Klaviyo announced that it has opened its platform to AI systems it does not own. More than 260 Klaviyo tools and capabilities and more than 490 APIs are now callable directly from Claude, ChatGPT, or any AI system a team already runs, and an agent on the other end of that connection can read your customer data, write to it, and put a campaign live without a person ever opening Klaviyo. If you sell on Shopify or WooCommerce, this is almost certainly the most consequential thing that happened to your stack this week, and it is consequential in a way that has nothing to do with security in the usual sense. Nothing here is a breach, a flaw or an exposure. It is a capability, working exactly as designed, and it is a good one. The point worth your attention is narrower and stranger: for as long as you have had a mailing list, sending to it required a human being sitting in a screen. Nobody ever wrote that down as a control, because it was not a control, it was just the way software worked. It has been quietly doing the job of one anyway, and this announcement is where it stops.
What exactly did Klaviyo announce?
Here is what is actually on the record, taken from Klaviyo's own K:BOS write-up and the trade coverage of it. Klaviyo's framing for the whole set is that the platform is going headless — reachable from wherever the work is happening rather than only from inside its own interface.
- The date is 9 September 2026, at K:BOS, Klaviyo's annual customer conference. In Klaviyo's own words, "more than 260+ Klaviyo MCP tools and capabilities are callable directly from Claude, ChatGPT, or any AI system". Independent coverage puts the API surface at more than 490 endpoints.
- The capability is not read-only, and this is the part to slow down on. Klaviyo describes agents that can read, write and publish campaigns without opening Klaviyo's interface. The worked examples it gives are ordinary and appealing: building a live reporting dashboard in a tool like Cursor or Lovable, automating a weekly performance review that posts its findings into Slack, drafting a campaign through ChatGPT.
- SQL has arrived inside the Klaviyo Data Platform, in preview, reachable through both Composer and MCP. A marketer asks a question in plain language and Klaviyo translates the prompt into the query. Profiles, events, segments, lists, campaigns and catalogs are queryable today; forms, flows, templates and custom objects are described as coming, as is Claude and ChatGPT support for the SQL layer specifically.
- Klaviyo puts the scale of what sits behind that query surface at more than 4 billion signals a day across 9 billion profiles. That is the company's own figure for its own platform and we are repeating it as such, not as an independent measurement.
- Co-founder and co-CEO Andrew Bialecki framed the reasoning this way: "An agent is only as useful as three things; whether it understands a brand's data, whether it can reach that understanding from wherever it's running, and whether it can act on it for every individual customer." Note the third clause. The pitch is explicitly not about an agent that reports. It is about an agent that acts.
- Klaviyo's developer documentation says the MCP server is compatible with any MCP client that supports remote servers, and names Claude, ChatGPT, Cursor and VS Code among them. This is not a private integration with one AI vendor. It is a door with a standard shape.
Isn't this just the AI Klaviyo already had?
No, and the distinction is the whole story. Klaviyo has had AI features for a long time, and it has had an MCP server for a while too. Those were all instances of the same shape: intelligence delivered inside Klaviyo's product, on Klaviyo's screens, governed by Klaviyo's own idea of who is allowed to press what. If a feature could send an email, it did so in a place where a person with a login was standing there, and every account has a rough, unstated sense of who those people are.
What was announced this week points the other way. The agent is not in Klaviyo. Klaviyo is in the agent. The thing holding the connection is a chat client, an IDE, a script somebody wrote on a Thursday, or a scheduled task in a tool your marketing coordinator found last month — and none of those have a Klaviyo user, a Klaviyo role, or a Klaviyo permissions screen. They have a credential. Everything the far end is allowed to do to your customer list is decided by what that credential carries, and by nothing else, and the interface where a person used to be standing is no longer on the path at all.
Whose announcement this is, and what it does and does not say
This is a product announcement made at a vendor's own customer conference by a company whose commercial interest is served by you believing your marketing platform should be reachable from every AI you run. That is a real reason to read it carefully and we are not going to pretend otherwise. Three limits are worth holding. First, several of the headline pieces are explicitly previews rather than shipped general availability — the SQL layer is in preview through Composer and MCP, and Claude and ChatGPT support for that layer specifically is described as coming, not present. Preview features move, get renamed, and occasionally do not arrive. Second, the tool and API counts are Klaviyo's own, and a count of tools is not a measure of usefulness; a hundred of them may be narrow variations you will never call. Third, and worth saying plainly because it is the one people will reach for: the announcement itself does not discuss authentication, permissions or security at any length. That is not a scandal and it is not a gap in the product — the permission model is documented properly in Klaviyo's developer docs and help centre, which is where such things belong. But it does mean that the material your marketing team will read, and the material that describes what an agent is allowed to do to your list, are two different documents, and only one of them is being presented at a conference. So why do we still think this is the week's most useful story for a merchant? Because unlike most vendor news, every claim in it is checkable by you, today, in your own account, in about twenty minutes. That is rare enough to be worth acting on.
So where does the approval step actually live now?
In a table of permission scopes, and you can go and read the exact table Klaviyo publishes. Its developer documentation for the MCP server sets out the access needed for the full toolset, and the responsible thing to do is quote the shape of it rather than characterise it. To use all available tools, the documented scope set includes Profiles at full access, Events at full, Segments at full, Subscriptions at full, Templates at full, Images at full, Translations at full, and Campaigns at full — alongside a set of read-only scopes for accounts, catalogs, flows, lists, metrics and tags.
Read that list once more with a merchant's eye rather than a developer's. Campaigns at full access is the permission to create and send. Subscriptions at full access is the permission to change who is on the list and who has consented to hear from you. Profiles at full is the permission to alter customer records. Those three, held together by a single credential in a client outside your platform, add up to a connection that can compose a message, decide who receives it, and send it — which is precisely the point of the feature, and precisely why the scope decision deserves more than the four seconds it usually gets during setup.
- Klaviyo does the identity part properly, and this deserves saying first. The MCP server authenticates over OAuth with dynamic client registration rather than asking you to paste a long-lived secret into a chat window. That is the good version of this, and it is materially better than the pattern we keep finding in the wild.
- But scopes are still yours to choose, and Klaviyo offers three shapes for a private key: read-only, full, or custom. Custom is the one that matters and it is the one that gets skipped, because at setup time "full" is the option that makes the error messages stop.
- A key cannot be re-scoped later. Klaviyo's help centre is explicit that after a private API key is created you cannot add or edit its scopes — if the access is wrong, the remedy is to delete that key and create a new one. Which means every over-scoped credential you have is permanent until somebody goes looking for everything that depends on it.
- And you cannot read the key back. Klaviyo does not let you view a private API key again after creation, by design. So the question "which of our integrations is using this one?" cannot be answered by inspection later. It can only be answered by a record someone kept at the time, and in most businesses no such record exists.
- Only an Owner or an Admin can create, clone or delete a private API key. That is a genuine control and it is worth knowing you have it. It is also worth knowing how many people in your account currently hold one of those two roles, because that number is usually larger than the person who set it up remembers.
The two conclusions that both get this wrong
The first wrong conclusion is to treat this as a threat and shut the door — no MCP, no outside AI touching the marketing platform, revisit next year. It feels prudent and it is the more expensive mistake of the two, for a reason that has nothing to do with missing out on a capability. The sanctioned path here is OAuth with dynamic client registration and a granular scope table, which is a genuinely well-built front door. Refusing to use it does not mean nobody connects an AI to your customer data; it means the person who wants a weekly report badly enough goes and creates a full-access private key and pastes it somewhere you will never audit, and you have traded a governed connection for an ungoverned one while believing you tightened something. The second wrong conclusion is the mirror image and it is the more common: it is OAuth, the vendor is a serious company, the permission model is documented, therefore this is handled. It is handled in exactly the half that Klaviyo owns. The half you own is which boxes get ticked, by whom, and whether anyone can still name what each existing credential is for — and that half is not improved by the vendor doing good work, because the vendor is not the one deciding whether your connection needs Campaigns at full access or would do its job perfectly well with read. Both mistakes come from the same reflex: filing this under security, where the answers are yes and no, when it is an operations question, where the answers are who, which, and how would we know afterwards.
What would we actually do this week?
- List every private API key on the account and put a name beside each one. Not a system, a person. The useful output is not a count of keys, it is the discovery of the two or three nobody can account for, and that discovery is usually available within the first ten minutes.
- Decide, deliberately and in advance, whether any agent should hold Campaigns at full access. There is a strong case for yes and a strong case for no, and either is defensible — what is not defensible is arriving at it by accident because full access was the setting that made a tool stop complaining during setup. Plenty of genuinely valuable uses, reporting dashboards and weekly performance reviews among them, need nothing beyond read.
- Separate the credentials by job rather than by convenience. One key for the reporting agent with read scopes, a different key for anything permitted to publish, so that revoking the noisy one does not take down the important one. This costs a few minutes now, and it is the entire difference between a contained problem and an outage, because keys cannot be edited after the fact.
- Write down what each key is for at the moment you create it, somewhere that is not a chat message. You cannot read a Klaviyo private key back after creation, so the record you keep at that moment is the only record that will ever exist. This is the single highest-value habit on this list and it takes about fifteen seconds per key.
- Check who holds Owner and Admin on the account, since those two roles are what gate key creation. Most accounts have accumulated more of them than anyone intends, usually through agencies, contractors and departed staff, and this is a five-minute review with a permanent benefit.
- Decide what a sent campaign requires before it goes, and say it out loud in a sentence. "An agent may draft and schedule; a named human approves the send" is a perfectly good policy and takes one line. The reason to write it now is that until this week the software was enforcing something like it for you by accident, and it has stopped.
- Do not build anything on the preview features yet. The SQL layer is in preview and its Claude and ChatGPT support is described as forthcoming. Experiment freely, but keep it away from anything a person in your business is relying on this quarter.
The genuinely encouraging part
Set aside the caution for a paragraph, because the underlying news is good and it is unusually good for smaller merchants. Start with what the vendor got right: this arrived as OAuth with dynamic client registration and a granular, documented scope table, at a moment when the industry norm is still a long-lived secret pasted into a config file. That is a platform doing the hard part properly and handing you a real choice rather than a single on switch, and it is worth noticing when a vendor does this, because plenty do not. Then there is the shape of the work it leaves you, which is the part that genuinely favours you. Everything on the list above is a one-afternoon job for a business your size. You have one marketing platform, not fourteen. The number of private API keys on your account is a number a person can read off a screen, and the number of people holding Owner or Admin is small enough to fit in a sentence. An enterprise facing exactly this announcement is looking at a permissions review across dozens of connected systems, several agencies and a governance committee that meets monthly; you are looking at one screen and one decision, and you can be finished before lunch. There is a real prize behind that afternoon, too, because the capability itself is the good kind: a marketer who can ask a question in plain language and get the answer out of nine billion profiles, without waiting a week for someone to build the report, is a genuinely faster business. The work is small, it is available to you now, and doing it first is what lets you say yes to the rest of it without flinching.
Where we fit
The honest answer is that if you can already produce a list of every credential touching your customer data, with a named owner and a stated purpose against each, you do not need us for this and you should spend the afternoon doing the review yourself. It is not difficult work. What makes it not get done is that it belongs to nobody in particular: it is too technical for the marketing team who use Klaviyo daily, too unfamiliar to the developer who has not opened that account since the integration went in, and too invisible to reach anyone's quarter. So it waits, and every new connection makes the eventual reckoning slightly longer, and the answer to "which of these keys can send to the list?" gets harder rather than easier with time. That is the specific gap an AI Ops Automation Sprint is built to close. We inventory every integration and scheduled job touching your customer and product data, name an owner and a credential for each, separate the ones that need to publish from the many that only need to read, surface the ones running on momentum alone with nobody left who knows what they do, and leave monitoring behind on the paths that matter. Klaviyo has just made your customer list reachable from every AI your team runs, which is a real gift and comes with exactly one bill attached: from now on, you have to be able to say who is allowed to send.
Sources
- Klaviyo — K:BOS 2026: 4 updates powering Klaviyo's autonomous B2C CRM (the primary source and the origin of the quoted figures here: the 9 September K:BOS announcement, the "more than 260+ Klaviyo MCP tools and capabilities are callable directly from Claude, ChatGPT, or any AI system" wording, read/write/publish without opening the interface, the SQL-in-KDP preview and its object coverage, the Bialecki quote, and the 4 billion signals a day across 9 billion profiles figure)
- Klaviyo Developers — Klaviyo MCP server (the documentation the second half of this post rests on: OAuth with dynamic client registration, compatibility with any MCP client supporting remote servers including Claude, ChatGPT, Cursor and VS Code, and the published scope table for the full toolset — Campaigns, Profiles, Events, Segments, Subscriptions, Templates, Images and Translations at full access, with read-only scopes for accounts, catalogs, flows, lists, metrics and tags)
- Klaviyo Help Center — How to create or clone a private API key (the credential rules quoted here: read-only, full and custom scope options; that scopes cannot be added or edited after a key is created; that a private key cannot be viewed again after creation; and that only an Owner or Admin can create, clone or delete one)
- MarTech Series — Klaviyo Goes Headless, Opening Its Platform to Agents and Marketers Wherever They Work (independent trade coverage of the same announcement, the source of the 490+ API figure, and confirmation of the read/write/publish description)
- SMBtech — Klaviyo Opens Its CRM Platform To External AI Agents And Adds SQL Access For Marketers (a second independent report on the day, used to corroborate the tool and API counts and the plain-language SQL preview)
- JTS Tech Services — Your CRM just got a second front door — and it opens for the whole team with one admin click (the same shape of change on the Salesforce side a fortnight earlier, and why the breadth of a single correct authorisation is its own kind of exposure)
- JTS Tech Services — Your agents are anonymous inside your own stack (the pattern Klaviyo's OAuth path avoids, why static identity-less credentials are still the norm elsewhere in most stacks, and what to do about the ones you already have)
- JTS Tech Services — AI agents just showed up inside your team's tools. Now what? (the general version of this problem, including the shadow-agent path that a blanket refusal to use the sanctioned connection reliably produces)
