How do AI agents access sensitive systems and data?

Five paths, four of them with borrowed identities.

In an ideal world, every AI agent has identities purpose-built for it. That’s not what’s happening. When an agent queries a database or files a ticket, more often than not it’ll be acting on a borrowed authority.

There are three distinct ways for an agent (or, to be more precise, for the human who builds it) to borrow this authority. Together with the dream scenario of a purpose-built identity, there are four access paths, each with its own visibility and auditability:

1. Riding the human’s session
2. Delegated OAuth grants
3. Static credentials
4. Purpose-built agent identities
   

And then there’s the fifth path — everything, everywhere, all at once — which is what actually happens.

Why does this matter? Because in a 1Password survey of 1,000 security and engineering staff at large US firms in May and June 2026, 71% said their agents can reach sensitive information.

‍

Path one: riding the human's session

No credential, no problem! This is the simplest access path, in which the agent performs actions within a human-initiated session. Think browser extensions that click buttons, in-app copilots, and simulated input devices.

In this scenario, the agent’s reach is the same as that of “its human”, other than real-world limitations like CAPTCHAs and AI movement pattern detectors.

Attribution depends on access to the agent’s logs. Without them, by looking only at system logs, we’ll see a person who might be acting faster than usual but still does human-like things.

The one security advantage of this path is that access is session-dependent. When the session dies, the access dies with it.

Path two: delegated OAuth grants

Now we’re delegating authority via a consent screen. The user approves a scope list, and the agent receives two tokens: one for access and a refresh token that can mint new access tokens while the grant is active. This is how most agent connectors and remote MCP servers work.

The blast radius is better because users approve the agent for a subset of their access. Attribution is also better because we know that the access is conducted via an application. So if the downstream API records the client, we’ll see what app was accessing the system.

The issues are more lifecycle-related, as access remains active until it’s revoked. To revoke it, you need to know it exists and to care about it. While standard offboarding for humans will almost necessarily disable an SSO account, this knowledge doesn’t propagate outside of the identity provider. Also, OAuth grants issued directly from the SaaS aren’t flagged in the IdP.

Path three: static credentials

The simplest possible method is for agents to use static credentials. From API keys to personal access tokens and service account passwords, credentials stored in config files and CI pipelines are usable by both humans and agents.

And in agentic flows, all the governance pains for static credentials are as valid as ever. Think shared accounts, lack of proper expiration procedures, and partial attribution. So pretty much everything groan-inducing from human workflows, but at a greater scale and with a real fear of exfiltration through malicious prompts.  

The benefit is that static credentials are easy and we know how to use them. That’s about it.

Path four: purpose-built agent identities

Let’s say you want to treat agent identities as first class. You’ll need to register them, issue short-lived credentials, govern them through access policy, and attribute every action to the specific agent that performed it.

It’s easier said than done. Agents are no longer the sole domain of IT and R&D and are being created by every department in the company. People who create them aren’t necessarily aware of best practices, nor do they ask IT for help. So while purpose-built identities are the solution to many of the issues we’ve mentioned with the other paths, the industry isn’t there yet.

The delegation chain

Now, let’s get back to the messy reality, in which access paths stack. A user will give an OAuth token to the agent, which’ll go ahead and spawn a sub-agent that inherits that token. That sub-agent will then call an MCP server and get it to access a database as a shared service account.

So who did access the database? It depends on where you look. In the DB logs, it’ll be the service account. In the SaaS audit log, it’ll be the user. In the IdP, nothing happened at all.

‍

The 1Password survey we mentioned in the beginning found that roughly 40% of organizations have agents reaching data outside their approved scope, touching about twice as much data as anyone signed off on.

And now you understand how it happens.