Okta for AI Agents: Access Patterns

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. I 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 I want to 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², NIS2³, DORA⁴ 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.

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

#

Below is a brief overview of each pattern — what it does, when to use it, and the headline trade-off. For the full implementation guide (protocol flows, sequence diagrams, token claims, audit log examples, and Okta configuration walkthroughs) see the companion article: Access Patterns Deep Dive.

Cross App Access (XAA)

#

Cross App Access (XAA) is the flagship access pattern. It implements user-delegated, user-context-aware access through the Identity Assertion JWT Authorization Grant (ID-JAG)⁷, an emerging IETF standard. Every token carries both sub (the user) and act.sub (the agent) — enabling per-user audit attribution, surgical revocation, dynamic scope narrowing, and direct alignment with NIST SP 800-63-4¹, the EU AI Act², NIS2³, and DORA⁴.

• When to use it: internal APIs, MCP servers, and SaaS that has shipped ID-JAG support.
• Key benefit: full identity context at every hop. Effective permissions = intersection of agent rights, user entitlements, and per-request scopes.
• Limitation: ISV adoption for third-party SaaS is in progress.

👉 Deep dive: ID-JAG flow, token claims, audit logs, and configuration

Secure Token Service (STS)

#

Secure Token Service (STS) is the bridge for third-party SaaS that supports OAuth but hasn’t yet adopted ID-JAG. Okta acts as a secure broker: user-consented tokens are vaulted in Okta Privileged Access (OPA), and at runtime the agent gets a short-lived federated token. User context is preserved through the consent flow, so audit logs still capture who authorized the action.

• When to use it: third-party SaaS with standard OAuth (e.g. GitHub, Google Workspace, Atlassian) — until the vendor ships ID-JAG.
• Key benefit: user context without requiring ISV-side ID-JAG support; one-time consent enables fully autonomous Phase-2 operation.
• Limitation: scopes are fixed at consent time (no per-request narrowing); revocation is per-connection, not per-user.

👉 Deep dive: token vaulting flow, RFC 8693 exchange, comparison with XAA

Pre-Shared Key (PSK) or Vaulted Secret

#

Pre-Shared Key (PSK) stores static credentials (API keys, bearer tokens, webhook secrets) in Okta Privileged Access. The agent retrieves the secret at runtime instead of embedding it in code or configuration — and Okta can rotate it automatically when the downstream service supports it.

• When to use it: legacy REST APIs, webhook endpoints, or any service that authenticates only with API keys or bearer tokens.
• Key benefit: removes secrets from code; per-secret isolation gives at least agent-level attribution and surgical revocation.
• Limitation: no user context, no scope narrowing — audit logs see only the agent identity.

👉 Deep dive: secret retrieval flow, configuration, and migration path

Service Account

#

Service Account uses username/password credentials linked to a shared service identity. This is the legacy pattern Okta explicitly recommends migrating away from. Multiple agents typically share the same login, which breaks per-agent attribution and forces all-or-nothing revocation.

• When to use it: only when unavoidable — legacy systems (mainframes, on-prem databases, LDAP-backed services) that support nothing else, with a documented sunset plan.
• Key benefit: works with any system that accepts username/password.
• Limitation: no user context, no scope narrowing, shared identity, manual rotation. Every Service Account is a compliance gap.

👉 Deep dive: shared-identity flow, PSK comparison, and exit strategy

Strategic Recommendations

#

With the four patterns understood individually, the next step is to weigh them against each other and chart a migration path — the matrix, decision tree, and roadmap below pull it all together.

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 --> STS["🔄 Use STS
User-consented token brokering"]
    B -- No --> C["Does resource support API keys?"]
    C -- Yes --> PSK["⚠️ Use PSK
Vaulted secret"]
    C -- No --> SA["🚫 Service Account
Only option - plan migration immediately"]

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

Implementation Sequencing

#

Here’s a recommended roadmap for transitioning to XAA while maintaining security and compliance:

• 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 only when XAA isn’t supported
  • Use Service Account, or Pre-Shared Key only when absolutely necessary
  • Document rationale for non-XAA choices
• Phase 3: Monitor ISV roadmaps
  • As ISVs adopt ID-JAG, migrate STS connections to XAA
  • Track adoption announcements
• Phase 4: Service Account and Pre-Shared Key sunset
  • Establish formal deprecation timeline
  • Migrate to STS as intermediate step
  • Target zero service accounts for user-context workloads

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.

XAA will also be the foundation for future capabilities like Agent-to-Agent Access (A2A), Kill Switch (global token revocation), Human-in-the-Loop (HITL) workflows. Starting with XAA means you’re not just securing today’s integrations, but also future-proofing for tomorrow’s innovations.

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

#

• Access Patterns Deep Dive: Companion article with full protocol details, sequence diagrams, audit log examples, and Okta configuration
• 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
• AI Agent Token Exchange Guide: Step-by-step developer guide for agent token exchange flows
• Agentic Enterprise Blueprint: Strategic governance framework
• Interactive Demo: Securing the Autonomous Enterprise: Demo

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.