Okta
Octa
I created a testing environment for Okta for AI Agents (O4AA)! – Testing the security of AI agents by actually running them –
Introduction
The use of AI agents in business is shifting from the stage of "asking chatbots questions" to the stage of "delegating tasks to agents." Along with this, a challenge is emerging: the security of AI agents—particularly, who has the authority to access what data. Okta offers Okta for AI Agents (O4AA) to address this challenge.
However, O4AA is a feature that presents a high hurdle for testing, even if you're interested in trying it out. Therefore, we've created a demo console that combines an agent with a target application. This article will show you how to build and test it.
1. What is Okta for AI Agents (O4AA)?
Traditionally, granting AI agents permissions often involved simply handing over the user's account or API key. While convenient, this method has the following drawbacks:
- Excessive authority – the agent gains access to all the permissions of the borrowed account.
- Logs make it impossible to distinguish – only the borrowed account name is recorded in the audit log, making it impossible to track whether it was a human action or an agent action.
- It cannot be stopped on an agent-by-agent basis – because it is not registered as an ID, there is no unit to stop it.
In O4AA, agents register themselves with Okta and then define their access destinations as Resource Connections. At runtime, the agent receives a token from Okta and can only access resources within that scope.
2. I tried creating a test environment using the demo console.
The best way to understand how O4AA works is to actually run the agent. However, the preparation required for this testing can be surprisingly time-consuming. There are two main things you'll need.
- An AI agent application registered with Okta and implementing token exchange.
- The application on the resource side that the agent accesses
In other words, simply "creating an agent" is not enough; you also need to prepare the "accessed side" to compare cases where access is permitted and cases where it is denied. In fact, we have received feedback from our partners that preparing the testing environment is difficult.
Therefore, we have created a demo console that combines these two elements.
Demo Console Configuration
The demo console you create includes a demo AI agent and an XAA-compatible demo application. You will need to provide your own Okta tenant and Slack separately.
Figure 1: Demo console configuration
* In the diagram, XAA/STS represent two connection methods used by AI agents to access resources. The choice between them depends on the nature of the resource being accessed. The differences will be explained in detail in Chapter 4.
* In the management screen and demo console, the XAA-compatible demo application is registered under the name "ACME". All instances of "ACME" in the following screenshots refer to the XAA-compatible demo application.
set up
The setup screen consists of five steps. Following them in order will complete everything from registering the app with Okta to performing a connection test.
First, you'll need to create an OIDC web application to sign users into Okta. The ID token obtained here will serve as the starting point for verifying the user's identity when agents access resources later on. Clicking "Semi-automatic setup" will create a web application on the Okta side, and the Client ID and other information will be automatically entered.
Figure 2: Step 1 - Setting up the OIDC Web application
Next, the AI agent registers a key to authenticate itself with Okta. Using a client assertion signed with this key, the agent obtains a token on behalf of the user. The private key is stored only on the agent's side and is not shared with Okta.
Figure 3: Step 2 - Registering the AI Agent's authentication key
Next, we connect the two resources that will be accessed. One is Slack, which will be connected to using the OAuth STS Resource Server Connector as a resource that does not support XAA.
Figure 4: Step 3 – Connecting to Slack (Non-XAA)
Another example is the XAA-compatible demo application. This one uses a "semi-automatic configuration" that creates a custom authorization server, scopes, access policies, and resource connections all at once. The key feature of this configuration is that Okta can control the scopes included in the access token.
Figure 5: Step 4 - Connecting the XAA-enabled demo application
Check the settings on the Okta side.
Once setup is complete, the AI agent will be registered as a single ID in the Okta management console, and two resource connections (authorization server and application) will appear side-by-side. You will see that each has its own set of permitted scopes.
Figure 6: AI agents and resource connections registered in Okta
3. Try it out – when it's allowed, when it's denied
Once the setup is complete, let's actually send a request to the agent. First, enter "Show me the list of inquiries" into the XAA-enabled demo app. The agent will obtain a token from Okta, access it within the permitted scope, and return the results.
Figure 7: Permitted Cases (200 OK)
Now, let's change the scope settings on the Okta side. We'll remove the allowed `tickets:read` and leave only `tickets:reply`.
Figure 8: Remove tickets:read from scope
If the same request is made in this state, the agent will not be able to reach the resource. It will stop at the point of exchanging the ID token for ID-JAG and return an error.
Figure 9: Cases where rejection occurs
In the case of Slack (non-XAA)
Next, let's try requesting "show me the channel list" from Slack, a resource that does not support XAA. The behavior changes here, and it first asks for the user's consent.
Figure 10: Waiting for consent
When you open the consent page, a permission screen from Slack will appear. If the user grants permission here, the agent will be able to receive a token for Slack.
Figure 11: Slack consent screen
After agreeing, I made the same request again, and this time I was able to retrieve the channel list.
Figure 12: After consent, channel list successfully retrieved.
You'll notice that even though both involve "an agent accessing a resource," XAA and Slack (connected via STS) behave differently. We'll elaborate on these differences in the final chapter.
View the back side on the tracing screen
The trace screen allows you to see step-by-step which tokens were exchanged and where. The process from the exchange of the ID token to the ID-JAG, from the ID-JAG to the access token, and finally to the calling of the resource's API is visualized.
Figure 13: Trace screen (breakdown of Okta control)
4. Supplementary Information: Differences between XAA and STS connection methods
As supplementary information, I will now touch upon the details that were organized during the development process. O4AA provides multiple resource types depending on the nature of the resource being connected to.
| Resource type | Overview |
| Authorization server | Access to resources protected by Okta's custom authorization server. Supports XAA (Cross App Access) and uses ID-IAG. |
| Resource server | Okta acts as an intermediary, utilizing access tokens issued by third-party authorization servers. Supports the Brokered Consent (STS) flow. |
| Secret | Use static credentials stored in Okta Privileged Access. |
| Service account | A service account for an application defined in Universal Directory. Stored in Okta Privileged Access. |
Of these, XAA and STS come into play when an AI agent is allowed to access an application.
XAA（Cross App Access）
XAA is a method that assumes both the accessing and accessed parties trust the same IdP (Okta). Okta acts as an intermediary between the two parties, deciding whether to allow the connection based on its policy. The token exchange proceeds as follows:
Figure 14: XAA (ID-JAG) Token Exchange Flow
The key point is that this entire process does not involve a user consent screen. The decision is finalized by the IdP's policy. This characteristic is particularly useful for autonomous AI agents, as they often cannot wait for human approval during processing.
Please note that the issued ID-JAG is a short-lived token with a validity period of approximately 5 minutes. The final access token you receive is a standard Okta access token and can be revoked.
STS（brokered consent）
On the other hand, STS is a method used when the resource does not support XAA. Slack in this demo falls into this category. In this case, the access token is issued not by Okta but by a third-party authorization server, with Okta acting as an intermediary for its acquisition and transfer.
The biggest difference from XAA is that it requires user consent. Before the agent can act on behalf of the user, there is a step to obtain the user's consent. The consent screen shown in Figures 10 and 11 is a result of this mechanism.
Clarifying the differences in usage
| XAA | STS | |
| Resource type | Authorization server | Resource server（Application / MCP Server） |
| premise | The resource side also trusts Okta and is protected by a custom authorization server. | The resource side uses a third-party authorization server. |
| Token issuer | Okta (ID-IAG → Access Token) | Third party (Okta acts as an intermediary) |
| User consent | Not required (determined by IdP policy) | requirement |
| Main use | Our proprietary app that supports XAA | Existing SaaS such as Slack (OIDC compliant) |
To summarize, the dividing line is whether the accessed destination is inside or outside the Okta ecosystem. If it's inside, policy-driven control can be achieved with XAA; if it's outside, Okta acts as an intermediary with STS, requiring user consent.
Summary
This article describes how we built an O4AA testing environment using the demo console and demonstrated its operation. We registered an agent as a single ID and defined its access scope through resource connections. Changing the scope then instantly altered the agent's behavior. I felt that this aspect is easier to understand by actually observing it on the screen rather than just reading about it.
O4AA is an area where new features are still being added, and the scope of support and setup procedures are constantly changing. Please note that the information in this article is current as of the time of writing.
For those who want to "get a feel for it by trying it out first," we have a demo console available. If you would like to receive a demo, or if you are interested in O4AA testing or AI agent security, please contact us.
Reference (Okta official documentation)
Inquiry/Document request
In charge of Macnica Okta Co., Ltd.
- TEL：045-476-2010
- E-mail：okta@macnica.co.jp
Weekdays: 9:00-17:00
