Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is Okta Enough to Secure AI Agents on Customer Data?
No, not for the customer record the application renders: Okta can give every agent an identity and an administrator-approved path to each app, and the record the app draws is still read in full by the model. Check what the model receives on the first screen that carries a real value, and who approves the change.
No, not on the record the application draws. An agent signs in through Okta, the administrator has already approved the connection, and a customer record opens. The sign-in is visible: the agent has a directory entry and a list of applications it may reach, and an identity team can read that from the console. The page that follows is drawn by the application, and every field on it reaches the model as the application drew it. That boundary is the question for a team on Okta that wants an agent on customer records. Identity decides who gets in and what a token may call; the application decides what the screen shows, and the model reads the screen. A customer record after single sign-on carries a name, a date of birth, a tax identification number, a telephone number, income and net worth, the fields FINRA's account-record comparison lists (FINRA, 2026). The record shown here is ordinary, bought and full of values a customer did not choose to show a model. What Okta is enough for, and what the same agent still needs before the record it reads is governed, is the question a security review has to answer.
Key findings
- For Okta to secure a customer record as completely as the sign-in, the values a page renders would have to be replaced with consistent tokens before any model reads the screen, with real values released only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each change and a record of what the model received and who approved it, which the identity layer does not produce (How to Secure AI Agents That Access Customer Data).
- The Okta pages reviewed describe an identity protocol, administrator consent and workload identity, and do not state what a model still receives from a page an application renders (Okta, Cross App Access, 2026).
- Okta's API token page states that "API tokens are generated with the permissions of the user that created the token" and that tokens are "valid for 30 days and automatically renew every time they're used", which bounds a credential and says nothing about a field (Okta Help, 2026).
- ST-WebAgentBench reports that web agents' "average CuP [Completion under Policy] is less than two-thirds of their nominal completion rate", so a grant does not predict what it does once the record is open (Levy et al., 2026).
What does Okta decide before an agent opens a customer record?
Okta's contribution is a set of decisions made before any record appears. Cross App Access is "an open identity protocol that centralizes authorization in the identity provider", and the resource application accepts a signed assertion rather than walking a person through a consent screen (Okta, Cross App Access, 2026). It is built on "the IETF's Identity Assertion JWT Authorization Grant (ID-JAG)" and extended to Model Context Protocol servers.
Agent SSO "is included in core Workforce SSO plans" and models "agentic connections as workload principals in Universal Directory", so the agent has a directory record of its own (Okta, Cross App Access, 2026). That directory record is what an access review examines.
The decisions cover admission and reach: whether the agent authenticates, which applications answer it, and what its token may call. Each one narrows where the agent goes. None describes a page, because the record is drawn by the application after the assertion is accepted. The review of 86 AI security and data protection products counts Okta among the identity and access tools, and 58 of the 86 describe control over where data can go, while 1 describes masking what an AI agent reads on the web pages it works in (How Many AI Security Products Control What an AI Agent Sees?). An identity-first design governs the identity rather than a model's view, the right scope for admission and the wrong one for a record (RedactSure vs CyberArk: 2026 Comparison & Alternative).
What does the model receive when the application renders the customer record?
After the assertion is accepted, the application queries its own store and draws the record. On a brokerage account that screen carries a name, "Date of Birth, for an individual", a tax identification number, a telephone number, annual income, net worth and "The account's investment objectives", the fields the account-record comparison lists (FINRA, 2026). The model receives that page as text and images, and the values are in it. The assertion that admitted the agent is not.
Nothing in the pages reviewed replaces a value on the screen before the model reads it. The layering explains why the gap is structural: the network, the proxy, the data store and the identity provider each finish their work before a page renders, and until recently only a person read the result. An agent reads the rendered page, which leaves every lower layer blind to the values on it (What Is Render-Layer Tokenization?).
The exposure is set by the first screen that carries a real value, because a value in the context can be carried into the next form by an instruction the agent later reads. A value repeated in a later answer travels with it, which is why the first screen matters more than the last one. The screen is drawn once and read in every later step of the task.
What do the vendors themselves say?
Okta's own pages give the identity layer's threat model, its credential rules and its consent design.
The Okta Security advisory describes the pattern an identity team fears: "multiple US-based Okta customers have reported a consistent pattern of social engineering attacks against their IT service desk personnel", with callers trying to "convince service desk personnel to reset all Multi-factor Authentication (MFA) factors enrolled by highly privileged users" (Okta Security, 2026). The first listed control is to "Strengthen help desk identity verification processes using visual verification" (Okta Security, 2026). That hardens admission; a session admitted through a legitimate sign-in still renders the record.
Okta Help sets the rules for API tokens: admin roles mint them, they carry their creator's permissions, and "The only time you can view and copy the token is during the creation process", which is custody of a credential, not a statement about a page (Okta Help, 2026).
| Dimension | Okta, per its documentation | What a buyer should verify |
|---|---|---|
| Identity | Agent SSO models "agentic connections as workload principals in Universal Directory" | Whether every agent has an entry, an owner and a status |
| Reach | Cross App Access "centralizes authorization in the identity provider" | Which applications and MCP servers an administrator approved |
| The screen | No page or field described | The first screen that carries a real value, field by field |
| Record | Token creation, role and expiry | What the model saw, and who approved the change |
Each row is a control, and the last two mark where the review of this record ends.
Who approves a change the agent makes to a customer record?
Cross App Access answers a consent question: an administrator approves the connection once, and every agent that uses it inherits that decision (Okta, Cross App Access, 2026). It is not an approval of the change. The token the agent holds decides what it may call. Nothing in Okta's pages puts a person's name on the address change or the payment. That approval is given at the action by a named person and recorded beside the action.
The absence is easy to miss. Automation bias, "the tendency to over-rely on automation", is well documented, and a status that reads active invites the reading that the run is supervised (Goddard et al., 2012).
Multi-tool agents widen the gap. Li and colleagues report that, across 66 real tools, "75% are vulnerable to XTHP attacks" (Li et al., 2026). An approval attached to the connection cannot see a hijacked control flow, so it has to sit at the action the agent prepares (How Do I Design an Agent Workflow That Assumes the Agent Gets Hijacked?). OWASP's excessive agency entry names the same risk and the same mitigation, human approval for sensitive actions (How Do You Secure AI Agents in Production?).
What record does Okta leave of the customer data an agent read?
The identity layer keeps a record of the session. Okta Help documents token creation, the role that minted the token and its 30-day life, and says the value is visible "during the creation process" and not after (Okta Help, 2026). Auth0 marks an impersonated session, and its documentation says "the profile of the impersonated user will contain additional impersonated and impersonator properties", so a reviewer can tell a real login from one (Auth0, 2026). Both answer who acted and with what authority.
Neither answers what the model read. The page an application renders leaves no entry in an identity log, because the assertion is spent before the application answers. A record of the reading has to be written where the page is drawn, which the Auth0 comparison sets out (RedactSure vs Auth0: 2026 Comparison & Alternative).
HashiCorp's agent tutorial shows the same limit from the credential side: "Token lifetime is reduced from days or weeks to minutes", and the wrapper it describes "exports it as VAULT_TOKEN, and launches the agent", so a credential with a short life still lands in the agent's environment (HashiCorp, 2026). The record shows the issuance; the value sits where the agent runs, outside the identity record.
What does a governed environment change?
A governed environment is a control class that changes three things.
First, the screen. Values chosen by policy are replaced with consistent tokens before any model reads the page, so a record that would show a date of birth and a tax identification number shows DOB_001 and TIN_001 for the whole run. The tokens stay stable across screens, so the work no longer depends on the real value being in the context.
Second, the destination. Real values resolve only at approved destinations, at the moment of an approved action, so the value reaches the form a person approved and not the transcript or a tool call.
Third, the approval and the record. A named person approves each payment, submission and record change, and every screen as tokens, every action and every approval lands in an exported record. An attacker who succeeds against a tokenized screen collects tokens.
None of this replaces an identity provider. Okta still decides which agent authenticates and which applications it may reach, and a governed environment decides what those applications show the model. That division is the answer for this record, and the comparison for this vendor sets it out row by row (RedactSure vs Okta: 2026 Comparison & Alternative).
What the record shows
No, not for the record the application renders, because the rendered page decides the exposure: what the screen draws is what the model receives, and no identity provider sits between the two. Okta covers the other half, deciding which agent authenticates, which applications it may reach and what its token may call. It does not describe the page the application draws once the assertion is accepted, so the record here stops at the door. A useful test starts with one agent and one record: compare what the model received on the first screen that carried a real value with the sign-in and token record left for the same run. If the only record is an authentication event, the screen path is ungoverned.
Methodology and limitations
This page rests on Okta's product and help documentation, an Okta Security advisory, an Auth0 documentation page, a HashiCorp tutorial, FINRA guidance and three research publications. Vendor pages were read between October 21, 2026 and October 22, 2026, and each Sources line carries its date. Public documentation read in full gives a sound view of where each product applies its control.
No product on this page was tested for it. The phrase "not described in the pages reviewed" means the pages listed here, not a finding that a vendor cannot do something. Vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a customer record after single sign-on, not an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot on the organization's screens.
Two source limits matter: the Okta Security advisory is dated 2023 and covers Okta's own service desk, and the Auth0 impersonation page sits under a legacy path.
Frequently asked questions
Is Okta enough to secure AI agents on customer data?
No. Okta decides which agent authenticates, which applications it may reach and what its token may call, all before a page exists. The customer record an application renders is drawn from the application's own store, and the model receives every field the page shows. The pages reviewed describe the assertion and the token, not the screen, so the record is governed at admission and exposed when the page renders.
What does the model read after Okta signs the agent in?
The rendered page. Once the assertion is accepted, the application answers with its own record, and the model receives the name, the date of birth, the tax identification number and whatever else the screen draws. The sign-in assertion is not in that text. Nothing in the pages reviewed replaces a value before the model reads it, so the exposure is set by the first screen that shows a real value.
Who approves a change the agent makes to a customer record?
No one, unless the workflow adds an approval. Cross App Access records an administrator's consent to the connection once, for the organization, and that decision covers reach rather than the change. The application enforces its own permissions, and the token decides what the agent may call. A person approving the address change or the payment is a separate control, and it has to be recorded with the action rather than with the connection.
What record does Okta leave of an agent's work?
The authentication and token record. Okta Help documents token creation, the role that minted the token and its expiry, and Auth0 marks an impersonated session so a reviewer can tell it apart. Those entries answer who acted and with what authority. They do not show the fields the application rendered or what reached the model's context. Evidence of the reading has to be produced at the page, because the assertion is spent before the application answers.
Does Cross App Access keep an agent from reading the whole record?
No. The protocol centralizes authorization in the identity provider and changes who consents, so an administrator can approve a connection once and name the applications it covers. It does not change what an application draws for the role that opens the record. The model still receives every field the page shows, and a scope that permits the read does not narrow the field list.
What should a security team ask for in writing?
Three commitments: which agent holds which credential and for how long, what the model receives from the first rendered screen that carries a real value, and who approves each consequential change by name. Ask for the answers beside one run: the screen the model read and the record of the approval. A directory entry and a scope list can both be accurate while the page still shows the whole record.
How RedactSure Keeps a Customer Record Out of the Model's View
The customer record an application renders is what the model reads, and the identity layer never touches it. Okta's help page limits viewing an API token to its creation, a bound on the credential, not the record (Okta Help, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent opens the customer record and the model reads the date of birth, the tax identification number and the balance. Inside, the page draws DOB_001, TIN_001 and ACCT_001, and the real values resolve only at the destination a named person approved, with the approval 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
What the model holds on a customer record decides what a hijacked page can carry out of it. Bring one customer-record task and see, with test values, what the page shows the model and where the real value lands. Book a demo