Back to the blog
October 13, 2026
|
Perspectives

AI agents don't have identities. They borrow yours.

Most AI agents run on API keys and OAuth grants that employees hand out. To secure them, govern the delegation, not the identity.

There's a narrative taking hold in the identity market right now: AI agents are a new class of identity, and the answer is to treat them like one. Give every agent its own identity, manage it in your IdP, apply your existing identity governance playbook, done.

‍

It's a comforting story. It's also not how any of this actually works.

‍

The practical reality: delegation, not identity

Here's what happens when someone in your organization builds an AI agent today. They pick a platform, they define what the agent should do, and then they wire up tools. Those tools are, overwhelmingly, actions and data access requests against other SaaS services: read my email, query this CRM, post to that channel, pull these files.

‍

Every one of those tools has to run in the context of some authority. And the mechanisms available for granting that authority are limited by what the target services support. In practice, the flow is one of two things:

‍

Give the agent an API key. The user generates a key in the target service and hands it to the agent. Most API keys are not scoped any further than the permissions of the user who created them. Some platforms offer additional granularity, but even then, the key operates in that user's authorization context. When the agent acts, it acts as them.

‍

Give the agent an OAuth grant. The user clicks through a consent screen and delegates a slice of their authority to the agent, persistently. That grant doesn't expire when the user closes their laptop. It's a long-running, standing delegation that lets the agent take action and access data on the user's behalf, indefinitely, until someone revokes it.

‍

Notice what's missing from both flows: the agent's identity. There isn't one. The target service sees a client app exercising a human's authority. It has no concept of the agent as a separate principal, and nothing to govern apart from the user who granted access. The "identity" of the agent is a fiction layered on top of a delegation chain.

‍

Where the identity model does work

Production environments are the one place the identity model genuinely holds up. If you're deploying agents into AWS, Google Cloud, or Azure, you have real primitives to work with: service accounts, IAM roles, workload identity, scoped permissions. You can create a machine identity, give it exactly the authority it needs, and audit it as a first-class principal. Engineering teams building production agentic systems should do this.

‍

But that's not where most agents are being created. The explosion is happening in no-code and low-code platforms, in AI assistants with connector marketplaces, in tools your employees adopted last Tuesday. None of those environments give you IAM roles. They give you a text box for an API key and a consent screen for an OAuth grant. The identity-first playbook has nothing to say about that world, and that world is where the growth is. GenAI apps went from 75 to more than 1,000 in 18 months, and the average org now has 26 distinct AI apps in use.

‍

This is the Workforce Edge: thousands of individual decisions about which tools to adopt and what access to grant, made outside IT's view.

‍

Why the identity framing fails you

If you model agents as identities, you go looking for them in your IdP. You won't find them there, because they were never provisioned. They were delegated into existence by individual employees, one grant and one key at a time.

‍

Worse, the identity framing points your controls at the wrong object. You can't deprovision an identity that doesn't exist. You can't apply conditional access to a session that looks exactly like the user's own session. You can't do access reviews on a principal your directory has never heard of.

‍

Standards for agent identity are coming, and some IdPs already offer them for agents built inside their own ecosystems. But the agent your marketing lead connected to Gmail last month won't be retrofitted into that model.

‍

What you can do is govern the delegation itself.

‍

Delegation is the control point

Once you accept that agents authenticate by borrowing human authority, the governance model gets a lot clearer. The questions stop being "what identities do my agents have?" and start being:

  • Who has delegated authority, and to what? Every OAuth grant and API key is discoverable. The average employee creates 88 OAuth grants, and 31 of them carry data-level permissions.
  • What scope did the delegation carry? Reading a calendar is different from sending email and modifying files. Most users click through consent screens without reading them, so someone else should.
  • Is the delegation still justified? Standing grants outlive the experiments that created them. The agent someone built in March still holds their authority in November, whether anyone uses it or not.
  • What happens when the human leaves? If offboarding ignores the grants and keys an employee issued, those credentials keep working in a departed employee's context.

‍

This is a different program than identity governance. It's closer to grant governance: continuous discovery of delegations, scope review, lifecycle management, and revocation. The good news is that the artifacts are all there. OAuth grants are enumerable. API key issuance leaves traces. You don't need agents to announce themselves; you need visibility into the authority your users are handing out.

‍

The mental model shift

The market wants to sell you agent identity because identity is the product it already has. But the security problem in front of you isn't a directory problem. It's a delegation problem: human authority, persistently extended to software that acts autonomously, at a pace no access review cycle was designed for.

‍

Stop hunting for agent identities in your directory. The authority lives in the grants and keys your employees have already handed out, and that's where you can control it.

‍

Nudge Security discovers the OAuth grants and API keys your employees create, including the ones they hand to AI agents, so you can review scopes, revoke stale access, and clean up delegations at offboarding. Start a free trial to see what authority is already out there.

Related posts

Report

Debunking the "stupid user" myth in security

Exploring the influence of employees’ perception
and emotions on security behaviors