Intent-based governance is not what most vendors are selling

I have spent the last few months on the road with Icebreaker, our agentic AI governance product, in customer and partner conversations across this category. One challenge keeps coming back. "Doesn't your approach do the same thing as everyone else's." Every time we look closely, the answer is no, and for a reason worth naming. The products being compared fall into one of two camps.

1. The first helps the organisation identify mistakes after the agent has already made them, hopefully before the customer notices.

2. The second issues just-in-time, narrowly scoped permissions that are complex to implement well and still miss the point. Detection is not governance. Tighter scopes are not governance either, because the agent can still do the wrong thing inside a permitted scope.

The phrase "intent-based" or "intent-aware" governance now appears in almost every deck I see in the agentic AI space. Most of the time it does not mean what the buyer in the room thinks it means, and the buyer leaves believing they have bought something they have not.

What buyers think they are getting when a vendor says "intent-aware" is a system that evaluates what the agent is actually trying to do, in context, against business policy, and intervenes when the action drifts from purpose. What they are usually getting is a token, a scope, a policy evaluation against attributes known at the moment of issuance, and a behavioural anomaly detector layered on top. That is traditional identity and access management with the word "intent" stencilled on the front panel.

This bothers me because the failure modes are different, and the buyer will discover that the hard way. An agent operating inside its permitted scope can still take an action no human owner would sanction. It can chain permitted tool calls into a plan no one authored in advance. It can satisfy every static policy and still violate the goal it was given. Traditional IAM, however well executed, is structurally unable to catch that. It enforces what an identity is allowed to do. It does not evaluate what the agent is actually trying to accomplish at the moment of action. The first time an autonomous agent does something destructive while staying inside its permitted scope, the post-incident review will ask why the governance layer did not stop it, and the answer will not be a comfortable one.

Real intent-based governance starts from a different question. Not "is this identity permitted to call this API", but "is this action aligned with the goal the agent was given, the policy the business defined, and the risk tolerance of the operating context, evaluated semantically and at runtime". Permission alone is no longer the gate.

Why is the language being misused. I have a few theories. The most charitable is that the category is genuinely new and vendors are reaching for the closest available vocabulary, which happens to be IAM. A middle reading is that the distinction between delegation-time scope and runtime semantic evaluation is subtle enough that even technical reviewers inside vendor organisations miss it, and marketing absorbs the mistake. The least charitable, and probably the truest in some cases, is that there is commercial pressure to claim agentic AI capability and "intent-aware" is the cheapest claim to bolt onto an existing product line. Probably all three are operating at once. What I am sure of is that buyers cannot tell the difference from a deck, and they are paying enterprise prices for capability they are not getting.

If you are sitting through one of these pitches, here are the seven questions I would run. They are blunt by design. A vendor who is doing the genuine article will answer them.

1. When you say "intent", do you mean an OAuth scope encoded at delegation time, or a semantic evaluation of the agent's reasoning at the moment of action? If the former, you are buying delegation, not governance.

2. Does your policy engine evaluate the agent's plan and reasoning, or only the API call it is about to make? If the engine only sees the call, it cannot reason about the goal that produced the call.

3. Can you intervene during execution when behaviour drifts from the stated objective, even though every individual action remains inside its permitted scope? If the answer is "we flag it for review", that is detection, not governance.

4. How are your policies expressed. In business intent, for example "do not move funds to a new payee without a secondary control", or in technical scopes such as write:payments? Technical scopes will not save you when the agent does the wrong thing inside a permitted scope.

5. What does the audit trail capture. The resource and the timestamp, or the originating prompt, the agent's plan, the reasoning, the decision points, and the outcome? An audit that cannot answer "why" is an IAM log with extra fields.

6. What happens when the plan changes mid-task? Is the new plan re-evaluated against the original goal, or does the initial authorisation just persist for the rest of the session.

7. When a regulator or auditor asks you to prove that a specific agent action was authorised, can you produce a verifiable chain of evidence linking the action back to a declared business purpose, an approved session, and an approved plan, with cryptographic integrity end-to-end? Or can you only produce a log entry that says "permitted at 14:03". A log is not evidence. An attestation chain is.

A vendor doing the genuine article answers all seven without retreating. A vendor selling dressed-up IAM will reach for behavioural anomaly detection, ephemeral provisioning, scoped tokens, and ownership registries. Those are valuable controls. They are not intent-based governance.

The honest framing of this market, which a small number of analysts have already started to adopt, is that runtime governance for agents has three layers. Deterministic access control, which every credible vendor delivers. Behavioural observability, which most are bolting on. And intent-aware governance for evolving agent behaviour, which a much smaller group is actually building. Choosing not to operate at the third layer is a defensible architectural decision. Pretending you operate there when you do not is a sales decision, and the buyer pays for it later.

If a vendor's deck has the word "intent" in it, run the seven questions. The answers will tell you what you are really buying.

Writer’s Overview

Ajit Gupta – Co-Founder & CEO, Midships  

Ajit leads Midships Group’s transition from a specialist identity consultancy to a portfolio of autonomous, AI-native business units. He focuses on long-term business relevance through platform thinking, customer outcomes, and scalable operating models.

Short bio: Ajit is a strategic founder with deep expertise in IAM, platform delivery, and AI services, driving Midships’ expansion across Asia, the Middle East, and beyond.

📧 ajit@midships.io  

🔗 LinkedIn: Ajit Gupta