Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Can an AI Agent See in Your Identity Provider Admin Console?
An agent in the admin console can see everything the role can open, screen by screen: user records, group memberships, application assignments, the API tokens page, SSO settings, and on a reset screen a temporary password. Ask which role the agent holds, what each screen shows it, and who approves a token, a reset or a new admin.
An identity provider admin console is the one screen that lists everyone in the company, the groups that decide what each person can open, and the tokens that let software act as them. An agent granted a role there does not read a single record. It reads the index of the company's access, one rendered page at a time, and every field on those pages arrives in the model's context with the task.
Whether the agent should hold the role is only the first question for an identity team. Roles decide which pages open, and vendors document that layer in detail. What a role cannot decide is what a page shows once it is open: the full profile, the token value at the moment it is created, the temporary password in a reset dialog. Authority and content are easy to conflate, and reviews usually leave the second unstated. What the console renders is the part a runbook does not record.
The sharpest record is the API token page. A token is the console's own product: it is created there, it inherits the rights of whoever created it, and it leaves as a working credential that outlives the task.
Key findings
- For an agent's run in an identity console to leave the directory intact, the values on each rendered screen would have to be replaced with consistent tokens before any model reads it, so a super admin API token renders as TOKEN_001 and a temporary password as PASS_014 for the whole run (What Is Render-Layer Tokenization?).
- It would also require a named person approving each token created, password reset and role grant, and a record of the screens the agent read, kept where the customer's own monitoring can read it (What Is an AI Control Record?).
- The vendor pages reviewed describe roles, token lifetimes and reset flows in detail, and no page reviewed describes a control that removes the values a console screen renders before the model reads them (Okta, API tokens, 2026).
- Okta's help page states that "read-only admins may create tokens" and that "API tokens are generated with the permissions of the user that created the token", which makes the token page a delegation of the creator's whole role (Okta, API tokens, 2026).
- Okta documents a reset as either an email link that "expires in one hour" or a temporary password where "the user must change their password upon signing in", and the second route puts the value on the console (Okta, Reset, 2026).
- Microsoft's page states that "Microsoft Entra ID autogenerates a temporary password for the user" and that "The temporary password never expires", so a value an agent read on a reset screen stays valid until someone changes it (Microsoft, 2026).
What does an agent read in an identity provider admin console?
A console is a directory with a control panel on top. The users list renders every account, and the profile renders a person's name, username, email, department, manager and status. Group pages render memberships, application pages render which applications each group can enter, and the administrator page renders who holds which role. Later pages hold the controls and the trail: the API tokens page, the SSO settings and the audit log. The exposure is not rare: 207 of the 616 security flaws published for AI agents in the year reviewed, 34%, let an attacker reach data the agent, its tools or its server could reach, and credentials were the largest exposed category (How Many Security Flaws in AI Agents Were Published in the Last Year?).
Which pages an agent can open is decided by the role. What arrives when one opens is decided by the page. A browser agent receives the rendered page as text, an image or both, and every field enters the model's context whether the task needs it or not (What Does an AI Agent See in a Screenshot?).
Applications trust the directory to say who a person is and what they may open, so a change on one page moves access downstream without another administrator touching those systems. The model reads the access map the rest of the estate uses.
Those pages are personal data by design: names, usernames, email addresses, department and manager, sometimes a phone number or employee ID. OWASP notes that "Personal identifiable information (PII) may be disclosed during interactions with the LLM", which describes a directory screen as much as a chat window (OWASP, LLM02, 2025).
A role does not filter a page. A read-only administrator who can open the users page reads the full profile. An agent that calls the identity provider's API from a shell reads a response body outside a browser control, a route a review should describe separately.
What do the vendors themselves say?
Okta's token page names the roles that may create a token, including read-only admins, says a token is "generated with the permissions of the user that created the token", and adds that "The only time you can view and copy the token is during the creation process" (Okta, API tokens, 2026). Tokens are "valid for 30 days and automatically renew every time they're used with an API request", and "Tokens issued by deactivated users are rejected" (Okta, API tokens, 2026). It is flagged as Classic Engine, covers the Tokens tab, and says nothing about resets or provisioning.
Okta's reset page and Microsoft's reset page describe the other screen. Okta offers an email link that "expires in one hour" or a temporary password where "the user must change their password upon signing in", and a checkbox that will "sign the user out of all devices and browsers" (Okta, Reset, 2026). Microsoft requires "at least the Password Administrator role" and states that "Microsoft Entra ID autogenerates a temporary password for the user" and that "The temporary password never expires" (Microsoft, 2026).
Okta's account of agent access sits one layer up. Cross App Access "centralizes authorization in the identity provider", and Agent SSO models "agentic connections as workload principals in Universal Directory" (Okta, Cross App Access, 2026), which registers the agent and scopes what it may reach without changing what a console page renders once it holds a role.
| Screen | What the vendor page documents | What a buyer should verify |
|---|---|---|
| API tokens (Okta) | Roles that may create tokens, including read-only admins; the token inherits its creator's permissions; shown once, then valid for 30 days and renewing in use | Whether an agent can mint a token, and which role it inherits |
| Password reset (Okta) | An email link that expires in an hour or a temporary password the admin sets; a sign-out checkbox; the flow completes without other factors | Which route the runbook names, and whether the value renders to the model |
| Agent access (Okta) | Cross App Access centralizes authorization in the identity provider; agents are workload principals | Whether registration changes what the console shows the agent |
What does an agent read on an API token page?
The record is a token page: a list of tokens with names, owners and status, a create dialog, and a value that appears once. An agent asked to set up a reporting integration opens the page, fills in a name, and reads the token.
The page is where a role becomes a credential. Okta lists "Super admins, org admins, group admins, group membership admins, and read-only admins" as roles that may create a token (Okta, API tokens, 2026). The token inherits the creator's rights, so the page delegates the role behind it.
What the model holds is a value that outlives the screen. An agent that creates a token reads it in the dialog and may write it into a configuration file or a handoff message. Least privilege is a limit here: a scoped role decides which pages open, not what a page shows (What Is Least Exposure?). GitHub tells users to treat access tokens like passwords, so a token page is password-equivalent material (What Can an AI Agent See in Your GitHub Settings?). A key rotation on a dashboard shows the same pattern (Can an AI Agent Rotate a Key in a Vendor Dashboard Without Seeing It?).
Not all of that content is authored by the administrator. Display names, group names and application names can come from users and vendors, so the reader with the most access reads text outsiders can write, and an attack that hid page elements from a generalist web agent reached an attack success rate of up to 70 percent in stealing specific PII (Liao et al., 2025).
What should a security team ask for in writing?
The written answer should start with the role and end with the screen. Ask which role the agent will hold, which pages it opens, whether it can mint a token or reset a password, what the model receives from a rendered screen on each page, who approves each action, and what record shows the screens and approvals. An answer that names a role and stops has answered the access question and left the exposure question open.
Zero trust grants no implicit trust to an account "based solely on their physical or network location", and an identity provider makes that decision, which settles access, not page content (NIST, 2020). OWASP's excessive agency entry describes the risk as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM", a risk about actions rather than fields (OWASP, LLM06, 2025). Its prompt injection entry advises to "Restrict the model's access privileges to the minimum necessary", a rule about what the agent may reach rather than what it reads (OWASP, LLM01, 2025).
Injection is not hypothetical for a directory. OWASP notes that "Indirect prompt injections occur when an LLM accepts input from external sources", and hostile text in content an application reads can "enable adversaries to remotely (without a direct interface) exploit LLM-integrated applications" (OWASP, LLM01, 2025; Greshake et al., 2023).
Name the pages the agent must open for the task, name the fields those pages use, and compare the lists. Anything on the second list that is not on the first is exposure.
What does a governed environment change?
A governed environment acts at the render layer, before a model reads a page. Values chosen by policy are replaced with consistent tokens for the whole run, so the agent works with USER_014, TOKEN_001 and PASS_014 in the fields where the console would show a person, a token or a temporary password. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms which values are tokenized and approves each consequential action, and every screen, action and approval is written to a record that exports to the organization's monitoring.
The page stays readable: the agent can still see the user list, the group memberships, the token's name and status, and the reset dialog's controls, because those are what the task needs. The credential values do not arrive, and they do not arrive on the next page either, because the token stays TOKEN_001 for the whole run. The record lets a reviewer see which console pages the agent read, which values were tokens, and who approved the token creation or the reset.
Its scope is the rendered console. It does not govern a direct API call, a script that authenticates to the identity provider, or the terminal, which is why a review should describe those routes separately. The two designs are set side by side in RedactSure vs Okta: 2026 Comparison & Alternative.
What the record shows
What a console hands an agent is decided at the render layer: when a policy replaces the values on each screen with consistent tokens before the model reads it, the agent works the directory with USER_014, TOKEN_001 and PASS_014 in front of it, and the real values resolve only at the destination a named person approved. Roles decide which pages open, each page renders the full record, the token page can delegate the creator's whole role, and the reset screen can produce a working password. Nothing in those pages describes a control that filters the fields once a page is open. One check: give a test agent the least role that can finish a task, capture every screen it reads, and compare those fields with the fields the task used. The difference is the exposure the review has to name.
Methodology and limitations
The page rests on Okta and Microsoft documentation, three OWASP entries, NIST's zero trust guidance, two research papers and one existing comparison of the two designs. The vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control, and research is cited for what its abstract page states.
No product on this page was tested for it, and "not described" means the pages reviewed. Vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, an API token page in an identity provider console, and not an organization. A pilot of one workflow on the organization's own screens is still the test, and whether a particular console meets a contractual, regulatory or audit requirement belongs to counsel, assessors and the organization's own security and compliance officers.
Frequently asked questions
What can an AI agent see in an identity provider admin console?
Everything the role it holds can open, rendered one page at a time: the user list and each profile, group memberships, application assignments, admin roles, the API token page, SSO settings and the audit log. On a reset screen it can also see a temporary password when the runbook creates one. The role decides which pages open, and the page decides which fields arrive, so the answer needs both. A wider role adds pages.
Does a read-only admin role make the agent safe?
No. Okta's help page states that read-only admins may create tokens, and that a token is generated with the permissions of the user that created it, so a read-only agent can still mint a credential that reads the directory. Read-only limits changes to the directory, not what the console renders to the agent reading it. A role limits which pages open, not what one page shows. The page is the unit. The exposure that remains is the content of every page that role can open.
What does an agent read on the API token page?
The token list with names, owners and status, then the create dialog and the value the console returns once. Okta states that the only time a token can be viewed and copied is during creation, so the screen is the one place the value appears. The token then works for 30 days and renews while it is used. An agent that reads it can carry it into a configuration file or a message.
Can an agent read a temporary password on the reset screen?
Yes, on the route where the administrator sets one. Okta documents a temporary password that the user must change at sign-in, and Microsoft states that Entra autogenerates a temporary password that never expires. Both render the value on the console the agent is reading. The email-link route keeps the new value out of the console, because the user sets it from their own mailbox instead.
Who should approve a token creation or a password reset?
A named person with authority over the account, not the agent and not the vendor's review model. A token inherits the rights of whoever created it, so approval has to weigh the role behind the token rather than the task in front of it. A reset hands over an account, which makes the approver part of the identity decision. The approval should name the action, the account and the person.
What record should an admin console run leave?
One that shows the pages the agent read, the values that were replaced with tokens, the token or account it acted on, and the person who approved the action. A change log alone is not that record, because it shows what changed and not what the model saw before the change. The record should export to the organization's own monitoring, so a reviewer can compare the run with the ticket months later.
How RedactSure Keeps Token Values Off the Admin Console
An admin console shows the whole directory to the role that opens it, and the controls reviewed here decide which pages open, not what each page renders. Okta documents that a token is "generated with the permissions of the user that created the token" (Okta, API tokens, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, an agent creating a token read the value the console printed once and carried it into the run. Inside the governed environment, the value renders as TOKEN_001 and the agent creates the token through that placeholder; the real value resolves only at the destination a named administrator approved, and the record shows the screens read and the approver.
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
The value an agent reads while it creates a token outlives the task that needed it. Bring one admin task and see, with test values, what the model reads and where the real token lands. Book a demo