Okta for AI Agents: Supported Access Patterns

From Governance to Mechanics: Choosing the Right Access Pattern

#

In my previous article on the Agentic Enterprise Blueprint, I explored how Okta positions AI agents as first-class identities within the enterprise security fabric. We examined the strategic framework answering three foundational questions: Where are my agents? What can they connect to? What can they do?

But strategy without execution is just theory. Now we must answer a more practical question: How should AI agents authenticate and authorize their communications with enterprise resources?

This guide is designed to help architects, security teams, and solution engineers evaluate the four access patterns Okta for AI Agents provides for AI agent integrations. By the end, you’ll understand:

• Which pattern fits your security requirements (user context, scope narrowing, audit trails)
• Which pattern your resources support (ID-JAG, OAuth, API keys, or username/password)
• How to compare security levels between patterns
• When to migrate from legacy patterns to modern approaches

This question isn’t academic. The access pattern you choose determines:

• Whether your audit logs capture user attribution: Can you trace an action back to both the agent and the user it acted for?
• Whether you can revoke access surgically: Can you disable a single user’s access to one agent without affecting others?
• Whether your architecture complies with regulatory requirements: Does your implementation satisfy NIST SP 800-63-4, the EU AI Act, and NIS2 traceability mandates?

Consider this scenario: Your security team is investigating a data access incident. An AI agent accessed sensitive customer records at 3:47 AM. With the wrong access pattern, your audit logs might show only service-account-agent accessed database. With the right pattern, you see sales-representative agent, acting on behalf of john@example.com, accessed customer record #12847 with read scope, transaction ID jti-7z9x2q8. The difference is architectural, not coincidental.

Okta for AI Agents (O4AA) provides four distinct access patterns, each optimized for different security models, resource capabilities, and compliance requirements¹. The choice isn’t arbitrary: it’s a fundamental architectural decision that shapes your agent security posture.

Let’s examine each pattern, understand when to use it, and see how they fit into a coherent access strategy.

Access Patterns at a Glance

#

The Okta for AI Agents (O4AA) platform offers four ways for an agent to reach a downstream resource. Each one is configured as a Managed Connection attached to the agent’s workload principal in Okta. Picking the right pattern comes down to three factors:

1. What does the downstream resource support? (XAA, ID-JAG, OAuth, API key, username/password)
2. Is user-level context required? (Audit attribution, per-user scope narrowing)
3. What are your security and governance requirements? (Compliance profile, revocation granularity)

The Four Patterns

#

Pattern Comparison Matrix

#

Decision Framework

#

The framework prioritizes patterns by security posture: XAA provides the strongest guarantees, while Service Account represents the weakest (and should be treated as temporary).

---
config:
  layout: dagre
---
flowchart TB
    A["Does resource support ID-JAG?"] -- Yes --> XAA["✅ Use XAA
User-delegated, full audit,
surgical revocation"]
    A -- No --> B["Does resource support OAuth 2.0?"]
    B -- Yes --> C["Is user context essential?"]
    B -- No --> SA2["🚫 Service Account
Only option - plan migration immediately"]
    C -- Yes --> STS["🔄 Use STS
User-consented token brokering"]
    C -- No --> D["Does resource support API keys?"]
    D -- Yes --> PSK["⚠️ Use PSK
Vaulted secret"]
    D -- No --> SA1["🚫 Service Account
Last resort - plan migration"]

    A@{ shape: hex}
    B@{ shape: hex}
    C@{ shape: hex}
    D@{ shape: hex}
    style XAA fill:#d4edda,stroke:#28a745
    style SA2 fill:#f8d7da,stroke:#dc3545
    style STS fill:#cce5ff,stroke:#0d6efd
    style PSK fill:#fff3cd,stroke:#ffc107
    style SA1 fill:#f8d7da,stroke:#dc3545

Cross App Access (XAA)

#

Cross App Access (XAA) is the flagship access pattern for Okta for AI Agents. It implements user-delegated, user-context-aware access through the Identity Assertion JWT Authorization Grant (ID-JAG), an emerging IETF standard for secure delegation³.

For detailed configuration steps, see the Cross App Access documentation.

Why XAA Matters

#

XAA is the first access pattern to embed full identity context at every hop in an agent workflow. Every token carries both:

• sub: The user identity (who authorized this action)
• act.sub: The agent identity (which agent is acting on their behalf)

This dual-identity structure enables capabilities impossible with traditional service accounts:

• Per-user audit attribution: Every agent action is traceable to the specific user who authorized it
• Surgical revocation: Disable one user’s access to one agent without affecting other users or agents
• Scope narrowing: The token’s effective permissions are the narrowest overlap of what the agent is allowed, what the user is entitled to, and what the specific task requires
• Regulatory compliance: Complete audit trails satisfying NIST SP 800-63-4, EU AI Act, and NIS2 traceability requirements

How XAA Works: The ID-JAG Flow

#

The XAA flow involves a token exchange sequence where Okta vouches for the user’s identity to the target resource’s authorization server.

sequenceDiagram
    autonumber
    actor User
    participant Agent as AI Agent
    participant OktaAS as Okta Org AS
    participant CustomAS as Custom AS
    participant Resource as Protected Resource

    User->>Agent: Initiates action
    Agent->>OktaAS: Request ID Token (OIDC)
    OktaAS-->>Agent: ID Token (sub: user@acme.com)
    Agent->>OktaAS: Token Exchange Request (ID-JAG)
    OktaAS-->>Agent: ID-JAG Assertion
    Agent->>CustomAS: Present ID-JAG + requested scopes
    CustomAS->>CustomAS: Validate ID-JAG signature (JWKS)
    CustomAS->>CustomAS: Evaluate RBAC policy
    CustomAS-->>Agent: Scoped Access Token (sub + act.sub)
    Agent->>Resource: API call with Access Token
    Resource->>Resource: Validate token claims
    Resource-->>Agent: Response data

Step-by-step breakdown:

1. User initiates action: User interacts with the AI agent (e.g., “Show me my open opportunities”)
2. Agent obtains ID Token: Agent authenticates to Okta Org Authorization Server via OIDC
3. Token exchange (ID-JAG): Agent exchanges the ID Token for an Identity Assertion JWT
4. Present to resource AS: Agent presents the ID-JAG to the target resource’s Custom Authorization Server
5. Policy evaluation: Custom AS validates the ID-JAG signature via Okta’s JWKS endpoint and enforces RBAC policies, checking the user’s group memberships and configured scope entitlements
6. Scoped token issued: Custom AS issues an access token containing both sub (user) and act.sub (agent) with narrowed scopes
7. Resource access: Agent calls the protected resource with the scoped token (expires in minutes)

The ID-JAG Standard

#

ID-JAG (Identity Assertion JWT Authorization Grant) is based on several IETF standards:

• RFC 8693: OAuth 2.0 Token Exchange
• RFC 7523: JWT Profile for OAuth 2.0 Client Authentication
• IETF draft-02: Identity JWT Authorization Grant specification

For a comprehensive overview of Cross App Access and how it fits into the OAuth ecosystem, see the OAuth.net Cross App Access reference.

The key innovation is the act claim, which captures the actor (agent) identity separately from the subject (user) identity. This enables a clean separation of “who is this action for” versus “what system is performing the action.”

Token Structure

#

A typical XAA access token contains:

{
  "sub": "john@example.com",
  "act": {
    "sub": "sales-representative",
    "aud": "okta.com"
  },
  "aud": "crm-orders-api",
  "scope": "orders:read accounts:read",
  "jti": "s2r3d4x3m6a0q1l",
  "iat": 1735571312,
  "nbf": 1735571312,
  "exp": 1735571468
}

XAA Use Cases

#

Use Case 1: Internal API via MCP Server

A customer support agent needs to access the internal order database to answer customer queries.

• Agent registered in Okta Universal Directory
• MCP Server protected by Okta Custom Authorization Server
• XAA flow: Agent exchanges user’s ID Token for scoped access to orders:read
• Audit: Every query logged with user ID, agent ID, and transaction ID

Use Case 2: First-Party SaaS (ISV-Enabled)

A sales assistant agent accessing Salesforce opportunities on behalf of a sales rep.

• Salesforce implements ID-JAG validation
• Agent presents ID-JAG to Salesforce authorization endpoint
• Salesforce issues scoped token for the user’s data only
• No static credentials; no shared service accounts

Use Case 3: Multi-Step Agent Workflows

A finance agent executes an approval workflow:

1. Step 1: Read expense report (read:expenses scope)
2. Step 2: Check budget availability (read:budgets scope)
3. Step 3: Submit approval (write:approvals scope)

Each step can request different scopes. If the agent is compromised mid-workflow, revocation stops only that user’s session without affecting others.

Configuration Overview

#

Implementing XAA requires:

1. Register the agent in Okta Universal Directory as a workload principal
2. Create a Managed Connection and select “Authorization Server” (for custom APIs) or “MCP Server” (for MCP endpoints). Both use the same ID-JAG exchange under the hood.
3. Configure the Custom Authorization Server protecting your resource
4. Define RBAC policies that evaluate both user and agent attributes

Example policy logic:

IF (act.sub == "sales-representative")
AND (sub IN groups["sales-team"])
AND (requested_scope IN ["sales:read", "accounts:read"])
THEN issue_token_with_scope
ELSE deny

The policy ensures the agent can only access sales data when the user is a member of the sales team.

Testing XAA: The xaa.dev Playground

#

Okta provides an interactive testing environment at xaa.dev where you can experiment with XAA flows without infrastructure setup⁴.

Features:

• Browser-based testing (no Docker or local configuration)
• Pre-configured components: Requesting App, Resource App, IdP
• Get started in under 60 seconds
• Register your own custom clients for testing

The playground includes a sample flow where “Bob Tables” creates and manages tasks through an AI agent, demonstrating the full ID-JAG exchange.

XAA Limitations

#

• ISV adoption in progress: XAA is GA on the Okta side, but third-party SaaS integrations require ISV support. Major vendors are actively implementing ID-JAG, building on XAA today ensures you’re ready when they ship.

• Token lifetime vs. long-running sessions: Tokens expire in minutes, requiring new exchanges for each request. This is by design (limits blast radius) but may impact agents that cache credentials.

• Not suitable for: Agents that must operate offline or cache credentials indefinitely. For these scenarios, consider STS with careful credential lifecycle management.

Secure Token Service (STS)

#

Secure Token Service (STS) enables agents to access third-party SaaS applications that support OAuth but haven’t yet adopted XAA. Okta acts as a secure broker, vaulting user-consented tokens and providing short-lived federated access at runtime.

In the Okta admin console, you configure STS by creating a managed connection with the “Application” resource type, selecting an OIN app integration or a custom resource server. Okta then brokers the OAuth token exchange between the agent and the third-party service.

When to Use STS

#

• Third-party SaaS with OAuth support (GitHub, Google Workspace, Slack, Jira)
• User-level context is required for audit and compliance
• ISV hasn’t implemented ID-JAG validation yet

How STS Works

#

sequenceDiagram
    autonumber
    actor User
    participant Okta as Okta (Token Broker)
    participant ThirdParty as Third-Party SaaS
    participant Agent as AI Agent

    rect rgb(240, 248, 255)
        Note over User,ThirdParty: One-Time Consent Flow
        User->>Okta: Authenticate
        Okta->>ThirdParty: OAuth Authorization Request
        ThirdParty-->>User: Consent Screen
        User-->>ThirdParty: Approve access
        ThirdParty-->>Okta: Authorization Code
        Okta->>ThirdParty: Exchange for tokens
        ThirdParty-->>Okta: Access + Refresh Tokens
        Okta->>Okta: Vault tokens (Privileged Access)
    end

    rect rgb(255, 248, 240)
        Note over Agent,ThirdParty: Runtime Agent Access
        Agent->>Okta: Request access (workload identity)
        Okta->>Okta: Validate managed connection policy
        Okta-->>Agent: Short-lived federated token
        Agent->>ThirdParty: API call with token
        ThirdParty-->>Agent: Response
    end

STS Token Flow

#

1. One-time consent: User authenticates and consents to the third-party service
2. Token vaulting: Okta secures the access and refresh tokens in Okta Privileged Access
3. Runtime access: Agent authenticates to Okta with its workload principal
4. Token exchange: Okta issues a short-lived federated token for the downstream service
5. API access: Agent calls the third-party API with the short-lived token, crucially, user credentials never touch the agent

Key difference from XAA

#

• Consent flow: STS requires the user to go through the third-party’s OAuth consent screen; Okta then stores and manages those tokens on behalf of the agent. XAA skips the consent screen entirely. Delegation happens at agent registration time in Okta.
• Audit trail: STS captures user consent and agent access in Okta logs, but the third-party service may only see the agent identity. XAA provides full user+agent context to the resource.
• Token lifetime: The federated token issued to the agent is short-lived (minutes) to limit risk, but the underlying access/refresh tokens in Okta may have longer lifetimes depending on the third-party service’s policies.
• Revocation: Revoking access requires deleting the vault entry in Okta, which may affect all agents using that connection. No per-user revocation within the third-party service.
• Scope narrowing: The agent receives whatever scopes the user consented to during the OAuth flow. Okta can’t dynamically narrow scopes per request like XAA.

STS Use Cases Examples

#

• GitHub: Agent reads repositories and creates pull requests on behalf of developers
• Google Workspace: Agent manages calendar events and sends emails for users
• Slack: Agent posts notifications and manages channels
• Jira/Confluence: Agent creates tickets and updates documentation

Strategic Direction

#

STS is explicitly a transitional bridge pattern. Once a ISV or SaaS vendor ships ID-JAG support, you can upgrade that connection from STS to XAA without re-architecting. Until then, STS gives you user-level context that Pre-Shared Key and Service Account simply can’t provide.

Pre-Shared Key (PSK) or Vaulted Secret

#

Pre-Shared Key (PSK) stores static credentials (API keys, bearer tokens, webhook secrets) in Okta Privileged Access (OPA). The agent retrieves secrets at runtime rather than embedding them in code or configuration.

When to Use Pre-Shared Key

#

• Legacy REST APIs that only support API key authentication
• Webhook endpoints requiring bearer tokens
• Third-party integrations with static token auth
• Early-phase services that will eventually add OAuth

How Pre-Shared Key Works

#

sequenceDiagram
    autonumber
    participant Admin as Admin
    participant Okta as Okta (Privileged Access)
    participant Agent as AI Agent
    participant Resource as Protected Resource

    rect rgb(240, 255, 240)
        Note over Admin,Okta: Configuration Phase
        Admin->>Okta: Create & vault secret (API key)
        Admin->>Okta: Create managed connection on agent
    end

    rect rgb(255, 248, 240)
        Note over Agent,Resource: Runtime Access
        Agent->>Okta: Authenticate (workload principal)
        Okta->>Okta: Validate managed connection policy
        Okta-->>Agent: Release secret
        Agent->>Resource: API call with secret
        Resource-->>Agent: Response
    end

Pre-Shared Key Limitations

#

Configuration

#

1. Create the secret in Okta Privileged Access
2. Create a managed connection on the agent (type: Secret)
3. Specify a Resource Indicator (identifier the agent uses to request the secret)
4. Agent authenticates and requests the secret by resource indicator

Service Account

#

Service Account uses username and password credentials linked to a shared service identity. This is the legacy pattern that Okta explicitly recommends migrating away from.

How Service Account Works

#

sequenceDiagram
    autonumber
    participant Admin as Admin
    participant Okta as Okta (Privileged Access)
    participant AgentA as Agent A
    participant AgentB as Agent B
    participant Resource as Protected Resource

    Admin->>Okta: Create service account (svc_agent@acme)
    Admin->>AgentA: Register with managed connection
    Admin->>AgentB: Register with managed connection

    AgentA->>Okta: Request credentials
    AgentB->>Okta: Request credentials
    Okta-->>AgentA: Username/Password
    Okta-->>AgentB: Username/Password

    AgentA->>Resource: Authenticate as svc_agent@acme
    AgentB->>Resource: Authenticate as svc_agent@acme

    Note over Resource: Both appear as same identity!

The Problem with Service Accounts

#

Service Accounts presents four critical security gaps:

1. Invisible agents: Multiple agents share a single identity, making it impossible to tell which one performed an action
2. Excessive permissions: Service accounts typically carry broad, static privileges that far exceed what any single task requires
3. Missing user attribution: Compliance audits can’t answer “which user triggered this data access?”
4. All-or-nothing revocation: Deactivating the service account kills access for every agent and system that depends on it

When Service Account is Unavoidable

#

• Legacy systems requiring username/password authentication (on-prem databases, mainframes, LDAP-backed services)
• Batch processing with no end-user context
• Systems that have not adopted any modern authentication method

Migration Path

#

1. Audit: Identify all service accounts currently in use
2. Evaluate: Can the resource support OAuth? → Migrate to XAA/STS
3. Fallback: Can we use API keys? → Migrate to Pre-Shared Key
4. Interim: Service Account acceptable only for batch processes with no user context, with a documented sunset plan

Service Account vs Pre-Shared Key

#

Both patterns lack user context and lack scope narrowing, but they differ in the type of credential stored and the security posture:

Strategic Recommendations

#

Pattern Selection by Compliance Profile

#

Implementation Sequencing

#

Phase 1: Audit existing integrations

• Map all agent connections to one of the four patterns
• Identify service accounts and pre-shared keys

Phase 2: New integrations default to XAA

• Use STS or Pre-Shared Key only when XAA isn’t supported
• Document rationale for non-XAA choices

Phase 3: Monitor ISV roadmaps

• As ISVs adopt ID-JAG, migrate STS connections to XAA
• Track adoption announcements (Salesforce, GitHub, etc.)

Phase 4: Service Account sunset

• Establish formal deprecation timeline
• Migrate to Pre-Shared Key or STS as intermediate step
• Target zero service accounts for user-context workloads

From Theory to Practice: Configuring Access Patterns in Okta

#

In Okta’s Universal Directory, you can register AI agents as workload identities and create Managed Connections that define how they access downstream resources. Each connection type corresponds to one of the access patterns we’ve discussed.

AI Agents List	AI Agent Detail

When you create a managed connection, you’ll see five resource types. They map to the four access patterns covered in this article:

Conclusions

#

The choice of access pattern isn’t a technical detail: it’s an architectural decision that shapes your AI agent security posture for years to come.

Key takeaways:

1. XAA is the future: User-delegated, auditable, compliant. Investing in XAA now means your architecture is ready for MCP Server and Agent-to-Agent support the moment they land.

2. STS bridges the gap: For third-party SaaS that supports OAuth but not ID-JAG, STS provides user context while you wait for ISV adoption.

3. Pre-Shared Key is acceptable for legacy: API-key-only services need vaulted secrets, but plan migration as resources modernize.

4. Service Account is technical debt: Every service account is a compliance gap waiting to surface in an audit. Start planning your exit.

The journey from Service Account → Pre-Shared Key → STS → XAA represents a security maturity progression. Each step up the ladder adds user context, scope narrowing, and audit granularity.

Getting Started

#

Test XAA Today

#

Explore the interactive XAA playground at xaa.dev, no setup required. Experience the full ID-JAG flow in your browser.

Learn More

#

• Okta for AI Agents: Platform overview
• Cross App Access Solution: XAA solution page
• Cross App Access Documentation: Official configuration guide
• XAA.dev Documentation: Interactive playground docs
• Cross App Access Introduction: Technical deep dive
• XAA Developer Playground: Hands-on tutorial
• Building Resource Apps: Implementation guide
• Agentic Enterprise Blueprint: Strategic governance framework

Join the Conversation

#

Which integrations in your environment are still using service accounts? Have you started mapping your agent connections to these access patterns? Where are you in that journey?

Share your experience in the comments below or connect with me on LinkedIn to continue the discussion.