A New Concept for Authentication and Authorisation for AI Agents

This article is written by a human. – AIHumanize.

The Image was created by Michael Poulin with the help of DeepAI.

This work has been inspired by the post on LinkedIn by Weiwei Feng, Global AI & GenAI (Director) at Capgemini.

Problem to Solve

One of the major differences between AI agents and SOA Services is that Services had explicitly designed and implemented functionality and all resources required for their task, while still-emerging AI Agents create their plans of action and needs for resources by themselves, at runtime, and in dependence on the specified task. As Mrs. Weiwei Feng wrote, “Neither the user nor the agent knows what external system or database they’re about to hit.” While this statement includes a few important non-articulated assumptions, it reflects the essence of AI Agent execution and cooperation with unknown others.

That is, nobody, neither creators nor users, can predict what the AI Agent would need to solve the specified task, and there will be no time for human intervention into runtime execution to properly reconfigure the AI Agent. The consequence of this is straightforward—neither direct-explicit nor delegated authentication or authorisation, as we know them today, will work for AI Agents.

We need a new concept for both authentication and authorisation that would allow effective work of quasi-autonomous AI Agents.

I am not mistaken—AI Agents are autonomous only in the sense of human oversight, but technically they are not autonomous at all and can create a need for additional functionality or data to solve the given task, i.e. they allow dependencies at work with no problems. This is called a “soft dependency”.

So, the old questions—‘How to figure out who/what contacts me?’ and ‘How to figure out if this contact is permitted?’—are ’re-erected on the next spiral of technology evolution.

Approach

AI Agent Capriciousness 

As we know, the behaviour of AI Agents changes with changes in the execution context and with the changes in the initial prompt or triggering event. This means that the AI Agent may and can create a new Execution Plan for itself. A new plan can contain several needs for additional data sources and, probably, other AI Agents to execute and change the state of the world, which the initial AI Agent needs.

I am using this probabilistic language here because each AI Agent is assumed to be created in isolation from others, and the creator or user does not know up-front what might be needed. Just in case, the ecosystem of AI Agents is similar to the SOA ecosystem, where each entity is created independently from others and may have an individual provider and owner.

At runtime, the logic of the AI Agent execution is unknown, and, as many scientific researchers state, it may be never reachable and does not make practical sense but incurs a high price tag. I am referring here to the works of Roman V. Yampolskiy, Zachary C. Lipton, Angelo Calvello, Dan Hendrycks, and Laura Hiscott.

Boundaried Knowledge

Explained arguments do not mean that we have finished with authentication and authorisation for AI agents. These two security controls are simply shifted from the acting entities to the Resource Registry.

As you hopefully noticed, I mentioned that an AI Agent can create a need for additional functionality and data. Such a need can be expressed in the ‘language’ that only this AI Agent understands. To communicate this need to others, another language is required, which, at least, would be understandable to them.

The Resource Registry is the container that keeps information about certain nomenclature of AI Agents and data sources or databases that want to be used by others. This Resource Registry and each entity registered in it must ‘speak’ a shared meta-language, but this is not enough.

The AI Agent need can be expressed using different vocabulary, as each AI Agent and data source may have its own provider independent from other providers. So, the Resource Registry should provide a comprehensive translation of needs to offers and vice versa. This is the task for the special AI-based translator.

Access to the Resource Registry should be controlled by explicit authentication of the requesting AI Agent, i.e. each AI Agent should have its unique ID, at least in the context of the particular Resource Registry. If the AI Agent is permitted to get into the Resource Registry, the proposed concept states that every or any resource in there is accessible to the requesting AI Agent unless its own security policies do not prohibit certain resources.

 If access to a concrete Resource Registry is denied, the AI Agent may try other Resource Registries if they are available and related access credentials are known to the AI Agent. Otherwise, the denied AI Agent may re-create its Execution Plan, identify different resources it needs, and try to resolve them. Actually, this resolution capability is limited by the knowledge about available resource registries. If the list of the latter is exhausted, the AI Agent must stop itself and announce an inquiry for help.

Partially responding to Weiwei Feng’s comment, “Nobody knows what’s coming next, but everyone affects everyone else”, I can refer you to the section “What If?” that describes a big trap awaiting us in the next step.

Upon getting into the Resource Registry, the AI Agent should be able to either create a meta-query or engage a Resource Registry’s Assistant (AI Agent) to compose this query based on the translated needs. There is no guarantee that a suitable entity would be found. If no luck, the AI Agent turns into the state of denial and can act as described earlier.

It is unclear at the moment how a found pair of AI Agents can interact and what interfaces, channels, and methods they can use. I anticipate a lot of cases where interaction content may be complex enough to be expressed as a sentence, like a prompt. However, there may be many cases working via “fire-n-forget”/pub-sub with very simple event identities available in additional catalogues.

The natural boundary of the Resource Registry forms the boundary of the scope of possible interactions for a set of AI agents. Human oversight may not allow an AI Agent to contact anything anywhere due to business security concerns such as business dependency, business continuity, financial spending limitations, inter-market competition, and the like. Technology can move anywhere at its own pace, but business still preserves its revenue-enabling benefits.

Authentication & Authorisation Concept

The Concept

The proposed Authentication & Authorisation Concept comprises several statements. I enumerate a few of them, hoping that my readers would extend this list:

1.  A stand-alone AI Agent and a composition of AI Agents act similarly with regard to authentication and authorisation. An AI Agent comprises a few modules that should interact with each other and can identify preliminary unknown needs in additional functionality and data. The modules of the AI Agent are concrete and known a priori; however, some data sources identified by the design and the resources needed at runtime may be collected in the Resource Registry.

2. The Resource Registries can be federated if needed, being focused, for instance, on particular business or technology domains.

3. The authentication of each AI Agent is delegated to the access control of the resource registry. Each AI Agent should have individual credentials to access a particular resource registry, while different Resource Registries may require different credentials. The control of crossing the Resource Registry boundaries in federation ought to be defined because the federation chain can be dynamically changed.

4. The authorisation is revoked from an individual AI Agent and delegated to the resource registry. If logged, the AI Agent has authorisation to look up a resource it needs and expresses via the Registry’s meta-language. A special AI translator and AI query searcher should be provided by the resource registry. If the resource is found, it may be involved with a related interface. However, it is not excluded that some AI Agents may be preconfigured with certain restriction policies that prevail over a simple finding of a counterpart. Such policies may be enforced as in the Resource Registry or outside of it—related solutions depend on the preferred design in each case.

5. The Resource Registry is filled using a standardised mechanism by the providers of the resources. The provider should submit the resource—an AI Agent or a data source—with the description of offered capabilities in the meta-language of the registry. The provider is free to revoke the resource from the registry. For the latter case, the Resource Registry should define a reasonable “graceful period of revocation” to protect the consumers of the Resource Registry that work with the resource at the moment of the removal.

Accountability

From step one, I deny any accountability of AI Agents for the harm they can cause to the users (human or other AI Agents). This accountability starts and remains with the provider of each AI Agent.

This accountability also relates to the internal runtime planning (orchestration of execution) and the needs identified by the AI Agent and possible invocation of supplemental resources. However, there is no accountability for those resources invoked. “My” AI Agent may make a call and deal with the results. The AI Agent involved with my AI Agent is not my Agent.

At the same time, “my” AI Agent is accountable for the consequence of an incomplete or failed execution plan. A related scenario is described in the section “What If?”.

Resilience

The interactions in the AI Agent ecosystem, including internal interactions between the AI Agent’s modules. So, I contemplate two areas of resilience to be realised with regard to access control:

1) Access to a Resource Registry

2) Access to a found resource.

A resilience for access to a Resource Registry should include more than one means of access mechanism. An AI Agent may have a few credentials for these mechanisms. Just keeping multiple instances with a single login mechanism in the distributed deployment of the Resource Registry is not enough because it can be affected by the changed state of the world (execution context).

It is recommended that the Resource Registry enable a few alternative methods for looking up or querying the registry, which can increase the robustness of the runtime execution of AI Agents.

A resilience for access to the resource—AI Agent and data store—found in the Resource Registry is the second part of the resilience solution. This results in more than one invocation mechanism being provided by the supplemental resource. The invocation mechanisms should be clearly documented at the moment of registration of the supplemental resource in the Resource Registry and supported via the meta-language for querying.

Safety

A discussion of authentication and authorisation would be incomplete (overfocused) if the safety of invocations resulting from the succeeded authentication and authorisation were not addressed. A notion of safety in this article is defined as a state of mind or a belief in self-immunity or self-inviolability from any potential harm to the actor caused by communicating with a resource, system, or provider.

It is asserted that the Resource Registry may not decrease or increase the safety of the AI Agent. The same relates to the look-up mechanism in the Resource Registry.

However, an invocation of a supplemental resource—another AI Agent or data source—has the potential of reducing the safety of the actor. That is, direct interactions between AI Agents and with pre-configured or supplemental data stores require additional control and safety governance.

The governance of interactions between AI Agents should take into consideration that an AI Agent can access another AI Agent via a Resource Registry and, at the same time (runtime), can access a third AI Agent directly. This can result in safety uncertainty for the runtime duration.

Another aspect demanding safety governance relates to the Resource Registry federation. This federation can be dynamic and composed of different providers. That is, it is unknown up-front how interconnections between federated Resource Registries can impact the initial AI Agent.

Thus, it is recommended to design interactions or invocations between AI Agents and supplemental resources with acknowledgement for each interaction from the involved entity.

 What If?

I can identify a few scenarios to consider in the line of notorious “what if?” analysis.

First, what if there is no resource registry available? I.e., can two AI agents work with each other? – Of course, you need only to consider what you need to build for each AI Agent and, probably, recall why such registries were created for SOA Services operating in composition of service-based applications.

Second, what if at runtime an AI Agent has built an execution plan (without human oversight), and this plan considers invocations of more than one additional AI Agent or data store, and the first invocation of the supplemental AI Agent has succeeded but the invocation of the second AI Agent or data store has failed? In this case we have a known “broken transaction” over a few resources because the initial AI Agent cannot proceed with the initial plan and might create a new one. The trap is that the involved AI Agent can perform its work by the time when the failure takes place and the world state has changed already. That is, a chain of reactions had started and can involve more and more AI agents—we do not know. In the old days, such a situation was supposed to trigger a “compensation transaction” to undo the results of becoming an orphan supplemental AI Agent. Sometimes, it worked, but in the complex systems, this compensation failed, leaving the world in quite an uncertain state. This problem is due to be solved before the runtime invocation of supplemental resources may be allowed. We should not rely on mercy from AI Agents, especially if we do not know what is waiting for us at the end.

Conclusions

1. Stop panicking about a “need” for check permissions on every AI Agent interaction.

2. The Resource Registry solution eliminates this need via delegated accessibility control.

3. The identity of the AI Agent is mandatory, but its control is also delegated to the Resource Registry.

4. If an AI Agent interacts with another AI Agent or data source directly, both authentication and authorisation are the responsibilities of the AI Agent providers (the old, current, and scary model).

5. Consider a concept of Composition of AI Agents as a self-contained design entity.

6. Create a “unique” ID for each AI Agent among those that might work together (in the composition). The Resource Registry may need the AI Agent identity, but it may be different for different Resource Registries.

7. The Resource Registry helps to manage resources available for each AI agent at runtime.

8. Use the Resource Registry for operations within the Resource Registry. Different The Resource Registries may have different meta-languages. This is the special subject for governing the Resource Registry federation.

9. The Resource Registry uses functionality and metadata for its look-up for resources rather than entity identifiers.

10. An AI Agent provider is accountable only for the provided AI Agents and responsible for their accessibility and authorisation mechanisms. The AI Agent provider is not accountable for the supplemental AI Agents. An AI Agent provider is accountable for resolving potential problems caused by the incomplete/interrupted/failed execution plan of the provided AI Agent.

11. The AI Agent provider should take care of the resilience of the AI Agent invocation mechanism. The Resource Registry may provide resilience for its access and internal querying as well.

12. The Resource Registry should not change Safety for the AI Agent. Direct interaction between AI Agents reduces safety. A composition of AI Agents has its own safety that may differ from the total safety of all included AI Agents.