AI agent identity: it's just OAuth

I keep getting asked (by non-security folks) about how organizations should handle AI agent identity and permissions — I’m clearly not the only one. Security folks, though, aren’t really talking about this. The perception is that we need new solutions for authenticating and authorizing AI agents. Do we?

No, really, do we? I was talking to a friend of mine about this, and he made a really good point: if you were a developer building a random SaaS app, why would you prioritize making it easier for agents to use your app, instead of just building your own AI agent or assistant in your app? I’m embarrassed to say that I hadn’t stopped to consider if I agreed with the inherent assumptions present in the question.

I think that yes, SaaS apps will want to make it possible to manage agent authentication and authorization, but it might be a little while until we get there. There is definitely a desire from consumers — an agent will only become more useful as it’s more personalized, and able to take more actions on your behalf. But it might be a while until we get there on the app side: first, we’ll probably see apps try to build some AI functionality in-app first, and then maybe they’ll be overwhelmed with requests when individuals give agents access to their accounts directly. Eventually, though, I suspect it’ll look kind of like the adoption of Plaid: initial reticence that this will lead to more competition, then increased interest when that connectivity makes it easier to provide higher-value services.

So I think we will need a solution here. So why aren’t security folks talking about this? As with many other market-wide changes, the difficulty doesn’t lie in innovating new technology — most of what we need already exists in OAuth — but in adoption. The real challenge is that many organizations and products haven’t fully embraced and implemented OAuth, regardless of any interest in agents.

Why OAuth makes sense

When building an app that agents can use, we need a way to grant them limited, controlled access to resources. These automated agents need to access data on behalf of users or organizations, but with appropriate restrictions and the ability to revoke access. We need to be able to restrict their access — they need different levels of access for different tasks — and we need to be able to audit what they’re doing.

OAuth provides exactly this: a standardized way to delegate limited access to resources without sharing full credentials. It allows applications to request specific permissions (scopes) on behalf of users, with those users explicitly approving what access they’re granting.

Granular permission scopes in OAuth are perfect for agent access patterns. Instead of giving an agent full access to an API, you can grant specific read or write permissions to particular resources. These scopes can be composed as needed, allowing for precise control over the actions an agent can take.

OAuth also lets you handle the distinction between user-level and organizational-level permissions. When an agent needs access to a user’s calendar, that should be tied to that user’s identity. When it needs broader access to organizational resources like a shared knowledge base, that should be tied to an organization.

OAuth tokens are meant to expire (or at the very least, be revoked), unlike API keys which tend to live forever in your environment. Yes, you can also have long-lived OAuth refresh tokens, but the access token itself is meant to be short-lived. (Yes, some also live forever.) This natural life cycle means you don’t have to worry about persistent access.

OAuth makes sense for AI agents. Again, I’m not the only one who has come to this conclusion.

Implementing OAuth scopes for AI agents

Have apps that should have really not implemented OAuth support? Yes. The minimum bar these days is SSO — you’re lucky if you get OAuth, SCIM, or audit logs.

So let’s assume you’ve gone through the hype cycle and are now on the slope of enlightenment and decided that yes, your app will be adding support for agent identities. What would you need to do?

Start with your existing permission model

Actually, pause — before thinking about building agent-specific authorization in your application, take a step back and make sure you have solid authorization fundamentals, with clearly defined roles that map to actual user needs and workflows, with proper documentation of what permissions each role includes. These roles should follow a logical hierarchy — say, if an admin role inherits reader permissions, that pattern should be consistent throughout your system; or, an auditor role should have read access everywhere. You can also get more fine-grained and allow user-defined roles, which are groupings of permissions. (I wouldn’t suggest you start here, though: users will come up with weird groupings of permissions that will then be hard to debug, the roles won’t get updated when you add new permissions, and most of your users will have similar role needs so you should really give them a decent starting point. Once you’re a cloud provider with dozens of different products and hundreds of permissions, sure, allow user-defined roles.)

Instead of creating ‘AI agent’ permissions, fix your existing ones. If a global API key is the only granularity of permissions you have today, that’s your actual problem. You need separate read and write permissions for each action, and you need to clearly document what each permission allows.

Implementing organizational scopes

When developing OAuth scopes, they should ideally match your existing permission models — if you have reader and editor roles, you should have corresponding OAuth scopes. Don’t just make it one allows-everything scope like an API key — you don’t want users to be constantly over-provisioning access. Follow your existing role inheritance patterns. There’s no need to create a separate hierarchy just for OAuth.

A significant part of the work to support OAuth is also giving admins controls to not allow certain OAuth apps or scopes. This is the real value of using OAuth — admins will have the ability to easily set policies for their entire organization — right now, they have no idea who is bringing a personal OpenAI API key to work. Consider only letting admin users generate OAuth tokens with the most sensitive or permissive scopes.

In your audit logs, every action taken with an OAuth token should be logged with both the token identifier and the associated user or organizational context.

Where AI agents need special handling

While most permissions can map to existing patterns, there are some agent-specific considerations:

• Rate limits serve different purposes. For human accounts, they’re a safety net in case of compromise. For agent tokens, they’re an essential control — you need separate limits to ensure automated access doesn’t impact human users who actually need to get work done. If my agent gets rate limited then, I, as a human, should still be able to use the service. You’re most likely already doing this when implementing OAuth, but it becomes particularly important for dealing with agents.

• Cost controls matter more for automated access. Consider restricting operations that could incur significant costs to an organization if an agent goes wild, like expensive API calls or queries.

Still use API keys for organization access

We’ve been talking about supporting authorization for user-level activities, but you may also want to authorize agents at the admin-level to perform organization-wide duties. You could have the agent use OAuth to get authorization as a specific admin, but for long-term persistent access, this organization level set of duties is usually supported via API keys. You’ll still want to take into account some of the above considerations, like rate- or cost- limiting API keys separately.

Why this solution kind of sucks

Why isn’t this already possible? Because OAuth isn’t as widely supported and as visible as it should be. (Also, it’s not necessarily the easiest thing to implement.)

But building proper OAuth support isn’t just work for service providers — the flip side is that identity providers need to step up too. An admin should be able to see, for everyone in their organization, which users have granted OAuth access to their accounts and how that’s being used — but this list of connections is not often reviewed today, making those blocking controls even more important. (Check out your Google account connections to find apps you forgot you signed into 5 years ago.)

Where this solution fails completely

I’ve also completely ignored where agents are clearly heading — being able to perform operations as if they were you, on your device, like Claude MCP, Claude computer use or ChatGPT desktop. This is a much more annoying problem to solve authorization for.

Apple has taken the lead in improving privacy and security settings overall by giving you controls over which apps can say, find devices on your local network, but these are still pretty coarse-grained. It’s like when a Chrome extension asks to see and change all browser data. We have more permissions and controls than we did a few years ago, but these aren’t fine-grained enough for the world we’re about to be living in.

I don’t know what the right solution here is. It’s not a separate user account on your device, as that’s completely segmented from your user account, but you are trying to share data. It’s also not something like a Linux process user owner, where you can attribute a process to a specific user, since it’s not like only Claude is running Spotify; you are also running Spotify. So, here, we probably do need something new, even if it’s just more fine-grained permissions. Either your OS will need to give you a reasonable way to limit what a local agent does, or an app will need to give you a reasonable way to separate ‘who’ is taking an action, or both.

What bothers me the most about the on-device agent identity story is that it’s the lowest common denominator. You can design the perfect solution for letting an agent use an OAuth token to access a website as you, but that falls apart the second the agent is a stowaway in your browser session, and likely only detectable with some sketchy adtech behavioural analytics.

Start by building decent OAuth scopes

Forget about agent-specific solutions for now, and instead focus on implementing proper OAuth scopes in your product. Build clear, well-documented permission models, and create granular scopes that map to real use cases. The effort you put into improving your permission model will benefit both humans and agents alike.