This is probably the least comfortable post in the series.
The obvious way to write about vendor over-claiming is not to name anyone. That’s what I’ve done. The alternative is to pretend this isn’t happening. It is.
If you’re buying in this space just now, you’ll have noticed the shift. Everything is AI-powered, agent-aware, autonomous, or adaptive. Some of that is fair. Some of it is a bit ahead of the product. Some of it is, bluntly, a plan described as if it already exists.
The difficulty isn’t that any single claim is wildly wrong. It’s that they’re just accurate enough to be plausible, and just vague enough to be hard to pin down.
If you can’t tell the difference, you won’t notice immediately. You notice later — when the thing you thought you’d bought doesn’t quite behave the way you expected.
This is written for the buyer trying to avoid that.
There is good work in the market. Some of it is genuinely very good. The problem is sorting that out without sitting through the same conversation repeatedly.
What the market actually does
It’s worth being clear about the baseline before getting into the patterns.
Behavioural analytics is real. It works, and it’s better than it was. Most of the leading SIEM and XDR platforms can do something sensible here once they’re properly integrated, even if getting there still takes more effort than tends to get mentioned.
Correlation across multiple signals is also real, though uneven. Some vendors genuinely bring identity, endpoint, network, and cloud data together in a useful way. Others are still, in practice, centred on one domain with additional feeds attached.
Automated response exists, but tends to be bounded. The more credible vendors are quite clear about where automation stops. The ones who aren’t tend to leave that line deliberately vague.
Where the market is much less settled is around agent identity as a proper subject. There are attempts — some of them credible — but this isn’t a mature category. There’s no consistent model, and no product that joins all the pieces up end-to-end.
That matters, because quite a lot of the current positioning assumes that layer already exists.
Pattern one: new language on old capability
The most common pattern is also the easiest to miss at first.
A product that already does competent behavioural analytics or anomaly detection gets described using the vocabulary of something more advanced — agent-aware, AI identity, agent governance. The capability underneath hasn’t materially changed, but the framing has.
You can usually test this quite quickly. Ask whether the system treats an agent as a distinct subject — its own identity, its own posture, continuously assessed. This is the layer-three question from earlier in the series, asked commercially. If the answer comes back to the agent inheriting the identity of a user or service account, then you’re looking at the existing model described differently.
That isn’t inherently a problem. It becomes one when you assume you’ve moved further up the stack than you actually have.
Pattern two: fast presented as intelligent
A second pattern shows up in how “intelligence” is described.
A lot of systems positioned as AI-driven are, in practice, executing predefined logic at speed. That’s useful — speed matters — but it isn’t the same thing as a model that adapts or learns from new conditions.
The distinction becomes clearer if you ask what the system has learned. A model-based system should be able to describe, in general terms, how it adapts. A rules-based system generally can’t, because it isn’t adapting — it’s applying what it was given.
The difference tends to show up most clearly when something new appears. A model will usually degrade or flag uncertainty. A rule-based approach just won’t match, and often won’t say so.
Again, this isn’t about one approach being good and the other bad. It’s about them being described as interchangeable when they’re not.
Pattern three: the autonomous policy mirage
The more ambitious claims tend to sit around policy.
There’s a recurring narrative that systems can generate and apply access policy autonomously — learning from behaviour and adjusting continuously without human input. In practice, what exists in most cases is recommendation: the system suggests, and a human decides.
That distinction matters operationally.
The simplest way to get at it is to ask what actually changes without a human decision. If the answer is “not much,” then the system isn’t autonomous, regardless of how it’s described. If changes do happen automatically, then you need to understand how, on what basis, and what happens when something goes wrong — because at scale, it will.
Where this tends to cause problems isn’t technical. It’s when teams start assuming the system is handling policy hygiene and ease off the manual work that was doing most of the job.
Pattern four: the demo that doesn’t carry into production
A more subtle pattern sits around how products are demonstrated versus how they behave in practice.
Most platforms demo well and they’re shown against clean data, predictable scenarios, and with the right level of support. That’s normal. Production environments are less cooperative with Data being noisier, behaviour is less predictable, and edge cases show up quickly.
Some gap is expected. The question is how much, and whether it’s been represented honestly. The only reliable way to get a sense of that is to speak to people running the product at scale, against real workloads. Not just the reference case provided, but a range.
If that’s difficult to arrange, or tightly controlled, that’s usually informative in itself.
Pattern five: AI-washed platforms
The final pattern is less about capability and more about positioning.
An existing platform, often perfectly capable in its own right, has AI features added and is then presented as fundamentally redefined by them. In many cases, most of the underlying value remains where it always was.
There’s nothing inherently wrong with that. The issue is when the framing shifts in a way that suggests the value comes primarily from the newer addition.
The simplest check is to ask what capabilities exist only because of AI, and which were already present. If the answer isn’t clear, the distinction probably isn’t either.
What to do with it
You don’t need a large framework to navigate this, but you do need to be a bit more deliberate in how you run vendor conversations.
A consistent set of questions, asked every time, does most of the work:
- What actually changes in a trust decision when this is deployed? Where does its output really land?
- What, specifically, has the system learned? Not in general terms, but in a way that can be explained
- What happens when it encounters something it hasn’t seen before?
- Which decisions are made without a human, and where exactly is that boundary?
- What does failure look like outside a controlled demo?
- Who is running this in production at the sort of scale we care about, and can we speak to them?
None of these questions are particularly complicated. That’s the point and you’re not looking for perfect answers. You’re looking for answers that are consistent, direct, and hold up when you come back to them later.
In practice, how those questions are answered — or avoided — usually tells you as much as the content itself.
A word for the vendors
For anyone on the vendor side reading this and feeling slightly pointed at — it isn’t intended as a broadside.
The pressure to over-claim at the moment is real, and not all of it is cynical. The technology is moving quickly, and in quite a few cases the implementation is ahead of what can be neatly explained or documented.
Most vendors will admit that, if you get into a more direct conversation.
From a buyer’s point of view, the issue isn’t that things are evolving — that’s expected. It’s when positioning runs materially ahead of what can be relied on in production.
The vendors who are clear about where the edges are tend to stand out fairly quickly. The ones who aren’t tend to create more work for everyone involved.
If anything, buyers who ask sharper questions are usually easier to work with, not harder. There’s less to untangle later.
One thing to take from this
None of these patterns are new. Versions of them have shown up in earlier cycles.
What’s different now is the pace, and the fact that genuinely useful capability is evolving alongside a fair amount of loose positioning.
That makes it harder to separate signal from noise.
It gets easier once you know what to look for — and what to ask.
Post 12 of 13 in Stacked Zero Trust.
Previously: Post 11 - A Maturity Model for Stacked Zero Trust.
Next: Post 13 - The Next-Generation CISO Conversation.*
The reference document at the end of the series includes a longer buyer’s question set and a worked-through example of how the five patterns presented above appear in real product literature, anonymised.
References drawn on in this post: the buyer’s question framing introduced in Post 5 (Layer Two: AI as Mediator) is extended here. No specific vendor is named or referenced. The market description reflects publicly observable product positioning across the major Zero Trust and security analytics categories in mid-2026.