Guillaume Lebedel · · 6 min 
What SaaS buyers should check after Hex 4.0
Table of Contents
Hex 4.0, announced on 27 October 2026 alongside a $100M raise at a $1.2B valuation, is a from-scratch rewrite built for agents. For SaaS buyers, the interface matters less and the data model, permissions and audit trail matter more. Before renewal, ask whether agents get write access, per-user permissions and a per-agent audit log.
Facts here were checked on 29 October 2026. Hex 4.0 is in private beta, and the figures that come from press coverage are attributed to it in the text.
What changed in Hex 4.0?
Hex 4.0 is a rewrite built around code that agents write and people review. Hex announced it on 27 October 2026 with a $100M round at a $1.2B valuation led by PeakXV and 137 Ventures. It is in private beta, with broader availability promised over the coming weeks, and Hex says more than 2,500 customers use the product.
Hex’s own account of why is specific. In the same announcement, the company says its agent harness “was becoming bloated with hundreds of tools” and that outside agents “were having to use Hex through a keyhole via MCP”. People were also doing analytics in Cursor, Codex and Claude “without permissions, provenance, context, or observability”.
The Hex 4.0 post describes what replaced that. You can click inspect on any element and see “the full lineage of your data”, and there is a first-class tool for reviewing agent-generated analytics code. You can also start with an artifact in Claude and push it to Hex to rebuild it as an app.
Dealroom and Forbes report that Hex deleted millions of lines of code, including its chart builders and query constructors. That is their framing. Hex’s own posts say “from-scratch rewrite” and give no line count. Dealroom also quotes CEO Barry McCardel saying features “now just don’t matter because the agents just write the code for all of it”.
Are AI agents ending SaaS, or only the interface?
The evidence so far points at the interface. Hex removed screens that agents can now generate, and kept lineage and code review. IDC draws the same line: SaaS applications are “systems of record, workflow orchestrators, and data governance frameworks”, and their value is the data model, the audit trail, the compliance configuration and the approval hierarchies.
That comes from Eric Newmark’s IDC blog post of 23 September 2026, titled “SaaSpocalypse: Catchy Title, Flawed Premise”. Forbes and Dealroom both report that Salesforce CEO Marc Benioff called the SaaSpocalypse “crazy nonsense” in his Dreamforce keynote. I have not checked the keynote itself.
Hex and IDC agree on what survives, so a buyer can use that as a renewal checklist. If a chart builder is cheap to regenerate, the line items worth negotiating are the ones agents cannot regenerate: who may change which record, and the history of who did.
What does an AI agent need from a SaaS product besides a UI?
An agent needs four things from a product: a supported way to write data, an identity the product recognises, permissions that apply to that identity, and a record of what it did. Hex’s list of what was missing when agents worked around its product (permissions, provenance, context, observability) maps onto the same four.
| What the agent needs | Question for the vendor | What a gap looks like |
|---|---|---|
| Write access | Can an agent change data through a supported API or tool call? | A read-only MCP server, with writes only in the UI |
| Identity | Whose identity does the agent act under? | One shared service account for every agent |
| Permissions | Do the user’s roles and field limits apply to the agent’s calls? | The agent reads fields the person cannot |
| Audit record | Does the log name the agent and the person who delegated? | One service account name on every entry |
Should an AI agent act with a user’s own permissions or a shared API key?
An agent should act under the user’s own permissions or under a dedicated identity made for that agent. A shared API key gives every agent the same access and puts one name in the log. Some products make this hard: in Salesforce and Workday, an agent authenticates as an existing user such as an integration user.
We went through the options in how AI agents log in to Salesforce and Workday. A dedicated user per agent gives the clearest audit trail, and a shared integration user suits fixed, scheduled jobs better than an agent that chooses its own actions.
We built Tool Policies at StackOne for the permission half of this. A policy can block tools by name or pattern, mask response fields, and apply to everyone, named users or groups synced from an identity provider. Policies only narrow access, and a deny rule takes precedence over everything else. The policies page states one limit plainly: they apply to calls made for a member of an organization, such as OAuth and AI platform sessions, and API key calls do not receive them.
What should an audit log say when an AI agent changes data?
An audit log should name the agent, the person who delegated the run, what the agent read and wrote, the result, and the policy text in force at the time. A log with only a service account name shows who was allowed in. It does not show who asked, which is what an incident review needs.
Our post on what an AI agent’s audit record should contain lays out the same list, and adds that runs spanning several vendors need the logging on the call path, since no single vendor sees the whole run.
IDC put numbers on the gap in The audit trail that doesn’t exist, a blog post of 8 September 2026. It reports that IDC research finds 60% of security leaders lack basic agent containment controls and 35% cannot shut down a rogue agent once it is deployed.
Hex lets you inspect the lineage of any number in an app. A buyer can ask the same of the actions around it: for each change an agent made, which agent, on whose behalf, under which policy.
Is an MCP server alone enough for AI agent access?
No. An MCP server exposes a product’s actions to an agent, but it does not decide whose permissions apply or write the audit trail. Hex called its own MCP route a keyhole for outside agents. A read-heavy server is fine for a pilot, but across many apps it repeats authentication and splits the logs.
Our comparison of native MCP servers and a tool gateway covers where that shows up: repeated authentication, lower tool-selection accuracy, fragmented audit logs and limited governance.
Which questions should SaaS buyers ask before renewing?
Ask whether an agent can write and through what, whose permissions apply to its calls, and what the audit log records for an agent change. Get each answer in writing before the renewal date, and test the second and third with a limited user and a single agent change.
- Can an agent write, and through what? Get the supported API or tool, the scopes it needs and whether it works under a person’s identity or only a service account.
- Whose permissions apply? Ask for a test: give an agent a user with limited access and check that it cannot read the fields that user cannot.
- What does the log record? Ask to see one entry for an agent change. It should show the agent, the person who delegated, the action and the policy in force.
Where a vendor offers a monitor-only mode, start there. In StackOne, a monitor-only policy logs what it would have blocked without blocking anything, so the logs show how much agent traffic a rule would touch before you enforce it.
If you want to see how policies apply to the agent calls in your own stack, book a demo with the StackOne team.