12 min read
The Week the Boundary Got Written Down
For most of this year I have been asking vendors a question they mostly answer with a demo: what, precisely, is your agent allowed to do in my tenant, and how do I stop it. This week three of the nine platforms I work in every day answered it in writing. They gave three different answers, and more interestingly, they put those answers in three different places. One went in the marketing copy, one in a reference table, and one in the API contract. The place turns out to matter more than the words.
TL;DR
- Three customer engagement platforms published what their agent may actually do, and put the answer in three different places. Klaviyo put it in launch copy, Braze in a reference table, HubSpot in the API contract, and where it is written decides more than what it says.
- Klaviyo Headless opened more than 260 MCP tools that can “read, write, and go live” without anyone opening Klaviyo. No permission model, session lifetime or revocation path was published alongside it, for a fourth consecutive week.
- Braze documented 71 tools, 34 of them write, together with their edges. No user-level PII, the dashboard user’s own permissions, revocation on the next request, and a published exclusion for customers using IP allowlisting.
- HubSpot moved the boundary into the tenant. From the 2026-09 API version, admin-configured validation rules apply to every CRM API write path, which binds every automated writer, including the ones nobody has told you about yet.
Klaviyo published the widest agent write scope on my watchlist
Klaviyo Headless launched at K:BOS with a sentence I expect to be quoted in procurement documents for the next year: “An agent can read, write, and go live the same way you would inside Klaviyo, without anyone opening Klaviyo at all.” More than 260 MCP tools, callable from Claude, ChatGPT, or whatever the team already has open.
I want to be fair about the instinct behind this, because it is the right one. Most practitioners I work with already spend half their week in a chat window, and making them return to a platform UI purely to press send is friction that serves nobody. Opening the platform to whatever surface the operator prefers is where all of this was always heading, and Klaviyo has arrived there before anyone else on my list.
But read the sentence again as an architect rather than as a marketer, and notice which word is doing the work. “Go live” is the send. It is the irreversible one. And “without anyone opening Klaviyo” describes, quite precisely, a production send that originated somewhere your platform audit trail may not reach.
Consider what that means in an operating week rather than in a demo. A campaign leaving your platform is the one action in the whole stack that cannot be recalled, and in most of the programmes I work on it is deliberately the slowest step, wrapped in an approval, a seed list and somebody’s initials. Nobody keeps that ceremony because they enjoy it: the cost of getting it wrong is measured in unsubscribes and, increasingly, in regulator correspondence. Moving the send into a chat window leaves that cost exactly where it was and makes the moment of decision harder to find afterwards, because what you will want to reconstruct is what was asked of the platform, which sits in a conversation you may not own, while the platform’s own log only records what it did.
What the announcement does not contain is a permission model, a session lifetime, or a revocation path. This is now the fourth consecutive week I have recorded that gap for Klaviyo, and the gap has widened, because the scope on the other side of it keeps growing. The only governance artefact named anywhere in the launch is a Compliance Hub, which appears once, in a closing list, alongside onsite personalisation and a retail feature, with no detail attached.
I have no quarrel with the capability itself. Everything else Klaviyo shipped that day is genuinely good, and the SQL layer in the Data Platform is quietly the most interesting piece of it: a marketer asks in plain language, and the platform returns both the answer and the exact query that produced it, so that asking twice gets the same result. That is reproducibility offered as a product feature, which is rare and worth applauding. What I want is for the boundary to be published on the same day as the reach, by the same team, with the same confidence.
Braze published the edges instead of the reach
The counter-example arrived from Braze, and it looks nothing like an announcement. Its remote MCP server, which I have been recording as an undocumented gap for five editions, is now fully documented. I counted the published table: seventy-one tools, thirty-four of them write, six of them deletes, and among the writes both launch_campaign and stop_campaign.
That is a wide surface by any measure, wider in some respects than what Klaviyo described. The difference is everything around it. No tool returns user-level PII, and that is stated as an absence of capability rather than a recommendation. Agents inherit the permissions of the Braze dashboard user who authenticated, not a shared API key. Permission changes apply on the next request, and a deactivated dashboard user loses access with them, which is the first revocation path on my board that names the moment it takes effect rather than gesturing at one.
Then there is the sentence nobody will quote and every regulated client will hit: if you use IP allowlisting, you cannot use the remote MCP server at all. A published exclusion is worth more to me than a published feature, because I can plan an architecture around a documented no. I cannot plan around silence.
Braze also does something I have not seen another platform on this list attempt, which is to disclaim its own position in the chain. The documentation says plainly that Braze does not see your original prompt and cannot verify that the tool call it receives reflects what you meant, and then recommends against auto-mode in whichever client you use. That is a vendor telling you where its responsibility stops. It makes for unflattering copy, and it is exactly the paragraph I want in front of a client’s risk team.
Inheritance won, and nobody has costed the audit
Line up the boundaries published this year and a pattern has settled. Braze inherits the dashboard user’s permissions. Treasure AI’s voice connector inherits the user’s role, so a regular user’s agent reads only their own recordings. Claudeforce inherits the seller’s access, with the explicit selling point that there is no new permissions model to build and no re-auditing account by account. 6sense inherits too, and removes PII from its people-search tools on the way.
Only Optimizely went the other way, giving each Virtual Teammate its own identity that activity can be traced back to. It remains the outlier.
I understand why inheritance is winning. It is faster to ship, it reuses a permission model that already exists and is already audited, and it gives the buyer a genuinely honest answer to “who can this thing see”, which is: exactly what you can see. For a rollout on a deadline, that is a strong argument and I have made it myself.
The cost lands later, and it lands in one specific room. When something goes wrong and you are reconstructing what happened, an inherited identity means the log says a person did it. It says so because the agent borrowed the person, and the log has no field for that distinction. You will be asking a marketing manager to account for a send she did not compose, at a time she was not working, and the system of record will agree with the auditor rather than with her.
That is survivable if you plan for it, and the plan is not complicated: separate service accounts per agent workflow, scoped to the minimum, with names that make their nature obvious in a log. What is not survivable is discovering the problem during the incident.
HubSpot moved the boundary into the tenant
The most consequential release of the week has no keynote, no name, and a title that reads like maintenance. From the 2026-09 API version, HubSpot enforces admin-configured validation rules on all CRM API write paths, and pipeline delete endpoints validate references by default.
Read as an architect, that is quietly enormous. For years the validation rules your admin configured were, from the API side, advisory. Any integration holding a token could write around them. Every data quality programme I have run has had the same conversation in month three, where the rules are demonstrably set, the records still arrive malformed, and the reason is that the rules only ever applied to humans typing into forms.
Now they apply to the write path, which means they apply to every writer, including ones nobody has told you about yet.
This is the same boundary question answered from the opposite end, and I think it is the better end. Every vendor racing to publish what its agent may do is describing the caller. HubSpot changed the callee. An agent cannot reason, prompt, or retry its way past a constraint that lives in the tenant rather than in the tool definition, and unlike a published tool list, a tenant rule does not need to be re-read every time the vendor ships.
If you are deciding where to spend governance effort in a stack that is about to acquire a lot of automated writers, spend it there. The roster of things writing to your CRM will keep growing and you will not be consulted about most of it.
Adobe and Salesforce put the write scope inside the assistant
Adobe’s contribution came in the release notes rather than a launch, and it is easy to miss. The CX Coworker in Journey Optimizer gained Content Management MCP tools, and the vendor’s own list of what they do includes creating content, updating templates, and creating, updating, cloning and publishing fragments. Publishing a fragment from a chat prompt is a production write, in a product where fragments are reused across live journeys.
What I find genuinely encouraging sits two entries above it. The same assistant gained an Analyze Journey Anomalies skill, and Adobe took the trouble to specify that once an anomaly is confirmed, the skill runs read-only diagnostics. Somebody at Adobe decided that the read-only nature of an investigative capability was worth putting in the release note, in a product where the neighbouring capability publishes fragments. That distinction is the whole discipline, and I would like to see it become a convention.
Salesforce added record creation and updates to Agentforce Coworker, and MoEngage, catching up on a release that had been unavailable for a month, shipped agents that delegate to sub-agents which run in parallel while a parent consolidates their output.
That last one deserves more attention than it will get, because delegation breaks every boundary written so far. All of them assume one agent and one operator. When a parent agent hands work to a child, whose identity does the child act under, which grant was exercised, and which of the two does the audit log name? MoEngage’s release note describes the parallelism and the shared memory and says nothing about identity. Nobody has drawn the reporting lines for an org chart that just acquired a second layer.
Two vendors set opposite defaults for the same decision
Salesforce is turning the Agentforce Platform on by default. New Winter ‘27 orgs get it automatically, and existing orgs are on a rolling basis that began this month. I flagged this in the last edition expecting the release note to gain detail. It has not. There is still no list of which orgs, no schedule, and no statement about whether opting out is a supported configuration or merely something you can attempt.
OpenAI shipped GPT-6 Astra, its most capable model to date and the first to meet the critical threshold for cybersecurity under its own preparedness framework, and made enterprise access off by default. An administrator has to turn it on.
Neither position is obviously wrong, and I would resist the temptation to score this. There is a real argument that a platform capability nobody enables is a capability nobody benefits from, and default-on is how most genuinely useful infrastructure has ever reached the people who needed it. There is an equally real argument that the point of an administrative boundary is that things cross it on purpose, and that a capability powerful enough to require a safety framework is powerful enough to require a decision.
What I would not accept from either is the third option, which is the one Salesforce is currently offering: a default that changes on an unpublished schedule. If a capability is arriving in my client’s production tenant on a rolling basis, the schedule is not an implementation detail I can be relaxed about. The schedule is the control.
The five questions I am taking to vendors
This week gave me a usable shortlist, and it is short because most of it can be answered in writing before anyone books a call.
Whose identity does the agent act under, and if it is an inherited one, what appears in the audit log. How long does a session live, and what is the elapsed time between my revoking someone’s access and their agent stopping. Which tools write, which delete, and is that list published somewhere I can diff between releases. Is there a draft-only or approval-required mode, and can I make it mandatory rather than optional. And, the one I have started asking first because it sorts vendors fastest: what does your product refuse to do, and where is that written down.
Braze can answer four of those five from public documentation today. Klaviyo, whose agent has the widest reach of any on my list, can currently answer none of them. I want to be careful about how that reads, because Klaviyo has shipped more interesting capability this quarter than almost anyone. The gap measures what each company decided to publish, which says nothing about the engineering on either side, and publishing is a choice that gets made by people who could have chosen otherwise.
The vendors who write the boundary down are the ones you can actually buy from, because a capability without a documented edge is not a product decision you can defend to anyone.
Sources
Klaviyo
- K:BOS 2026: 4 Updates Powering Klaviyo’s Autonomous B2C CRM. The Klaviyo Headless announcement, the 260+ MCP tool figure, the read-write-go-live quotation, SQL in the Klaviyo Data Platform, and the single reference to a Compliance Hub.
- Klaviyo What’s New. Manage Click Tracking, the channel performance dashboard, and First-Party ID.
Braze
- The Braze MCP server. The no-PII rule, dashboard-permission inheritance, revocation on the next request, the IP allowlisting exclusion, and the legal disclaimer recommending against auto-mode.
- Braze MCP server functions. The published tool table from which the seventy-one tool count and the write and delete counts are taken.
HubSpot
- HubSpot developer changelog. CRM API write validation enforcement and pipeline delete reference validation, both live with the 2026-09 API version.
Adobe
- Journey Optimizer release notes. Content Management MCP tools in CX Coworker, the Analyze Journey Anomalies skill and its read-only diagnostics, and the mandatory consent checkbox for landing pages.
Salesforce
- Winter ‘27 Release Note Changes. Record creation and updates with Agentforce Coworker, and the unchanged Agentforce Platform Enabled by Default note.
MoEngage
- August 2026 release notes. Multi-agent coordination for Custom Agents, sub-agent parallelism, and workspace-level memory.
OpenAI
- GPT-6 Astra. The critical cybersecurity threshold, and enterprise access being off by default at launch.
Others referenced
- 6sense product release notes, 2 September 2026. The MCP server with PII removed from people search results.
- Treasure AI September 2026 release note. The role-inheriting read-only voice connector, and Snowflake query tags.
- Optimizely press index. Virtual Teammates and their per-agent traceable identity.
The digest behind each weekly article is produced through a structured AI-assisted scan of official release notes and product update sources. I review the output, verify the relevant signals and write the architectural interpretation.
This article draws from the Martech Weekly Digest scans run on September 10, 2026, covering 4 to 10 September across several CEP platforms and vendors. The dated record behind it is in MarTech Watch, Week 37.
If you find errors or gaps in coverage, I want to know. The process improves when the output is challenged.
