OAuth Scopes and Non-Human Identities:
The New Attack Surface in Enterprise AI

Every time an employee connects ChatGPT Enterprise to their calendar, or lets Copilot read their inbox, a new kind of identity is created inside the organization — one that isn’t a person, doesn’t sleep, and often ends up with more access than anyone realizes. This is the world of non-human identities, and understanding how OAuth scopes work is the starting point for reasoning about the risk they carry.

How an AI agent gets access

When you connect an AI tool to a SaaS platform — Google Workspace, Microsoft 365, Salesforce — it doesn’t get your password. Instead, it goes through OAuth 2.0: the app requests a set of permissions called scopes (“read your email,” “create calendar events,” “access all files in Drive”), you approve them, and the identity provider issues an access token the app can use going forward. That token is what security teams need to track — not a login, but a standing grant of capability.

A single OAuth grant can quietly bundle access across mail, storage, and CRM. (Image by author)

Why scope creep happens

In practice, apps tend to request broader scopes than any single feature needs — partly for convenience during development, partly because narrow, task-specific scopes aren’t always available from the platform. An integration that only needs to read calendar availability may request full read/write access to email as well, because that’s the scope bundle the platform offers. Multiply that across dozens of AI integrations connected by different employees, and an organization ends up with a sprawling, largely invisible map of standing access it never explicitly approved at that scale.

What makes non-human identities different to monitor

• No natural login pattern — a human has a rough daily rhythm; a service account or agent can call an API at any hour without that being inherently suspicious.
• Long-lived tokens — unlike a browser session, an OAuth token can remain valid for months, surviving well past the point someone stopped actively using the integration.
• Delegated, not attributable, actions — when an agent reads a file or sends a message, the audit log often shows the app’s identity, not which employee’s data it’s acting on behalf of, making incident investigation harder.
• Discovery gaps — many organizations simply don’t have full visibility into which third-party apps their employees have granted access to, because approval often happens with a single click outside IT’s purview.

Anomalous token activity as a detection signal

Because non-human identities don’t behave like people, effective monitoring looks for deviations from an app’s established pattern rather than trying to apply human-style anomaly detection. A calendar-reading integration suddenly making bulk file-download calls, or a token that’s been dormant for months abruptly reactivating with elevated API usage, are the kinds of signals that matter — the goal isn’t flagging automated behavior itself, but flagging automated behavior that changes shape.

Reducing the exposure

1. Maintain an inventory of every third-party app with OAuth access, not just the ones IT explicitly provisioned.
2. Review granted scopes periodically and revoke ones that exceed what the integration actually uses.
3. Treat token revocation as a routine offboarding step — for both departing employees and retired integrations.
4. Alert on behavioral deviation from an app’s historical usage pattern, not just on the presence of automated access.

Conclusion

AI copilots and agents are becoming some of the most privileged identities inside modern SaaS environments, often by accident rather than design. Treating OAuth scopes and token activity as a first-class security surface — with the same rigor applied to human account monitoring — is quickly becoming table stakes rather than a nice-to-have.