Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Sessioni di policy e propagazione delle identità

Con le politiche temporali, puoi definire regole basate sugli eventi passati che si sono verificati all'interno di una sessione, non solo sulla richiesta corrente. Puoi applicare vincoli come:

Una sessione di policy raggruppa più chiamate Gateway in un'unica sessione logica. La sessione è il limite oltre il quale vengono valutate le regole politiche temporali.

Come funziona

Passaggio dell'ID di sessione della policy

Includi l'x-amzn-bedrock-agentcore-policy-session-idintestazione nelle tue richieste al Gateway. È necessario generare l'ID di sessione e inviarlo per ogni richiesta, a partire dalla prima richiesta. Il Gateway non genera un ID di sessione per conto dell'utente. Il valore è una stringa che identifica la sessione e consigliamo un UUIDv4. Invia lo stesso ID per ogni richiesta nella stessa sessione.

Se si omette l'intestazione o si invia un valore vuoto, il Gateway non stabilisce una sessione. Se il motore di policy associato contiene una policy temporale, le richieste senza un ID di sessione hanno esito negativo e viene generato un errore di convalida.

Per il formato accettato e il modo in cui il Gateway lo convalida, vedi Verifica dell'intestazione e implementazioni non in fase di esecuzione.

Prima richiesta (crea la sessione):

curl -X POST \
  https://mygateway-abcdefghij.gateway.bedrock-agentcore.us-west-2.amazonaws.com/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "x-amzn-bedrock-agentcore-policy-session-id: 12345678-1234-1234-1234-123456789012" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "PaymentTool___transfer_funds",
      "arguments": {
        "amount": 500,
        "recipient": "account-789"
      }
    }
  }'

Richieste successive (continua la sessione):

curl -X POST \
  https://mygateway-abcdefghij.gateway.bedrock-agentcore.us-west-2.amazonaws.com/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "x-amzn-bedrock-agentcore-policy-session-id: 12345678-1234-1234-1234-123456789012" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "PaymentTool___transfer_funds",
      "arguments": {
        "amount": 600,
        "recipient": "account-456"
      }
    }
  }'

Se la tua politica temporale limita ogni sessione a 1 trasferimento, la seconda richiesta mostrata nell'esempio precedente verrà rifiutata.

Esempio di Python:

import requests
import uuid

GATEWAY_URL = "https://mygateway-abcdefghij.gateway.bedrock-agentcore.us-west-2.amazonaws.com/mcp"
ACCESS_TOKEN = "YOUR_ACCESS_TOKEN"

# Generate or reuse a session ID for the conversation
session_id = str(uuid.uuid4())  # for example, "12345678-1234-1234-1234-123456789012"

def call_tool(tool_name, arguments, session_id):
    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {ACCESS_TOKEN}",
        "x-amzn-bedrock-agentcore-policy-session-id": session_id
    }

    payload = {
        "jsonrpc": "2.0",
        "id": "request-1",
        "method": "tools/call",
        "params": {
            "name": tool_name,
            "arguments": arguments
        }
    }

    response = requests.post(GATEWAY_URL, headers=headers, json=payload)
    return response.json()


# First call - allowed
result1 = call_tool(
    "PaymentTool___transfer_funds",
    {"amount": 500, "recipient": "account-789"},
    session_id
)
print(result1)  # Success

# Second call in same session - may be denied by temporal policy
result2 = call_tool(
    "PaymentTool___transfer_funds",
    {"amount": 600, "recipient": "account-456"},
    session_id
)
print(result2)  # Denied if rate-limit policy applies

Ciclo di vita della sessione

Propagazione dell'identità in scenari con più hop

Nelle architetture agentiche, una richiesta spesso fluisce attraverso più primitive: AgentCore

User -> Gateway1 -> Runtime (agent) -> Gateway1 (tool call) -> Target

Affinché le politiche temporali funzionino su questi salti, l'identità della sessione deve essere preservata. AgentCorelo gestisce automaticamente utilizzando la Workload Identity Chain (WIC):

Cosa significa per te:

End-to-end flusso:

User            Gateway1            Runtime            Gateway1            Target
 |  POST /mcp      |                   |                   |                  |
 |  + session-id X |                   |                   |                  |
 |  + Authorization|                   |                   |                  |
 |---------------->|                   |                   |                  |
 |                 | mint WAT1         |                   |                  |
 |                 | (sid=X, cpn=user) |                   |                  |
 |                 |  forward + WAT1   |                   |                  |
 |                 |------------------>|                   |                  |
 |                 |                   |exchange WAT1->WAT2|                  |
 |                 |                   | (sid=X preserved) |                  |
 |                 |                   | tool call + WAT2  |                  |
 |                 |                   |------------------>|                  |
 |                 |                   |                   | evaluate temporal|
 |                 |                   |                   | policy, session X|
 |                 |                   |                   |  forward         |
 |                 |                   |                   |----------------->|

Considerazioni importanti

Utilizzo dell'ID di sessione con gli SDK

Puoi passare l'ID di sessione della policy tramite qualsiasi client che supporti intestazioni personalizzate sulle richieste Gateway. Gli esempi seguenti mostrano come includerlo quando si utilizzano MCP Python SDK e Strands Agents.

Utilizzate lo stesso valore ID di sessione per tutte le chiamate nella stessa sessione logica. Quando inizia una nuova conversazione, genera un nuovo ID di sessione.

Client MCP (Python SDK):

Quando usi MCP Python SDK con un trasporto HTTP in streaming, includi l'ID della sessione nelle intestazioni della connessione:

from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client
import asyncio

SESSION_ID = "12345678-1234-1234-1234-123456789012"

async def call_with_session(gateway_url, token, tool_name, arguments):
    headers = {
        "Authorization": f"Bearer {token}",
        "x-amzn-bedrock-agentcore-policy-session-id": SESSION_ID
    }

    async with streamablehttp_client(url=gateway_url, headers=headers) as (read, write, _):
        async with ClientSession(read, write) as session:
            await session.initialize()
            result = await session.call_tool(name=tool_name, arguments=arguments)
            return result

result = asyncio.run(call_with_session(
    "https://mygateway-abcdefghij.gateway.bedrock-agentcore.us-west-2.amazonaws.com/mcp",
    "YOUR_TOKEN",
    "PaymentTool___transfer_funds",
    {"amount": 500, "recipient": "account-789"}
))

Agenti Strands:

Quando utilizzi Strands Agents con un AgentCore gateway come origine dello strumento, passa l'ID di sessione nelle intestazioni di trasporto del client MCP. Tutte le chiamate allo strumento effettuate dall'agente durante la sessione hanno la stessa sessione e le politiche temporali valutano la cronologia completa.

from strands.tools.mcp.mcp_client import MCPClient
from mcp.client.streamable_http import streamablehttp_client

SESSION_ID = "12345678-1234-1234-1234-123456789012"

def create_transport(mcp_url, access_token):
    return streamablehttp_client(
        mcp_url,
        headers={
            "Authorization": f"Bearer {access_token}",
            "x-amzn-bedrock-agentcore-policy-session-id": SESSION_ID
        }
    )

mcp_client = MCPClient(lambda: create_transport(gateway_url, token))
with mcp_client:
    result = mcp_client.call_tool_sync(
        tool_use_id="tool-1",
        name="PaymentTool___transfer_funds",
        arguments={"amount": 500, "recipient": "account-789"}
    )

Real-world casi d'uso dei clienti

Gli scenari seguenti illustrano in che modo le politiche temporali risolvono le comuni sfide di sicurezza e conformità nelle applicazioni agentiche.

Servizi finanziari: limitazione della velocità di trasferimento

Un'applicazione fintech consente agli utenti finali di avviare bonifici bancari tramite un agente conversazionale. Senza una politica temporale, un agente compromesso o in loop potrebbe eseguire trasferimenti illimitati in un'unica sessione. Con un limite di velocità basato sull'ambito della sessione, il Gateway impone un numero massimo di trasferimenti per sessione:

User: "Transfer $500 to Alice"      -> Allowed (1 of 3)
User: "Transfer $200 to Bob"        -> Allowed (2 of 3)
User: "Transfer $1000 to Charlie"   -> Allowed (3 of 3)
User: "Transfer $50 to Dave"        -> DENIED by temporal policy

Ogni sessione utente utilizza il proprio ID di sessione. Il limite di frequenza viene ripristinato all'avvio di una nuova sessione, poiché un nuovo ID di sessione crea un nuovo limite di valutazione.

Assistenza sanitaria: controlli di escalation

Un operatore sanitario accede alle cartelle cliniche dei pazienti e può anche inviare messaggi a sistemi di notifica esterni. Una politica temporale impone che, una volta effettuato l'accesso ai dati dei pazienti, non siano consentite chiamate API esterne per il resto della sessione. Ciò impedisce l'esfiltrazione dei dati anche se i prompt dell'agente vengono manipolati a metà sessione:

Agent: calls PatientRecords___read_chart      -> Allowed
Agent: calls ExternalAPI___send_notification  -> DENIED (sensitive data was accessed in this session)

Il vincolo non è sullo strumento stesso, ma send_notification è consentito nelle sessioni che non hanno mai accesso ai dati dei pazienti. La politica considera ciò che è accaduto all'inizio di questa particolare sessione.

DevOps — vincoli di sequenziamento

Un agente di distribuzione deve seguire una sequenza obbligatoria: i test devono essere superati prima che la distribuzione proceda. Si applica una politica temporale che Deploy può essere richiamata solo dopo essere RunTests stata chiamata nella stessa sessione:

Agent: calls Deploy___to_production   -> DENIED (RunTests not yet called in this session)
Agent: calls RunTests___execute       -> Allowed
Agent: calls Deploy___to_production   -> Allowed (RunTests was called earlier in this session)

Ciò garantisce la sequenza di distribuzione indipendentemente da come viene richiesto all'agente o dal framework di orchestrazione che lo controlla.

Multi-tenant SaaS: applicazione del budget per utente

Una piattaforma SaaS ospita agenti di intelligenza artificiale per più utenti finali dietro una credenziale di applicazione condivisa (CUSTOM_JWTcon richieste per utente tramite flussi (OBO)sub). On-Behalf-Of La sessione di ogni utente riceve un ID di sessione univoco. Poiché il Gateway associa la sessione sia all'ID di sessione che al principale autenticato, le sessioni dei diversi utenti vengono automaticamente isolate. Una policy temporale impone «al massimo 100 USD in chiamate agli strumenti per sessione», valutate indipendentemente per utente, anche se tutto il traffico arriva tramite le stesse credenziali dell'applicazione.

Scelta dell'ambito della sessione: sessioni ampie o ristrette

L'ID di sessione fornito determina il limite di valutazione per le politiche temporali. La scelta dell'ambito giusto influisce sia sulla sicurezza che sull'usabilità:

Linee guida:

Verifica dell'intestazione e implementazioni non in fase di esecuzione

In che modo il Gateway verifica l'ID della sessione

Quando il Gateway riceve l'x-amzn-bedrock-agentcore-policy-session-idintestazione, esegue la seguente convalida:

Se chiami direttamente il Gateway (senza AgentCore Runtime)

Quando l'applicazione chiama direttamente l'endpoint Gateway, ad esempio un servizio di backend che effettua richieste HTTP all'URL del Gateway, gestisci tu stesso l'ID di sessione:

Non sono necessarie configurazioni, autorizzazioni o chiamate API aggiuntive. Il Gateway crea la sessione al primo utilizzo e la fa scadere dopo 24 ore di inattività.

Se le tue richieste fluiscono tramite Runtime AgentCore

Quando le chiamate attraversano il percorso User → Gateway → Runtime (agent) → Gateway (tool call), è sufficiente passare l'ID di sessione della richiesta iniziale al primo Gateway. La piattaforma incorpora l'ID di sessione all'interno del Workload Access Token (WAT) e lo propaga automaticamente in tutti gli hop a valle. Il codice agente non deve leggere, archiviare o inoltrare l'ID di sessione: arriva al Gateway ricevente in modo trasparente.

Informazioni sul Workload Access Token (WAT)

Il Workload Access Token è un token opaco con AWS firma che riporta il contesto di identità di una richiesta durante il flusso tra i servizi. AgentCore Quando la policy temporale è attiva, il WAT contiene:

Il WAT è di breve durata (TTL di 15 minuti), firmato crittograficamente dal servizio AgentCore Identity e opaco per tutti i partecipanti. Non può essere falsificato, manomesso o decodificato da chiamanti o intermediari.

Non interagisci direttamente con il WAT. Viene riportato sull'X-Amz-Bedrock-AgentCore-Identity-WATintestazione interna, gestita interamente dalla piattaforma. Questa spiegazione viene fornita in modo da comprendere come funziona la continuità della sessione tra gli hop: non è necessario intraprendere alcuna azione in merito al WAT.

Per maggiori dettagli sull'identità del carico di lavoro e sui token di accesso, consulta Get workload access token e Understanding workload identities.