A new paradigm has recently emerged in AI Access Control and Governance: the usage of “Intent” for enforcing AI guardrails. “Intent” means a purpose, a goal, or a firm plan to do something. When applied to Agentic AI, Intent is the semantic description of the goal of the (Agentic) task at hand. The idea is to check the AI’s actions against that initial “Intent” set by the prompter to ensure that the actions of the agents triggered to accomplish that goal are actually in-line. The aim is to avoid such dramatic consequences as accidental full database deletions, for example.
But who sets this Intent? Interestingly, interpretations seem to vary….
For some (see here or here), “Intent” refers to the intention of the Agent being controlled or governed. For others, including us at Indykite, but also for the Verifiable Intent specification for Agentic Payments (VI), “Intent” refers to the intentions of the Subject of the agentic workflow; i.e., the human user, or the autonomous long-lived Agent, who prompted the agentic system in the first place. The Subject vs Agent Intent debate is a rather foundational and profound distinction. Now of course both Intents should match, but because of the nondeterministic nature of AI, they might actually not, and that is the point.
Subject vs Agent Intents
The best solution would therefore be to deduce “both” Subject’s and Agent’s intents. Nevertheless, deriving intent is a costly process that requires an AI inference model, and we know that the currently already expensive inference costs will increase five-fold by 2028. It is therefore a good idea to limit Intent extraction, especially since both are actually not needed, as we will see below... But then whose intent should we consider?
The right intent is the Subject’s, naturally. Subjects prompt the AI Agent(s), they set the goal and they may be asked to approve actions. The Agent’s own intent should match the goal set for them by the Subject. A good AI governance harness should therefore catch any drift between the intentions of the Subject and actions of the Agent actors the Subject delegates to. This is the basis of “Intent Based Access Control” (IBAC), a new authorization paradigm that limits an Agent’s permitted actions to only those matching the Intent set initially.
Now, inferring the Agent’s Intent becomes unnecessary once we have understood, and extracted, a formal representation of the Subject’s intent. The Harness platform thereafter just needs to validate the Agent’s actions, and ensure they match the subject’s Intent. The Agent’s intent extraction becomes unnecessary: we just need to look at what the agent actually attempts to do.
Dynamic Authorization
Now two questions arise:
- And Intent can literally be anything, how can we represent such a thing in a formal, normalized way?
- How can we validate the Agent’s action against it?
Formalizing Intent may feel akin to “boiling the ocean”; and indeed, a Human user can literally prompt an AI Agent with any question or goal. Formalizing Intent must be like using a full blown language, mustn’t it?
Well, we need to simplify the problem here. In the context of building Agentic Governance harnesses, what we are really interested in is ensuring that those Agents can only undertake legitimate actions: ones they are actually authorized to perform. Therefore expressing all Intents as access requests is a good way to go about it. In fact, such a harness shouldn’t really care about any prompts submitted to an AI Agent that is not an access request.
And moreover, all Intents can actually be expressed as Access requests. Let’s take the usual “book a flight” example, where a human user prompts an AI Agent to book a flight for them. What the User is really asking here is for the Agent to access a flight booking system to perform a search. The follow-up action is to access the same system, but this time the action isn’t a search, but buying the flight ticket. Similarly, in an Enterprise, a long-lived Agent may be prompted by employees to help in their day-to-day job functions. In fact, any one of these prompts is an access request to an underlying enterprise system (database, API or other, more specialized Agent) to fetch from information, what else could it be?
But we can simplify the Intent extraction even further. Any given Agent has a domain of knowledge that is specific to its intended usage. Generic Agents such as Claude or ChatGPT need Internet access, but agents specific to an organization, public or private, will only need to have the knowledge specific to that organization. When deriving Intent, it is therefore important to ground that deduction in the domain of knowledge that the governed agent evolves in. An AI Agent assessing Insurance Claims, for example, shouldn’t have to answer questions about astrology or oil extraction... It is therefore possible to simply reject any prompt not grounded in the domain of knowledge at hand.
Given all this, all Intents can be formalized as access requests, and these now can be expressed in a proper standard: OpenID AuthZEN, I.e., as sets of {Subject, Action, Resource, Context} tuples. That is the right format to represent intents in a formal, normalized way.
Formalizing intent makes it enforceable
When implementing IBAC, the Subject (human or machine) is the one to consider. That Intent must thereafter be used as the basis for validating the actions of any Agent the Subject delegates its request, and accesses, to. For the purposes of extracting intent from prompts, grounding in the domain of knowledge of the organization, its Ontology, greatly simplifies things. Expressing intent as sets of AuthZEN evaluation requests provides a simple and handy format to use as the basis for comparing Agentic actions to original Intent.
In the next blog in this series, we will look at examp-les of intents expressed as AuthZEN statements, and see how IBAC actually works and uses these formal Intents to infer decisions in a deterministic way.
.webp)
