The practical (and magical) uses of AI are on every technologist’s lips to some extent. From CIOs to CISOs to practitioners like us, most of us are trying to separate the hype from the help. For me, one of the most fascinating things in all of this is the potential for AI-powered agents. Back in 2019 I talked about an individual-centric flavor of them which I called “Counselors.” Flash forward and Salesforce is all in on AgentForce, building customer engagement agents at scale.
Agentic AI feels like an inevitability. From its humble origins in screenscraping decades ago to RPA to “dumb” agents (e.g. IFFTT, Zapier, etc), the desire for “smarter” and more autonomous engines of process execution has only grown both within enterprise and for individuals. I was talking to a bunch of my fellow identity nerds about this, and we were trying to wrap our heads around how, from a digital identity perspective, agent AI would, could, and should work.
First off, we know that these agentic AIs are not going to build net new capabilities inside the enterprise. For example, an agent isn’t going to create a CRM, but instead use the services that the existing CRM provides. And that means it’s going to use the APIs that the CRM exposes. In this case, the agent will look mostly* like just another API client. These agents will learn about the capabilities APIs provide by consuming OpenAPI/Swagger descriptions and then go to work.
If that’s the pattern for them, that’s great news because we, identity practitioners, know how to deal with that… good old OAuth! Yes, we will need to likely up our dynamic client registration capabilities. Yes, we will likely need to get better at OAuth scopes management and rich authorization requests. Yes, we will likely need to graft a better policy engine into those decisions. But those known knowns are absolutely manageable with technology and practices that exist today.
However, there’s another way agents will interact with services… not through the back channel (e.g. APIs) but through the front channel via an emulated browser. In this case, the agent will look more like a human clicking on various elements on the page. (Yes, that’s glorified screenscraping but it’s AI powered screenscraping 😉.) Now, I know from experience that treating a DOM like an API is tricky and fragile, but it will happen regardless.
Now the reality is that we’ll see combinations of both use cases. Agents are going to use every means provided to them… including working with other agents. As Erik said to me recently, one can think of these agents as a squad of hyper-intelligent, hyper-dilligent, hyper-eager interns with a task to accomplish, and no fear of being fired for doing something the “wrong way.”
From an IAM practitioner’s perspective, this case is far more difficult. That squad of interns has all your credentials or at least the tokens you authorized them to have. There’s little that exists today that one could use to limit what I can do versus what an agent on my behalf can do. Not without some formalized “on behalf of” (OBO) mechanism. And this strikes at an extremely long standing problem in IAM - we have lacked a formal method to represent OBO actions. We don’t have widely available means to delegate access such that it is easy to determine that this is Ian, this is Ian acting on behalf of a parent who has given him legal proxy, or an agent acting on behalf of Ian, or an agent acting on behalf Ian acting on behalf of a parent who has given him legal proxy.
*Come to think of it, no enterprise will want agents calling APIs without tracking them back to an accountable person who initiated the transaction. This means that the back channel use case has an OBO problem too! There’s a chance that existing patterns from robotic process automation (RPA); at the very least, monitoring and auditing the non-human identities used by RPAs should be a known science.
There are some who propose concepts like personhood tokens as a means to address this… I, for a variety of reasons, am cautious here. I will observe that a representation of delegation and a means of auditing and enforcing delegation are two very very very different things. The representation problem pales in comparison to the audit and enforcement problem. Similarly, mechanisms such as User Managed Access (UMA) could potentially be employed here, but I am not fully convinced that UMA solves the general OBO problem.
So… what’s an IAM practitioner to do in the face of forthcoming agentic AI? First off, don’t panic. We’ve got some foundational tools that can be brought to bear. Yes, you’ll likely need to improve your policy and authorization services, but that’s solvable. Second, double down on zero standing privilege efforts… every person is privileged in the enterprise… and so are all the agents! Lastly, it might be time for another look at UMA to see if it fits your use cases.
But there’s one more thing I would recommend you at least monitor, and it’s going to sound a little strange: OpenID Foundation’s Death and the Digital Estate working group. Why on earth do I recommend that? Consider that a child acting as the executor of a late parent’s will is an extremely common example of OBO. In the physical world, we have all manner of process to do this. But when it comes to managing that late parent’s digital assets (and associated credentials) we have comparatively nothing. I have a growing suspicion that to address those associated challenges, we are going to have to better address the OBO problem that has been with IAM for decades. Solving a very common, very human problem may just be the key to securely unlocking one of AI’s most promising futures. Yup, I didn’t see that coming either.