AI Agents can do a lot, they can discover each other and decide which tools to use or which other agents to invoke in order to achieve their set goals. Autonomous agents can just make these decisions on their own, whether warranted or not by the original intent of their set goals. And that is the problem, whether autonomous or not, Agent actions are typically obscure. It is nearly impossible to understand why an agent acting within a workflow has performed the actions or tasks it has undertaken, not unless these actions are properly tracked and audited.

The necessity for adding governance and deterministic guardrails to agentic workflows has therefore prompted several organizations and tech professionals to publish their own solutions or frameworks for securing these workflows. For example Cisco’s AGNTCY framework, the Cloud Security Alliance’s (CSA) “Agentic AI Identity & Access Management New Approach”, the “OpenID Connect for Agents (OIDC-A)” standard proposal, OWASP’s “Securing Agentic Applications Guide", OpenID’s “Identity Management fo Agentic AI” or, more recently, a new draft specification that was proposed this week at the Internet Engineering Task Force (IETF)’s meeting 125: “AI Agent Authentication and Authorization”.

The whole slew of solutions and frameworks can feel rather overwhelming. Some proposed solutions or frameworks are even contradictory. Authenticating AI Agents for example, is, rightly so, a base requirement in all frameworks, but one can’t implement Verifiables Credentials (VCs) and SPIFFE at the same time… (rather, one can, but why would one?). And besides, do we really need all that extra infrastructure?

These proposed solutions are not only extremely complex, but also tend to focus on an idealized environment, a sort of dream state where the authors can just express their wish-lists for what would constitute, in their sense, an ideal environment for securing AI. In most cases, the authors have little regard to any pre-existing work or publications, and seem instead to reinvent the wheel with each new paper. Given the AGNTCY framework, for example, did we really need a new CSA Approach? Given the OIDC-A proposal, did we really need a new IETF specification? And finally, why can’t all these proposals agree?

Why are these frameworks unrealistic?

The AI Security frameworks, proposals or recommendations published so far disagree for two main reasons. The first is that adding guardrails to AI is a complex problem, and there are several valid strategies for solving it. The second is that all these proposals focus on the wrong problem: authentication, where the real challenge is enforcing proper authorization based on the context. They are all rather light on that front.

Besides, these frameworks are unrealistic because they do not bear in mind the realities of modern enterprises, which are always playing catch-up with the latest trends and standards. Some are still struggling with implementing their multi-factor or passkey initiatives; talking about VCs, SPIFFE or transaction tokens can therefore seem like a far fetched goal for most. Furthermore, the proposed solutions rely in part on draft specifications, which are not yet implemented by any off-the-shelf vendors, or involve complex infrastructure, in the form of extra hardware and software. Enterprises would have to implement and deploy these at great additional cost. Enterprises also face a wide in-house knowledge gap with most solutions, which would likely require them to engage costly external consulting help for implementation and deployment.

What are the solutions for securing Agentic Workflows?

Public and private organizations should look, and focus on the tools they already have at hand, at least for solving the simpler problem of authentication. Authorization will require additional tooling, it is therefore a better use of their budget to invest in solving that real, hard problem. Here is how this could look like…

Performing Authentication for AI agents

First, let’s get authentication out of the way. Like all machines before the advent of AI (see for example IoT device authentication), smart agents can use public-private key cryptography to authenticate. It is just a matter of creating a private key, and using it to create a JWT Bearer Client assertion (as per RFC 7523 - a well supported specification that has been around for a decade at least). Note that SPIFFE is just a very fancy, complicated way to create essentially the same thing. SPIFFE may have its place in hedge cases, where the agent cannot for some reason, create/hold a private key, or where proving the agent runs on a specific hardware is critical. But in any case, a JWT Bearer assertion will allow the client to authenticate using the OAuth client_credentials grant, which is supported by all current Identity providers. Note that if required, the Bearer token thus created can also be tied cryptographically to the request that uses it through the DPoP standard (RFC 9449 - also very well supported throughout the industry). These very well established standards are likely to solve most, if not all, authentication use-cases.

A note on Verifiable Credentials (VC)… Like the other methods above, these are also cryptographic artifacts that can be used to prove an agent’s identity. Nevertheless these require a full paradigm shift: Identity Subjects now need a Decentralized ID (DID) and a digital wallet to hold these VCs. Resource Servers now need to behave like Verifiers, and there needs to be an Issuer for all these VCs. This paradigm shift is likely inevitable in highly distributed systems, or if integration with trust frameworks is a requirement. But these are very specific use-cases…

In any case, one way or another, we solved the Authentication problem.

Using Access Tokens to enable agentic workflows

Now, Agentic workflows rely on OAuth2, as per MCP and A2A specifications. Implementers therefore need to handle Access Tokens. But contrary to some claims made in the papers cited above, AI Agents are not typical workloads. They are indeed software components that require resources, nevertheless agentic components have some major differences.

Firstly, an Agent may require a lot of resources, much more than traditional Micro-Service or App (e.g., GPUs). Furthermore, Agents are stateful: they need to keep track of sessions in order to exchange JSON-RPC messages via MCP or A2A. Finally, Agentic transactions can last tens of seconds, or even minutes, much longer than the millisecond timeframe of typical micro service meshes, for which the “workload Identity” suite of standards (including SPIFFE) had been originally created. Agentic workflows therefore require “medium-lived” tokens, not short lived ones. Tokens that have a time-to-live (TTL) of at least several minutes, enough for all the AI models to compute their answers or perform their tasks for a given transaction.

Performing Authorization in agentic workflows

As discussed above, the authentication problem is rather easy to solve using existing, well supported specifications and functionality. Easy comparatively to the Authorization problem at least. The main investment in protecting agentic workflows should therefore be made in the authorization components. It is where the complexity lies, and where additional components are necessary.

Preliminary Definitions

Proper Agentic authorization involves the following concepts:

‍

• Subject: The Entity that initiates the Agentic Workflow, and on behalf of whom all the actors involved in the Agentic Workflow perform their tasks.

• Intent:  The intent is the goal or task the initiating Subject is trying to accomplish, it captures the intention of the Subject. For example a user trying to buy a plane ticket or an autonomous agent monitoring log files wanting to send an alert. An intent can be modelled as a Subject wanting to Perform an Action, or set of Actions, over a set of Resources (e.g., Buy Plane-Ticket, Send Alert, etc.).

• Skills: describe the capabilities of an Agent. Skills definitions are now standardized through Anthropic’s Agent Skills specification. The initial Intent of an Agentic transaction therefore needs to be translated into a set or ordered tasks, which in turn must match one or several available skills (otherwise the original intent can’t be fulfilled).

• Tools: the tools made available to agents, which include MCP tools. Thus, a given Agent skill may be implemented through the use of one or several underlying Tools. Tools can be hardcoded within the agent, or made available externally via MCP.

• Resource: an entity that Subjects intend to use, and that needs to be protected. A resource is a very generic term, and can refer to Agents, MCP Servers, Skills, Tools, data elements, APIs, etc… A resource can be as granular as necessary.

• Policy Enforcement Point (PEP): a block of code or software that acts as a proxy or gateway placed in front of a Resource.The PEP can filter all messages incoming to a protected resource and redirect them to a Policy Decision Point (PDP) for evaluation. The PEP enforces the decisions of the PDP, in particular it rejects all messages or requests deemed unauthorized by the PDP.

• Policy Decision Point (PDP): an external policy-based rules engine that can store, manage and run access policies and evaluate access requests to protected resources. The PDP gets access evaluation requests from PEPs and responds based on the available policies. The PDP is also responsible for access governance: it can keep track of all access requests and decisions.

• AuthZEN: a new OpenID specification that standardizes the communication protocol between PEP and PDP. It makes the whole system interoperable: any PEP can invoke any compliant PDP.

• Context: The set of facts pertaining to the Subject, the Agent Actors or the environment that are true at the time that an access request is evaluated. It is easier to model the context as a Graph, because of the otherwise hard to express or understand relationships between all the involved entities. For example, the same Agent actor may have access to different tools depending on the transaction Subject or other environmental factors and policies.

• Intent-Based Access Control (IBAC): The authorization model used by the PDP and its policies to model the access permissions based on context. IBAC relates Intent to Tasks, Skills and Context, and leverages policies that use all these factors in order to perform access decisions in an Agentic Workflow.

‍

What are the guidelines for implementing Agentic Authorization ?

Given these elements, Agentic Workflow authorization can be properly enforced by following the following guidelines:

• It is necessary to track the initial transaction intent, and also the suite of actions and delegations that actually occur at runtime, and compare those to the tasks that are permitted given the context of the time. The intent needs to be valid, and the Skills invoked must match the Intent, based on the configured access policies of the system.

• An Agentic workflow needs a set of PEPs placed in front of all Agents and MCP Tools, in order to control and track the message flow, and to enforce coarse to fine-grained access controls throughout the whole transaction. The PEPs could for example be A2A or MCP compliant gateways, or code block wrappers placed around any calls to resources.

The OAuth2 Token Exchange specification is very well suited to track real-time delegation chains (and well supported throughout  vendors too). Through Token exchange, a client, say a PEP, can exchange a Subject (e.g., User) token and an Agent token for a delegated token with an act claim. The act claim is a JSON object encapsulating the whole delegation chain up to that point, and can be used as part of the context in IBAC policy evaluations.  For example, the following act object illustrates a 2-Agent chain where the token's subject first delegated to indykiteagent-2, which then invoked indykiteagent as the second workflow step.:
‍

  
{
  "act": {
    "sub": "indykiteagent",
    "act": {
      "sub": "indykiteagent-2"
    }
  }
}

‍

• The other difficult part of this model is capturing the Intent. If the Subject is a human user, the initial goal is likely set through Natural Language via an LLM. Human language is complex, extracting content is therefore not an easy task. Specialized AI models can be used to extract concepts, topics or entities from input text. Such models can then be used to formalize the original intent into some machine-readable serializable format. The initial intent, or a subset thereof,  should be passed from a step to the next in the agentic workflow.

• As mentioned above, Intent can be modelled as a collection of Subject, Action, Resource, Context quads. The AuthZEN specification therefore provides an adequate format for expressing intent.

• Intent must be carried around throughout the Agentic Workflow, ideally it should be part of the Delegated Access Token that is exchanged at every step. A good way to convey the intent in its AuthZEN format is through the OAuth Rich Authorization Request specification (RAR - RFC 9396 - another well supported specification). The contents of the RAR authorization_details claim can thus be an AuthZEN JSON object expressing the intent. This can then be used as is by any IdP/AS, or Agent Gateway, to evaluate access with an external PDP, the end-result being a token that will contain only those AuthZEN claims that are actually permitted.

• Cross-Domain Agentic workflows, that is workflows where AI Agents from a trust domain can invoke other Agents or Tools in another trust domain, is an often cited gap in many implementations. A new draft specification proposal called Identity Assertion JWT Authorization Grant (ID-JAG) provides an interesting solution, if it gets adopted by the IETF as a proper RFC. This would allow an agent from a trust domain to get an access token from a different domain, which it can then use to access a given resource in that other domain. This new proposal relies on OAuth Token Exchange, therefore investing in Token Exchange (which has been around for some time now) is also a good way to future proof the system.

Solving the challenge of Agentic AI authorization

Solving the Agentic AI Authorization problems requires proper knowledge of existing standards and tools, as well as reading existing material to avoid reinventing solutions. Agentic Workflow implementers should look for solutions or vendors that implement the following specifications:

• OAuth2
• JWT Bearer Client Assertions
• DPoP (optionally)
• Token Exchange
• AuthZEN
• ID-JAG (Future, based on Token Exchange)

And look at indykite.ai for a complete, standards compliant platform for Agent control and protection.

‍

This article was first published on Substack.