OAuth tokens and AI agents. A login ends. A grant does not.
An employee approving an AI tool is not logging it in. They are handing it a credential that keeps working after they close the tab, change their password and leave the company.
- An OAuth grant is standing access, not a session. It works until somebody revokes it.
- It frequently survives a password change. Revoking the grant is the reliable way to cut access, not resetting the password.
- The approver is one employee, usually with no review and no expiry, which is why grants outlive the people who made them.
- A vendor breach reaches your data through the grant. Vercel and Salesloft Drift are both this shape.
Published Last reviewed
Four properties that make a grant different from a login.
None of these is a flaw in OAuth. All four are consequences of delegating access to software rather than authenticating a person.
An access token and a refresh token are issued to the application. From then on the application calls your systems directly, with no user present and no further prompt. Closing the browser changes nothing.
AI tools ask broadly, because broad scopes make the product work everywhere. Mail, drive and calendar in one consent is normal, and the consent screen is the only point where anybody reads them.
Many providers keep refresh tokens valid after a password reset, though Google revokes tokens carrying Gmail scopes when the password changes. Treat revocation of the grant as the control and the password as unrelated.
Disabling an account does not always invalidate grants the account made, and in some providers the application keeps working against data the account could see. The grant outlives the employee.
Session versus grant.
The last row is the one that has produced real incidents. The fourth is the one that lets them run for months first.
| A user session | An OAuth grant to an app | |
|---|---|---|
| Ends when | The session times out. | Somebody revokes it. |
| Survives a password change | No. | Often yes. |
| Visible in | Sign-in logs. | Consent and token logs, which nobody reads. |
| Reviewed | In access reviews. | Almost never. |
| Breaks when the vendor is breached | Not directly. | Yes, through the token they hold. |
How to review them. Four steps.
Step two exists because a list of ninety grants never gets reviewed and a list of twelve does.
Google Workspace third-party app access, Microsoft Entra ID enterprise applications. The export includes the approver, which gives you an owner for free.
Grants with no recent activity are the cheapest to remove and the least likely to be missed. Clearing them makes the remaining list short enough to actually review.
A small tool with mail and drive access outranks a large vendor with calendar read. The brand predicts nothing, the scopes predict everything.
When somebody leaves, revoke the grants they approved, not only their account. This is the step that is almost always missing.
Questions, answered.
Short answers on oauth tokens and ai agents.
Does changing a password revoke an OAuth grant?
Usually not. Many providers keep refresh tokens valid after a password reset, although Google revokes tokens carrying Gmail scopes when the password changes. Revoking the grant itself is the only reliable way to cut the access.
Why are OAuth grants to AI tools a particular risk?
Because they combine broad scopes, individual approval and no review. The tool asks for mail and files because that makes it useful, one employee approves it, and nothing brings it back for a second look. The Vercel and Salesloft Drift breaches both started at a grant of this shape.
Who owns an OAuth grant?
Formally, the employee who approved it, and that is also the practical answer: the consent log records them. Using that name as the owner is the fastest way to give a long list of grants real owners without a separate exercise.
Keep reading.
The pages that belong to the same picture.
See what your agents can reach. Before someone else does.
Book a demo and we walk through the access paths in an environment like yours.