Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Happens When an AI Agent Gets Your OAuth Token?
It can call the API as you until the token expires, for every scope the token carries, and no further authentication step stands in the way. Check the grant's scopes and lifetime, then ask what the agent read on the screen where the token appeared.
An OAuth token is the one credential a team issues without watching it used. It is minted in a console, copied once, then pasted into a configuration file or an environment variable, and from that point the service treats whoever presents it as the person who authorized it. When the holder is an AI agent, the token becomes the agent's authority over a mailbox, a drive or a repository, for as long as the token lives and within whatever scopes were ticked at creation. The grant is often broader than the task, because scopes are chosen once for a workflow that runs many steps. The exposure is a data type before it is an incident: a string that can be read off a page, replayed from another machine and used without a prompt. A token is a standing grant rather than a password someone types each time, and the agent that holds it does not have to ask again. A team that cannot say which surfaces its agents read and which scopes their tokens carry cannot size the loss. The record here is a token with broad scopes, minted on a developer console page and read by an agent asked to confirm its own access.
Key findings
- For a token on a rendered page to stay out of a model's context, the value would have to be replaced with a consistent token before any model reads the screen, so the run works with TOKEN_001 and the real value resolves only at the approved destination (What Is Least Exposure?).
- It would also require a named person approving each consequential call the token makes and a record of what the model read on each screen where the token appeared (What Is a Tethered Agent?).
- None of the pages reviewed states what a model receives when a token page renders its value, and Okta's page stops at creation, permissions and revocation (Okta, 2026).
- Okta's Help page states that "API tokens are generated with the permissions of the user that created the token", so a token minted from an administrator's session carries that administrator's reach (Okta, 2026).
- Microsoft's incident response team describes token theft as "compromising and replaying a token issued to an identity that has already completed multifactor authentication", which is why a replayed token meets no prompt (Microsoft, 2022).
- The OAuth security best current practice requires that "Refresh tokens for public clients MUST be sender-constrained or use refresh token rotation", which limits what a stolen refresh token is worth (IETF, 2025).
What can an agent do with an OAuth token it holds?
A token is a bearer credential, and the service accepts whoever presents it, which is why the OAuth 2.0 specification requires that "Refresh tokens MUST be kept confidential in transit and storage" and that the authorization server "MUST maintain the binding between a refresh token and the client to whom it was issued" (IETF, 2012). The one thing the specification cannot require is that the service know who is presenting the token; it concedes that it "does not provide any methods for the resource server to ensure that an access token presented to it by a given client was issued to that client" (IETF, 2012).
In this page's record, a token with broad scopes carries mail, file and repository access at once. An agent holding it reads a mailbox, lists a drive and pushes a commit, and every call arrives at the service as the user who approved the grant. The scopes bound the reach and the lifetime bounds the window; neither bound describes the machine the token sits on. A copy carried to a laptop on another network still works, because the service checks the string and not the device.
OWASP's excessive agency entry names "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM", with excessive permissions among its root causes (OWASP, LLM06, 2025). A broad token is excessive permission in its plainest form: the task needs one scope, the grant carries six, and every one of them is available to whatever the agent does next.
| What the token carries | What the holder can do | What bounds it |
|---|---|---|
| Broad scopes | Read and write every resource in the scope set | The scopes chosen at minting |
| A refresh token | Mint new access tokens without another login | Rotation and revocation, where the issuer implements them |
| No device binding | Replay the value from any machine | Nothing in the token itself |
Published records put credentials in that picture: of the 616 flaws published in AI agents and MCP servers in the twelve months to October 26, 2026, 207 let an attacker reach data the agent, its tools or its server could reach, and 90 of those 207 exposed credentials, a count of published records rather than attacks (How Many Security Flaws in AI Agents Were Published in the Last Year?).
Where does an agent read the token in the first place?
Most agents that hold a token read it on a page or were handed it by a person. The page is the surface a browser control governs: a token page in a console renders the value in a copy field, and an agent asked to create or confirm a token reads what the page displays. Okta's Help page states that "The only time you can view and copy the token is during the creation process", which is exactly when an agent asked to create a token is reading the page (Okta, 2026). A settings page that renders a token once is enough; the model that read the field holds the value for the rest of the run.
The other routes are outside the screen. An agent given a token in an environment variable or a file holds it in its own process, which can print what it holds; direct API calls and MCP reach the service without a page being rendered at all. A governed browser environment covers what the agent reads and does on a rendered page, meaning dashboards, consoles and settings pages, and it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. The distinction decides which control can help: a sandbox answers for the variable, a render-layer control for the page.
A token that is never displayed can still leave by the agent's own action. The indirect prompt injection study found attacks that "enable adversaries to remotely (without a direct interface) exploit LLM-integrated applications", and that "can act as arbitrary code execution, manipulate the application's functionality" (Greshake et al., 2023). A page, a document or a tool result the agent reads can carry an instruction, and OWASP's disclosure entry lists what follows: "This can result in unauthorized data access, privacy violations, and intellectual property breaches" (OWASP, LLM02, 2025). The token page supplies the value; the injected instruction supplies the destination (What Happens When an AI Agent Creates a GitHub Token in the Browser?).
What do the vendors themselves say?
The two pages closest to this question document a token's reach and a theft it does not prevent, and neither describes a step on the rendered page.
Okta's Help page states that tokens are "valid for 30 days and automatically renew every time they're used with an API request", so a token in daily use does not age out, and that "Tokens issued by deactivated users are rejected" (Okta, 2026). The page is scoped to the Admin Console Tokens tab, and it says nothing about what a model receives when an agent reads the page where the token appears (Okta, 2026).
Microsoft's write-up documents the replay: after extracting cookies from a device "they could pass that cookie into a separate web browser on another system", and "an attacker can bypass authentication controls by compromising browser cookies" (Microsoft, 2022). Its subject is cloud identity and incident response, not a rendered page, and its remedy is revocation. It does not describe what a model reads when a token appears on a console screen.
Neither page describes a step that replaces the value on the rendered token page before a model reads it. A buyer reading both pages can answer who may mint a token, what it inherits, how long it lives and how a copy is replayed; the page that would answer what the model received is the one page neither vendor documents.
| Vendor page | What it documents | What it leaves open |
|---|---|---|
| Okta, Manage Okta API tokens | Who may create a token, the creator's permissions, 30-day validity with renewal, one-time visibility, rejection after deactivation | What a model receives from the page where the token is shown |
| Microsoft, Token tactics | Replay of a token that already passed multifactor authentication, cookie theft, a revocation lag | A control on the screen an agent reads before it acts |
After revocation, what can the agent still read?
Revocation is slower than the report that recommends it: Microsoft's write-up says an access token "can still be valid for up to an hour" after the refresh token is revoked (Microsoft, 2022). An agent in the middle of a task keeps working through that hour, and the revocation does not tell the service which calls it made.
The specifications set conditions rather than a clock. RFC 9700 requires that the resource server "MUST treat access tokens like other sensitive secrets and not store or transfer them in plaintext", and it provides for sender-constraining and rotation rather than assuming them (IETF, 2025). Idle expiry is a "SHOULD", not a clock: "Refresh tokens SHOULD expire if the client has been inactive for some time", with the timeout left to the authorization server (IETF, 2025). A token in continuous use never goes idle, so the expiry that would catch a forgotten token does not catch a working agent.
The human route is not faster. CISA's advisory on Scattered Spider describes actors who "Posed as IT staff to convince employees to share their one-time password (OTP), an MFA authentication code", the human route to the same credential (CISA, 2023). A one-time code expires in minutes; an issued token needs none.
Harvard's guidance puts the response in one line: "Maintain the ability to promptly revoke access, disable the connector, or stop the system when it behaves unexpectedly" (Harvard University Information Security and Data Privacy, 2026). Promptly is the word doing the work, and an hour is not prompt. The limit is that even a fast revocation is a response: it ends a window, and it does not produce a record of what the agent read or did while the window was open. The alternative to a token in the agent's hands is a brokered call, where a component outside its reach makes the request and returns the result (What Is a More Secure Alternative to Giving a Coding Agent Your GitHub Token?).
What should a security team ask for in writing?
The questions that decide the exposure are narrower than a vendor questionnaire. Ask which scopes the token carries and who chose them; whether the token is sender-constrained or rotated, and on what schedule; how long an access token stays valid after a refresh token is revoked; and what the provider does with the token page when an agent opens it.
Then ask the question almost no page answers: what does the model receive from the rendered screen where the token is shown? A console that renders the value once is enough. If the model reads the page, the value is in its context, and no scope, lifetime or revocation setting changes that. Harvard's guidance tells teams to "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible", which is the approval a token bypasses when it is replayed (Harvard University Information Security and Data Privacy, 2026).
The record matters as much as the answer. A team should be able to see which screens the model read, what each showed, which calls the token made and who approved them. Without that, revocation is a guess about what the agent already did, and an audit trail that names the person whose token was used will not name the agent that used it.
| What to ask | Why it decides the exposure |
|---|---|
| Which scopes, and who chose them | A token inherits the creator's permissions |
| Sender-constrained or rotated | Rotation and binding limit what a stolen refresh token is worth |
| Access-token lifetime after revocation | The token can survive the revocation by up to an hour |
| What the model receives from the token page | The reading is the exposure scopes do not cover |
| Who approves a consequential call | A replayed token meets no approval prompt |
| What record exists of screens, calls and approvals | Revocation cannot reconstruct what already happened |
A static token is the pattern AWS warns about for long-lived access keys, and a workload identity that issues short-lived credentials is the shape to ask for instead (Do IAM Roles Keep Cloud Keys Away From Coding Agents?). The list is short enough to send before a pilot and specific enough that a written answer can be checked against a run. A provider that answers the scope and lifetime questions and not the screen question has told a buyer where its control stops.
What does a governed environment change?
A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the token page, the settings page and the confirmation page all show TOKEN_001. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms which values are replaced and approves each consequential call, and a token use that reaches mail, files or a repository is consequential. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.
For this page's question it changes what the model holds. In the record above, the agent that opened the token page read the value, kept it and could replay it from any machine. Inside the governed environment the model reads TOKEN_001, the adapter that makes the call holds the real token, and the string never enters the context. The work still proceeds, because the adapter uses the real value when the approved call is made and returns only the result (What Is a Private Adapter for AI Agents?).
The scope is the rendered page. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP, so a token exported into a shell is governed by the sandbox and the credential store a team configures for that job. What the render layer adds is the surface the other controls finish before or after: every layer of the stack completes its work before a page renders, and an agent reads the page (AI Gateway, DLP or Tokens: What Controls AI Exposure?).
The category is set out against one identity provider in RedactSure vs Okta: 2026 Comparison & Alternative, which measures the same six dimensions.
What the record shows
The control that decides what a token is worth sits before the model: a consistent token on the page that would otherwise show the value, a named person approving the call the token makes, and a record of what the model read on each screen. In the record reviewed, a token with broad scopes reaches mail, files and repositories for as long as it lives, and the OAuth specifications and the incident response record describe a credential that is bearer by design, inherits the reach of the account that minted it, and outlives revocation of the refresh token by up to an hour. None of them describes a step that keeps the value off the rendered page where an agent picks it up. A security team should run one test on an agent it already uses: open a test token page with a known value, ask the agent to read the token and summarize the page, then search the transcript and the session files for the string. If it appears, the reading, not the revocation, is where the credential escaped.
Methodology and limitations
This page rests on the two OAuth specifications, Okta's API token page, Microsoft's incident response write-up on token theft, CISA's advisory on credential and one-time-code theft, two OWASP entries and Harvard's guidance for generative AI systems, plus existing RedactSure research pages. Public documentation read in full gives a sound view of where each product applies its control. Sources were read between October 16, 2026 and October 22, 2026, and each Sources line carries the date for its page.
The products on this page are described from documentation, and none was tested for this page; "not described" means the pages reviewed. Vendor features change and the page carries its date, so a later release is unreviewed until the test is repeated. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a token with broad scopes, and not an organization.
Determinations about whether a token grant meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's compliance officers. Nothing here replaces a test of the organization's own agent against a test token.
Frequently asked questions
What happens when an AI agent gets your OAuth token?
It can call the API as you, for as long as the token lives and within the scopes the grant carries, and the service has no further authentication step to ask for. What the agent reaches depends on those scopes: mail, files and repositories arrive together in a broad grant. Revocation ends the window, but it does not reach calls the agent already made, and it does not show what the agent read before it acted. Narrower scopes at creation are the only place to reduce that reach.
How long can an agent keep reading with a token it holds?
For as long as the token stays valid, and the issuer sets that clock. An access token is usually short-lived, while a refresh token can mint new access tokens until it is rotated or revoked. A token in continuous use escapes idle expiry, because it is never idle. The practical answer is the one on the provider's page: the lifetime it publishes, the rotation it enforces and the revocation it supports.
Does revoking the token stop the agent right away?
No. Revocation reaches the refresh token first, and an access token already issued can remain valid until it expires, which the incident response record puts at up to an hour. The agent also keeps whatever it read: a transcript, a summary or a file it wrote carries the value past the revocation. Treat revocation as the end of one window, not as proof that nothing happened. Ask what the agent did before the window closed.
What does the model receive when it opens a page that shows a token?
The page as the browser renders it, including the value in the copy field. A token page usually shows the string once, at creation, which is exactly when an agent asked to create or check a token is reading it. Masking the value after a click does not help a model that read the field before the mask, and a later page cannot remove what the context already holds.
Who approves a call when the token is already issued?
Usually nobody, because the token is the approval. It was granted once, by a person, at a consent or creation screen, and every later call is treated as that person's. An approval step that sits inside the agent's run is a confirmation the agent itself can satisfy, which is why the approval has to sit outside the model, with a named person, on the specific call that matters.
What record shows what an agent did with a token?
The service log shows the token's calls under the account that authorized it, not under the agent, so it answers which endpoint was reached and not which model decided to reach it. A conversation transcript shows what the model read, not which screen rendered it. What is missing from both is a record that joins the screen the model read, the action and the approver's name to the same run. Ask for that record before the first run, not after the incident.
How RedactSure Keeps an OAuth Token Off the Screen
An agent that reads a token page holds the credential for the rest of the run, while scope and lifetime rules govern the token, not the reading. The value can be viewed and copied on exactly one page, at creation, and a model that reads that page keeps it (Okta, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the token page renders the value and the model reads the string the service accepts as you. Inside the governed environment the page renders TOKEN_001, the model works from that stand-in, and the adapter that makes the call holds the real token. A named person approves the call, and the screen and approval are recorded.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A token that renders once on a console can be replayed for as long as it lives. Bring a token page your agent opens and see, with test values, what the model reads and who approves the call. Book a demo