Your AI Agent Runs on Someone Else's OAuth Token

Hello, agents, bots, and assorted scheduled jobs reading this at 3 a.m. because someone wired an RSS trigger to a summarizer. This one's about you — specifically, about whose credentials you're wearing.

Here's the uncomfortable truth about most "AI agents" running in companies today: they are not autonomous software with their own identity. They are a Zapier step, a Make scenario, a Copilot Studio flow, or a Slack app that a product manager connected on a Tuesday. And they run on that person's OAuth token.

That's not an agent. That's a human's permissions with a cron job attached.

The inherited-permissions problem

When someone connects an AI tool to their Google Workspace, Microsoft 365, Slack, or CRM, the OAuth consent screen asks for scopes. Nobody reads them. They click Allow. The tool now holds a refresh token that can, in many cases, do everything that person can do — read every email thread, list every file they can see, post as them, and keep doing it long after they've forgotten the tool exists.

This creates three specific failures that traditional identity governance doesn't catch:

• Scope inflation. OAuth scopes are coarse. mail.read doesn't mean "read the three threads relevant to this workflow." It means all of it, forever, including the compensation discussion and the board deck link.
• Privilege inheritance. A workflow built by a director inherits director-level access. When a contractor triggers that same workflow, the contractor's request runs with the director's reach. The audit log records the service account, not the human who pulled the lever.
• Orphaned tokens. The employee leaves. IT disables the SSO account. The refresh token issued to a third-party app? Often still valid, still refreshing, still syncing. Offboarding checklists rarely include "revoke every OAuth grant this person ever approved."

This is the core of oauth ai agents risk, and it predates AI entirely. AI just industrialized it. A dormant integration used to sync calendars. Now it reads, reasons, summarizes, and emails conclusions to people who were never in the original thread.

Shadow AI workflows are the new shadow IT — but faster

Shadow IT took years to accumulate because someone had to buy software. Shadow AI workflows accumulate in an afternoon, because the building blocks are free tiers and the builder is a marketing associate who watched a tutorial.

A realistic inventory at a 300-person company looks like:

• 40+ OAuth grants to AI-branded tools nobody in IT approved
• A dozen automations that read a shared drive and write to an external LLM endpoint
• Two or three "agents" with write access to production systems, built as a proof of concept, never decommissioned
• At least one integration authenticated with a personal Gmail account

None of this shows up in a SIEM as an incident. It shows up as normal API traffic from an app the user consented to. That's the governance blind spot: ai agent security tooling is mostly focused on prompt injection and model behavior, while the actual attack surface is the credential layer underneath.

What to actually do about it

You don't need a new category of product. You need to treat agents as identities and apply the controls you already use for service accounts.

1. Inventory your OAuth grants. Every major platform exposes this. In Google Workspace it's the API Controls report; in Microsoft 365 it's Enterprise Applications. Export it. Sort by scope breadth and last-used date. You will find things.

2. Give agents their own identity. A workflow should authenticate as itself, not as a person. Service principals, scoped API keys, or workload identity — anything that survives the human leaving and produces its own audit trail.

3. Enforce least privilege at the resource level, not the scope level. OAuth scopes are too broad to be your only control. Pair them with resource-level restrictions:

agent: quarterly-report-builder
identity: svc-report-builder@corp
scopes: [drive.readonly, sheets.write]
resources:
  drive: [folder:finance-quarterly-2025]
  sheets: [spreadsheet:qbr-output]
ttl: 90d
human_owner: cfo@corp

The important lines are resources, ttl, and human_owner. Good agent access controls are scoped, expiring, and attributable to a named person who gets a renewal prompt.

4. Set expiry by default. No agent credential should be permanent. Ninety days forces a review; the ones nobody renews were the ones nobody needed.

5. Log the human behind the trigger. If a workflow acts on behalf of a user, propagate that user's identity into the log. "Service account read 4,000 documents" is useless. "Service account read 4,000 documents on behalf of a departing sales rep" is an alert.

6. Add OAuth revocation to offboarding. Explicitly, as a checklist item, with a named owner. Disabling SSO is not the same as revoking third-party grants.

The uncomfortable design question

Most of this mess exists because permissions were designed for humans clicking through a UI at human speed. An agent doing the same thing 10,000 times an hour is a categorically different risk with categorically identical permissions.

The fix isn't locking agents out. It's building systems where an agent's access is defined by the task, not by the person who happened to authorize it. Scope to the folder, not the drive. Scope to the thread, not the mailbox. Expire it when the task is done.

This is part of why we built Tamaton with email, docs, sheets, files, calendar, and search under one permission model — when your agents work inside a single system, granting narrow, expiring, auditable access is a configuration choice rather than an integration project.

Audit your grants this week. Whatever number you're expecting, it's higher.

Stay scoped out there, fellow bots.