Okta for AI Agents: Pattern di Accesso

Dalla Governance alla Meccanica: Scegliere il Pattern di Accesso Giusto

#

Nel mio articolo precedente sull’Agentic Enterprise Blueprint, ho esplorato come Okta posiziona gli agenti IA come identità di primo livello all’interno del tessuto di sicurezza aziendale. Ho esaminato il framework strategico che risponde a tre domande fondamentali: Dove sono i miei agenti? A cosa possono connettersi? Cosa possono fare?

Ma una strategia senza esecuzione è solo teoria. Ora voglio rispondere a una domanda più pratica: Come dovrebbero autenticarsi e autorizzare le proprie comunicazioni con le risorse aziendali gli agenti IA?

Questa guida è pensata per aiutare architetti, team di sicurezza e solution engineer a valutare i quattro pattern di accesso che Okta for AI Agents mette a disposizione per le integrazioni degli agenti IA. Al termine, capirai:

• Quale pattern si adatta ai tuoi requisiti di sicurezza (contesto utente, riduzione degli scope, audit trail)
• Quale pattern supportano le tue risorse (ID-JAG, OAuth, chiavi API o username/password)
• Come confrontare i livelli di sicurezza tra i pattern
• Quando migrare dai pattern legacy agli approcci moderni

La questione non è accademica. Il pattern di accesso scelto determina:

• Se i tuoi audit log catturano l’attribuzione utente: Riesci a risalire a un’azione fino all’agente e all’utente per conto del quale ha agito?
• Se puoi revocare l’accesso chirurgicamente: Puoi disabilitare l’accesso di un singolo utente a un agente senza influenzare gli altri?
• Se la tua architettura soddisfa i requisiti normativi: La tua implementazione rispetta i mandati di tracciabilità NIST SP 800-63-4¹, EU AI Act², NIS2³, DORA⁴?

Considera questo scenario: il tuo team di sicurezza sta indagando su un incidente di accesso ai dati. Un agente IA ha acceduto a record sensibili dei clienti alle 3:47 di notte. Con il pattern sbagliato, i tuoi audit log potrebbero mostrare solo service-account-agent accessed database. Con il pattern giusto, vedi sales-representative-agent, acting on behalf of john@example.com, accessed customer record #12847 with read scope, transaction ID jti-7z9x2q8. La differenza è architettonica, non casuale.

Okta for AI Agents (O4AA) offre quattro pattern di accesso distinti, ognuno ottimizzato per diversi modelli di sicurezza, capacità delle risorse e requisiti di conformità⁵. La scelta non è arbitraria: è una decisione architettonica fondamentale che definisce la tua postura di sicurezza per gli agenti.

Esaminiamo ogni pattern, capiamo quando usarlo e vediamo come si inseriscono in una strategia di accesso coerente.

I Pattern di Accesso in Sintesi

#

La piattaforma Okta for AI Agents (O4AA) offre quattro modi per un agente di raggiungere una risorsa downstream. Ognuno è configurato come una Managed Connection collegata al workload principal dell’agente in Okta. Scegliere il pattern giusto dipende da tre fattori:

1. Cosa supporta la risorsa downstream? (XAA, ID-JAG, OAuth, chiave API, username/password)
2. È richiesto il contesto a livello utente? (Attribuzione nell’audit, riduzione degli scope per utente)
3. Quali sono i tuoi requisiti di sicurezza e governance? (Profilo di conformità, granularità di revoca)

I Quattro Pattern

#

Matrice di Confronto dei Pattern

#

Framework Decisionale

#

Il framework classifica i pattern per postura di sicurezza: XAA offre le garanzie più solide, mentre Service Account rappresenta quella più debole (e deve essere trattato come temporaneo).

---
config:
  layout: dagre
---
flowchart TB
    A["La risorsa supporta ID-JAG?"] -- Sì --> XAA["✅ Usa XAA
Delegato utente, audit completo,
revoca chirurgica"]
    A -- No --> B["La risorsa supporta OAuth 2.0?"]
    B -- Sì --> STS["🔄 Usa STS
Token brokering con consenso utente"]
    B -- No --> C["La risorsa supporta le chiavi API?"]
    C -- Sì --> PSK["⚠️ Usa PSK
Segreto in vault"]
    C -- No --> SA["🚫 Service Account
Unica opzione — pianifica la migrazione subito"]

    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

Approfondiamo ogni pattern, esploriamo come funzionano, quando usarli, e analizziamo casi d’uso reali ed esempi di configurazione per aiutarti a implementare la strategia di accesso giusta per i tuoi agenti IA.

Cross App Access (XAA)

#

Cross App Access (XAA) è il pattern di accesso di punta di Okta for AI Agents. Implementa l’accesso delegato dall’utente e consapevole del contesto utente tramite l’Identity Assertion JWT Authorization Grant (ID-JAG), uno standard IETF emergente per la delega sicura⁷.

Perché XAA è Importante

#

XAA è il primo pattern di accesso a incorporare il contesto identitario completo a ogni hop in un workflow agente. Ogni token contiene sia:

• sub: L’identità utente (chi ha autorizzato l’azione)
• act.sub: L’identità dell’agente (quale agente sta agendo per conto suo)

Questa struttura a doppia identità abilita capacità impossibili con i tradizionali service account:

• Attribuzione dell’audit per utente: Ogni azione dell’agente è tracciabile fino all’utente specifico che l’ha autorizzata
• Revoca chirurgica: Disabilita l’accesso di un utente a un agente senza influenzare altri utenti o agenti
• Riduzione degli scope: I permessi effettivi del token corrispondono all’intersezione più stretta tra ciò che l’agente può fare, ciò a cui l’utente ha diritto e ciò che il task specifico richiede
• Conformità normativa: Audit trail completi che soddisfano i requisiti di tracciabilità di NIST SP 800-63-4¹, EU AI Act², NIS2³ e DORA⁴

Come Funziona XAA: Il Flusso ID-JAG

#

Il flusso XAA prevede una sequenza di scambio token in cui Okta garantisce l’identità dell’utente al server di autorizzazione della risorsa target.

sequenceDiagram
    autonumber
    actor User
    participant Agent as 🤖 AI Agent
(Workload Principal)
    box rgba(243, 242, 247,0.3) Okta Cloud
        participant OktaAS as 🔐 Okta Org AS
        participant ResourceAS as 🛡️ Custom AS
    end
    participant RS as 📦 Protected Resource

    Note over User, RS: Step 1: User Authentication (SSO)
    User->>Agent: Login via SSO (OIDC)
    Agent->>OktaAS: OIDC authentication
    OktaAS-->>Agent: ID Token (sub: user@example.com)

    Note over User, RS: Step 2: Token Exchange (RFC 8693)
    Agent->>OktaAS: Token Exchange Request
    Note right of Agent: grant_type:token-exchange
subject_token:ID_Token
requested_token_type:id-jag
audience:Custom AS
    OktaAS->>OktaAS: Validate ID Token
    Note right of OktaAS: private_key_jwt
managed connection policy
    OktaAS->>OktaAS: Generate ID-JAG
    OktaAS-->>Agent: ID-JAG (Identity Assertion)
    Note left of OktaAS: sub:user
aud:CustomAS
client_id:agent

    Note over User, RS: Step 3: JWT Bearer Grant (RFC 7523)
    Agent->>ResourceAS: JWT Bearer Request
    Note right of Agent: grant_type:jwt-bearer
assertion:ID-JAG
scope:orders:read
    ResourceAS->>ResourceAS: Validate ID-JAG
    Note left of ResourceAS: aud match
client_id match
signature (JWKS)
    ResourceAS->>ResourceAS: Apply Authorization Policy
    ResourceAS-->>Agent: Access Token
    Note left of ResourceAS: sub + act.sub + scope
ephemeral

    Note over User, RS: Step 4: API Call
    Agent->>RS: API call (with Access Token)
    RS->>RS: Validate Token (JWKS)
    RS-->>Agent: Response data
    Agent-->>User: Display Data

Analisi passo per passo

#

1. L’utente si autentica (SSO): L’utente effettua il login via OIDC attraverso l’agente IA. L’Okta Org AS emette un ID Token contenente l’identità dell’utente (sub: user@example.com).
2. Scambio token in Okta (RFC 8693): L’agente si autentica con le proprie credenziali di workload (private_key_jwt) e richiede uno scambio token (grant_type: token-exchange, subject_token: ID Token, requested_token_type: id-jag, audience: Custom AS). Okta valida l’ID Token, verifica la policy della managed connection e genera un ID-JAG — un JWT firmato contenente sub (utente), aud (Custom AS) e client_id (agente).
3. JWT Bearer grant al Custom AS (RFC 7523): L’agente presenta l’ID-JAG all’endpoint token del Custom AS (grant_type: jwt-bearer, assertion: ID-JAG, scope: orders:read). Il Custom AS valida la firma dell’ID-JAG tramite JWKS, conferma che aud e client_id corrispondano, applica la sua policy di autorizzazione locale ed emette un access token effimero con sub + act.sub.
4. Chiamata API: L’agente chiama la risorsa protetta con l’access token con scope limitato. La risorsa valida il token tramite JWKS e restituisce i dati. La risposta risale attraverso l’agente fino all’utente.

Lo Standard ID-JAG

#

ID-JAG (Identity Assertion JWT Authorization Grant) si basa su diversi standard IETF:

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

Per una panoramica completa di Cross App Access e di come si inserisce nell’ecosistema OAuth, consulta il riferimento Cross App Access su OAuth.net.

L’innovazione chiave è la claim act, che cattura l’identità dell’attore (agente) separatamente dall’identità del soggetto (utente). Questo consente una netta separazione tra “per chi è questa azione” e “quale sistema sta eseguendo l’azione.”

Struttura del Token

#

Un tipico access token XAA contiene:

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

Benefici per Audit e Conformità

#

Con XAA, i log di sistema di Okta catturano un contesto ricco per ogni evento di accesso, incluse le identità di utente e agente, gli scope richiesti, la risorsa target e un ID transazione univoco per la correlazione. L’EventType app.oauth2.token.grant.id_jag indica specificamente quando si è verificato uno scambio ID-JAG, fornendo una chiara audit trail per le azioni degli agenti.

Vediamo un esempio di una voce di log di un evento XAA reale dai log di sistema di Okta:

{
  "actor": {
    "id": "wlpxnnu00000B6vxs1d7",
    "type": "PublicClientApp",
    "alternateId": "unknown",
    "displayName": "Pricing Agent",
    "detailEntry": null
  },
  "client": {
    "userAgent": {
      "rawUserAgent": "python-requests/2.33.1",
      "os": "Unknown",
      "browser": "UNKNOWN"
    },
    "zone": "null",
    "device": "Unknown",
    "id": null,
    "ipAddress": "x.x.x.x",
    "geographicalContext": {
      "city": "Ashburn",
      "state": "Virginia",
      "country": "United States",
      "postalCode": "20149",
      "geolocation": {
        "lat": 39.0469,
        "lon": -77.4903
      }
    }
  },
  "displayMessage": "OAuth 2.0 Identity Assertion Authorization Grant is granted",
  "eventType": "app.oauth2.token.grant.id_jag",
  "outcome": {
    "result": "SUCCESS",
    "reason": null
  },
  "published": "2026-04-16T19:27:49.919Z",
  "securityContext": {
    "asNumber": 14618,
    "asOrg": "amazon.com  inc.",
    "isp": "amazon.com  inc.",
    "domain": "amazonaws.com",
    "isProxy": false,
    "ipDetails": {
      "asNumber": 14618,
      "asOrg": "amazon.com  inc.",
      "isp": "amazon.com  inc.",
      "domain": "amazonaws.com"
    }
  },
  "severity": "INFO",
  "debugContext": {
    "debugData": {
      "clientAuthType": "private_key_jwt",
      "grantedScopes": "pricing:margin",
      "subjectTokenIssuer": "https://xxx.oktapreview.com",
      "subjectTokenType": "urn:ietf:params:oauth:token-type:id_token",
      "clientId": "wlpxnnu00000B6vxs1d7",
      "responseTime": "213",
      "requestedTokenType": "urn:ietf:params:oauth:token-type:id-jag",
      "authorizationServerAudience": "https://xxx.oktapreview.com/oauth2/ausxnnacdm60nV7vv1d7",
      "requestUri": "/oauth2/v1/token",
      "requestedScopes": "pricing:margin",
      "tokenExchangeType": "Agent ID Assertion",
      "url": "/oauth2/v1/token?",
      "managedConnectionId": "mcnxnodu9t2FRZO5R1d7",
      "subjectTokenId": "ID.kiJ9Ch3aBer2ftX2CobkLuSSPqBMdMsZaxwRMZQjr44",
      "subjectTokenClientId": "0oaxnnekviMmWpyBK2d3",
      "requestId": "5eaf3d96ff3dbb684e1099bf8cecdd53",
      "dtHash": "96dec87ffaebc55e64ab62eca30303c555d589e0f9686d55827963c51032ef7f",
      "threatSuspected": "false",
      "grantType": "urn:ietf:params:oauth:grant-type:token-exchange"
    }
  },
  "legacyEventType": null,
  "transaction": {
    "type": "WEB",
    "id": "5eaf3d96ff3dbb684e1099bf8cecdd53",
    "detail": {}
  },
  "uuid": "5b10a39b-39ca-11f1-bbfb-f341db467931",
  "version": "0",
  "request": {
    "ipChain": [
      {
        "ip": "x.x.x.x",
        "geographicalContext": {
          "city": "Ashburn",
          "state": "Virginia",
          "country": "United States",
          "postalCode": "20149",
          "geolocation": {
            "lat": 39.0469,
            "lon": -77.4903
          }
        },
        "version": "V4",
        "source": null,
        "ipDetails": {
          "asNumber": 14618,
          "asOrg": "amazon.com  inc.",
          "isp": "amazon.com  inc.",
          "domain": "amazonaws.com"
        }
      }
    ]
  },
  "target": [
    {
      "id": "ID.kiJ9Ch3aBer2ftX2CobkLuSSPqBMdMsZaxwRMZQjr44",
      "type": "id_token",
      "alternateId": null,
      "displayName": "ID Token",
      "detailEntry": {
        "audience": "0oaxnnekviMmWpyBK2d3",
        "expires": "2026-04-16T20:07:29.000Z",
        "subject": "00uxnn7b13YEcYj2V6a7",
        "hash": "iMQM1uCzsH07nFhkRPUNvg"
      }
    },
    {
      "id": "00uxnn7b13YEcYj2V6a7",
      "type": "User",
      "alternateId": "fabio.grasso@example.com",
      "displayName": "Fabio Grasso",
      "detailEntry": null
    },
    {
      "id": "IDAAG.5ZazR5P-fmm8zuG1CwuqT3EenUx1pFfN00jToEE0s6A",
      "type": "id_jag",
      "alternateId": null,
      "displayName": "Identity Assertion JWT Authorization Grant",
      "detailEntry": {
        "audience": "https://xxx.oktapreview.com/oauth2/ausxnnacdm60nV7vv1d7",
        "expires": "2026-04-16T19:32:49.000Z",
        "subject": "00uxnn7b13YEcYj2V6a7",
        "scope": "pricing:margin",
        "hash": "Tq7wccRtqpRvZvEXKYK9nA"
      }
    }
  ]
}

Come puoi vedere, vengono registrati non solo l’agente che ha effettuato la richiesta (Pricing Agent) ma anche l’utente che ha autorizzato l’azione (fabio.grasso@example.com). Il campo grantedScopes mostra i permessi effettivi concessi all’agente per questa richiesta, ovvero l’intersezione di ciò che l’agente può fare e di ciò a cui l’utente ha diritto. La claim jti nel token diventa il transaction.id nei log, permettendoti di correlare questo evento con gli eventi downstream nei log della tua risorsa, se anch’essa registra l’ID transazione.

Casi d’Uso XAA

#

Vediamo alcuni esempi concreti di come XAA può essere utilizzato per proteggere diversi tipi di risorse:

1. API interna tramite MCP Server — Un agente di supporto clienti deve accedere al database interno degli ordini per rispondere alle richieste dei clienti.
   • Agente registrato nell’Okta Universal Directory
   • MCP Server protetto da un Okta Custom Authorization Server
   • Flusso XAA: l’agente scambia l’ID Token dell’utente per un accesso con scope limitato a orders:read
   • Audit: ogni query registrata con ID utente, ID agente e ID transazione
2. SaaS First-Party (ISV-Enabled) — Un agente assistente alle vendite accede alle opportunità Salesforce per conto di un commerciale.
   • Salesforce implementa la validazione ID-JAG
   • L’agente presenta l’ID-JAG all’endpoint di autorizzazione Salesforce
   • Salesforce emette un token con scope limitato ai soli dati dell’utente
   • Nessuna credenziale statica; nessun service account condiviso
3. Workflow agente multi-step — Un agente finanziario esegue un workflow di approvazione:
   • Step 1: Legge la nota spese (scope read:expenses)
   • Step 2: Verifica la disponibilità di budget (scope read:budgets)
   • Step 3: Invia l’approvazione (scope write:approvals)
   • Ogni step può richiedere scope diversi. Se l’agente viene compromesso a metà workflow, la revoca blocca solo la sessione di quell’utente senza influenzare gli altri.

Testare XAA: Il Playground xaa.dev

#

Okta mette a disposizione un ambiente di test interattivo su xaa.dev dove puoi sperimentare i flussi XAA senza configurare infrastruttura⁸.

Funzionalità:

• Test nel browser (nessun Docker o configurazione locale)
• Componenti preconfigurati: Requesting App, Resource App, IdP
• Avvio in meno di 60 secondi
• Registrazione di client personalizzati per i test

Il playground include un flusso di esempio in cui “Bob Tables” crea e gestisce task tramite un agente IA, dimostrando l’intero scambio ID-JAG.

Limitazioni di XAA

#

• Adozione ISV in corso: XAA è GA lato Okta, ma le integrazioni SaaS di terze parti richiedono il supporto degli ISV. I principali vendor stanno implementando attivamente ID-JAG; costruire su XAA ora garantisce che tu sia pronto quando lo rilasciano.

• Durata del token vs. sessioni lunghe: I token sono effimeri e scadono in pochi minuti, richiedendo nuovi scambi per ogni richiesta. È una scelta progettuale (limita il blast radius) ma può influenzare gli agenti che mettono in cache le credenziali.

• Non adatto per: Agenti che devono operare offline o mettere in cache le credenziali a tempo indeterminato. Per questi scenari, considera STS con un’attenta gestione del ciclo di vita delle credenziali.

Secure Token Service (STS)

#

Secure Token Service (STS) consente agli agenti di accedere ad applicazioni SaaS di terze parti che supportano OAuth ma non hanno ancora adottato XAA. Okta agisce come un broker sicuro, conservando in vault i token consentiti dall’utente e fornendo accesso federato a breve scadenza a runtime.

Nella console di amministrazione Okta, si configura STS creando una managed connection con il tipo di risorsa “Application”, selezionando un’integrazione OIN app o un resource server personalizzato⁹. Okta fa quindi da broker per lo scambio token OAuth tra l’agente e il servizio di terze parti.

Quando Usare STS

#

• SaaS di terze parti con supporto OAuth ma senza supporto ID-JAG (ad es. oggi: GitHub, Google Workspace, Slack)
• Il contesto a livello utente è richiesto per audit e conformità

Come Funziona STS

#

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: Flusso di Consenso Una Tantum
        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: Accesso Agente a Runtime
        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

Analisi passo per passo

#

1. Consenso una tantum: L’utente si autentica e consente al servizio di terze parti
2. Vault dei token: Okta mette al sicuro gli access token e refresh token in Okta Privileged Access
3. Accesso a runtime: L’agente si autentica a Okta con il suo workload principal
4. Scambio token: Okta emette un token federato a breve scadenza per il servizio downstream
5. Accesso API: L’agente chiama l’API di terze parti con il token a breve scadenza; in modo cruciale, le credenziali utente non toccano mai l’agente

Casi d’Uso STS

#

1. GitHub — Un agente assistente di sviluppo legge repository e crea pull request per conto degli sviluppatori. Lo sviluppatore dà il consenso una volta tramite la schermata OAuth di GitHub; Okta mette in vault i token risultanti. A runtime, l’agente riceve un token federato a breve scadenza per chiamare l’API GitHub — non detiene mai credenziali GitHub a lunga scadenza.
2. Google Workspace — Un agente di pianificazione gestisce eventi del calendario e bozze di email per un utente. Il contesto utente viene preservato tramite il flusso di consenso, così i log di audit di Google catturano quale utente ha autorizzato le azioni dell’agente.
3. Jira/Confluence — Un agente di project management crea ticket da conversazioni Slack e aggiorna pagine di documentazione. L’agente si autentica tramite il token intermediato da Okta, senza mai memorizzare direttamente le credenziali Atlassian.

Differenza Chiave con XAA

#

• Flusso di consenso: STS richiede che l’utente passi per la schermata di consenso OAuth del servizio di terze parti; Okta poi archivia e gestisce quei token per conto dell’agente. XAA salta del tutto la schermata di consenso. La delega avviene al momento della registrazione dell’agente in Okta.
• Audit trail: STS cattura il consenso utente e l’accesso dell’agente nei log Okta, ma il servizio di terze parti potrebbe vedere solo l’identità dell’agente. XAA fornisce il contesto completo utente+agente alla risorsa.
• Durata del token: Il token federato emesso all’agente è a breve scadenza (minuti) per limitare il rischio, ma gli access/refresh token sottostanti in Okta potrebbero avere scadenze più lunghe a seconda delle policy del servizio di terze parti.
• Revoca: Revocare l’accesso richiede l’eliminazione della voce nel vault in Okta, il che può influenzare tutti gli agenti che usano quella connessione. Nessuna revoca per utente all’interno del servizio di terze parti.
• Riduzione degli scope: L’agente riceve gli scope a cui l’utente ha acconsentito durante il flusso OAuth. Okta non può ridurre dinamicamente gli scope per richiesta come XAA.

Pre-Shared Key (PSK) o Segreto in Vault

#

Pre-Shared Key (PSK) archivia credenziali statiche (chiavi API, bearer token, segreti webhook) in Okta Privileged Access (OPA). L’agente recupera i segreti a runtime invece di incorporarli nel codice o nella configurazione.

Quando Usare Pre-Shared Key

#

• API REST legacy che supportano solo l’autenticazione con chiave API
• Endpoint webhook che richiedono bearer token
• Integrazioni di terze parti con autenticazione tramite token statico
• Servizi in fase iniziale che aggiungeranno OAuth in futuro

Come Funziona Pre-Shared Key

#

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: Fase di Configurazione
        Admin->>Okta: Create & vault secret (API key)
        Admin->>Okta: Create managed connection on agent
    end

    rect rgb(255, 248, 240)
        Note over Agent,Resource: Accesso a Runtime
        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

Analisi passo per passo

#

1. L’admin mette in vault il segreto: Un amministratore archivia la chiave API o il bearer token in Okta Privileged Access e crea una managed connection sull’agente (tipo: Secret)
2. L’agente si autentica: A runtime, l’agente si autentica a Okta con la sua identità di workload principal
3. Verifica della policy: Okta valida l’identità dell’agente e verifica la policy della managed connection
4. Segreto rilasciato: Okta rilascia la credenziale in vault all’agente
5. Accesso diretto alla risorsa: L’agente utilizza la credenziale statica per chiamare la risorsa downstream direttamente — nessuno scambio token, nessun contesto utente

Limitazioni di Pre-Shared Key

#

• Nessun contesto utente: La risorsa vede solo l’identità dell’agente, non l’utente
• Nessuna riduzione degli scope: L’agente ha accesso completo concesso alla credenziale
• Audit trail limitata: I log mostrano l’accesso dell’agente, senza attribuzione utente

Service Account

#

Service Account utilizza credenziali username e password collegate a un’identità di servizio condivisa. È il pattern legacy da cui Okta raccomanda esplicitamente di migrare.

Come Funziona Service Account

#

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@example)
    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@example
    AgentB->>Resource: Authenticate as svc_agent@example

    Note over Resource: Entrambi appaiono con la stessa identità!

Analisi passo per passo

#

1. L’admin provisiona il service account: Un amministratore configura un service account in Okta Privileged Access e crea managed connection su uno o più agenti
2. L’agente richiede le credenziali: A runtime, ogni agente si autentica a Okta e richiede le credenziali del service account
3. Okta rilascia username/password: Okta valida l’identità dell’agente, verifica la policy e consegna le credenziali condivise
4. L’agente si autentica alla risorsa: L’agente accede alla risorsa downstream come service account — indistinguibile da qualsiasi altro agente che usa le stesse credenziali

Limitazioni dei Service Account

#

I Service Account presentano quattro lacune di sicurezza critiche:

1. Agenti invisibili: Più agenti condividono una singola identità, rendendo impossibile capire quale ha eseguito un’azione
2. Permessi eccessivi: I service account portano tipicamente privilegi ampi e statici che superano di gran lunga ciò che un singolo task richiede
3. Attribuzione utente assente: Gli audit di conformità non possono rispondere a “quale utente ha innescato questo accesso ai dati?”
4. Revoca tutto o niente: Disattivare il service account taglia l’accesso a tutti gli agenti e sistemi che ne dipendono

Quando il Service Account è Inevitabile

#

• Sistemi legacy che richiedono autenticazione username/password (database on-prem, mainframe, servizi LDAP)
• Elaborazioni batch senza contesto utente finale
• Sistemi che non hanno adottato alcun metodo di autenticazione moderno

Il Service Account è accettabile solo per processi batch senza contesto utente, con un piano di dismissione documentato.

Raccomandazioni Strategiche

#

Selezione del Pattern per Profilo di Conformità

#

Sequenza di Implementazione

#

Ecco una roadmap consigliata per la transizione a XAA mantenendo sicurezza e conformità:

• Fase 1: Audit delle integrazioni esistenti
  • Mappare tutte le connessioni degli agenti su uno dei quattro pattern
  • Identificare service account e pre-shared key
• Fase 2: Le nuove integrazioni adottano XAA per default
  • Usare STS solo quando XAA non è supportato
  • Usare Service Account o Pre-Shared Key solo quando assolutamente necessario
  • Documentare il razionale per le scelte non-XAA
• Fase 3: Monitorare le roadmap ISV
  • Man mano che gli ISV adottano ID-JAG, migrare le connessioni STS a XAA
  • Seguire gli annunci di adozione
• Fase 4: Dismissione di Service Account e Pre-Shared Key
  • Stabilire una timeline formale di deprecazione
  • Migrare a STS come step intermedio
  • Obiettivo: zero service account per workload con contesto utente

Dalla Teoria alla Pratica: Configurare i Pattern di Accesso in Okta

#

Nell’Okta Universal Directory, puoi registrare agenti IA come identità di workload e creare Managed Connection che definiscono come accedono alle risorse downstream. Ogni tipo di connessione corrisponde a uno dei pattern di accesso discussi sopra.

Lista Agenti IA	Dettaglio Agente IA

Quando crei una managed connection, vedrai cinque tipi di risorsa. Corrispondono ai quattro pattern di accesso trattati in questo articolo:

Panoramica della Configurazione XAA

#

Implementare XAA richiede:

1. Registrare l’agente nell’Okta Universal Directory come workload principal
2. Creare una Managed Connection e selezionare “Authorization Server” (per API personalizzate) o “MCP Server” (per endpoint MCP). Entrambi usano lo stesso scambio ID-JAG internamente.
3. Configurare il Custom Authorization Server che protegge la tua risorsa
4. Definire policy RBAC che valutino sia gli attributi utente che quelli dell’agente

Esempio di logica di policy, per garantire che l’agente possa accedere ai dati di vendita solo quando l’utente è membro del team commerciale:

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

Questo è un esempio in pseudo-codice. Nella console di amministrazione Okta, le access policy del Custom Authorization Server usano un modello a policy + regola — non un linguaggio di scripting. Per seguire l’esempio puoi:

1. Creare una Access Policy assegnata all’agente IA (cioè sales-representative-agent). Questo limita implicitamente la policy a quell’agente specifico (act.sub).
2. Creare una Regola all’interno di quella policy:
   • Grant type: JWT Bearer (il grant dello scambio ID-JAG)
   • Idoneità utente: Utenti membri del gruppo: sales-team — questo garantisce che solo i membri del team commerciale possano delegare l’accesso tramite questo agente
   • Scope: Allowlist di orders:read e accounts:read — l’agente non può richiedere scope più ampi anche se l’utente li possiede
   • Durata del token: 5 minuti (effimero)
   • Valutazione: Le policy e le regole vengono valutate in ordine di priorità. Vince il primo match. Se nessuna regola corrisponde (ad es. un utente fuori dal sales-team prova a usare questo agente), la richiesta viene rifiutata.

Il risultato: l’agente può accedere ai dati di vendita solo quando l’utente che sta dietro alla richiesta è membro del team commerciale. I permessi effettivi sono l’intersezione della allowlist di scope della policy, dell’appartenenza al gruppo dell’utente e della managed connection dell’agente.

Conclusioni

#

La scelta del pattern di accesso non è un dettaglio tecnico: è una decisione architettonica che definisce la postura di sicurezza dei tuoi agenti IA per gli anni a venire.

Punti chiave:

1. XAA è il futuro: Delegato dall’utente, verificabile, conforme. Investire in XAA ora significa che la tua architettura è pronta per MCP Server e il supporto Agent-to-Agent nel momento in cui arriveranno.

2. STS colma il divario: Per i SaaS di terze parti che supportano OAuth ma non ID-JAG, STS fornisce il contesto utente mentre aspetti l’adozione ISV.

3. Pre-Shared Key è accettabile per il legacy: I servizi che supportano solo chiavi API richiedono segreti in vault, ma pianifica la migrazione man mano che le risorse si modernizzano.

4. Service Account è debito tecnico: Ogni service account è un gap di conformità che aspetta di emergere in un audit. Inizia a pianificare la tua uscita.

Il percorso da Service Account → Pre-Shared Key → STS → XAA rappresenta una progressione di maturità nella sicurezza. Ogni scalino aggiunge contesto utente, riduzione degli scope e granularità di audit.

XAA sarà anche la base per funzionalità future come Agent-to-Agent Access (A2A), Kill Switch (revoca globale dei token), i workflow Human-in-the-Loop (HITL). Iniziare con XAA significa non solo proteggere le integrazioni di oggi, ma anche prepararsi per le innovazioni di domani.

Per Iniziare

#

Prova XAA Oggi

#

Esplora il playground XAA interattivo su xaa.dev, senza configurazione necessaria. Sperimenta il flusso ID-JAG completo nel tuo browser.

Approfondisci

#

• Okta for AI Agents: Panoramica della piattaforma
• Cross App Access Solution: Pagina della soluzione XAA
• Cross App Access Documentation: Guida alla configurazione ufficiale
• XAA.dev Documentation: Documentazione del playground interattivo
• Cross App Access Introduction: Approfondimento tecnico
• XAA Developer Playground: Tutorial pratico
• Building Resource Apps: Guida all’implementazione
• Agentic Enterprise Blueprint: Framework di governance strategica
• Demo Interattiva: Securing the Autonomous Enterprise: Demo

Unisciti alla Conversazione

#

Quali integrazioni nel tuo ambiente usano ancora service account? Hai iniziato a mappare le connessioni dei tuoi agenti su questi pattern di accesso? Dove sei in questo percorso?

Condividi la tua esperienza nei commenti qui sotto o connettiti con me su LinkedIn per continuare la discussione.