Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Sessions politiques et propagation de l'identité

Grâce aux politiques temporelles, vous pouvez définir des règles en fonction des événements passés survenus au cours d'une session, et pas seulement de la demande en cours. Vous pouvez appliquer des contraintes telles que :

Une session de politique regroupe plusieurs appels Gateway en une seule session logique. La session est la limite au-delà de laquelle les règles de politique temporelle sont évaluées.

Comment ça marche

Transmission de l'ID de session politique

Incluez l'x-amzn-bedrock-agentcore-policy-session-iden-tête de vos demandes adressées à la passerelle. Vous devez générer l'identifiant de session et l'envoyer à chaque demande, en commençant par votre première demande. La passerelle ne génère pas d'identifiant de session en votre nom. La valeur est une chaîne qui identifie la session, et nous recommandons un UUIDv4. Envoyez le même identifiant pour chaque demande au cours de la même session.

Si vous omettez l'en-tête ou si vous envoyez une valeur vide, la passerelle n'établit pas de session. Si le moteur de politique associé contient une politique temporelle, les demandes sans identifiant de session échouent avec une erreur de validation.

Pour connaître le format accepté et la manière dont la passerelle le valide, consultez la section Vérification des en-têtes et déploiements hors environnement d'exécution.

Première demande (crée la session) :

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"
      }
    }
  }'

Demandes suivantes (continuer la session) :

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"
      }
    }
  }'

Si votre politique temporelle limite chaque session à un transfert, la deuxième demande présentée dans l'exemple précédent sera refusée.

Exemple 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

Cycle de vie des sessions

Propagation d'identité dans des scénarios à sauts multiples

Dans les architectures agentiques, une requête passe souvent par plusieurs AgentCore primitives :

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

Pour que les politiques temporelles fonctionnent à travers ces sauts, l'identité de session doit être préservée. AgentCoregère cela automatiquement à l'aide de la chaîne d'identité de charge de travail (WIC)  :

Ce que cela signifie pour vous :

End-to-end débit :

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         |
 |                 |                   |                   |----------------->|

Considérations importantes

Utilisation de l'ID de session avec les SDK

Vous pouvez transmettre l'ID de session de politique via n'importe quel client qui prend en charge les en-têtes personnalisés sur les requêtes Gateway. Les exemples suivants montrent comment l'inclure lors de l'utilisation du SDK MCP Python et des agents Strands.

Utilisez la même valeur d'ID de session pour tous les appels d'une même session logique. Lorsqu'une nouvelle conversation démarre, générez un nouvel identifiant de session.

Client MCP (SDK Python) :

Lorsque vous utilisez le SDK MCP Python avec un transport HTTP streamable, incluez l'ID de session dans les en-têtes de connexion :

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"}
))

Agents Strands :

Lorsque vous utilisez des agents Strands avec une AgentCore passerelle comme source d'outil, transmettez l'ID de session dans les en-têtes de transport du client MCP. Tous les appels d'outils effectués par l'agent au cours de la session concernent la même session, et les politiques temporelles évaluent l'historique complet.

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 cas d'utilisation des clients

Les scénarios suivants illustrent la manière dont les politiques temporelles permettent de relever les défis courants en matière de sécurité et de conformité dans les applications agentiques.

Services financiers — limitation des taux de transfert

Une application fintech permet aux utilisateurs finaux d'effectuer des virements bancaires via un agent conversationnel. Sans politique temporelle, un agent compromis ou en boucle pourrait exécuter un nombre illimité de transferts en une seule session. Avec une limite de débit limitée à chaque session, la passerelle applique un nombre maximum de transferts par session :

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

Chaque session utilisateur utilise son propre identifiant de session. La limite de débit est réinitialisée lorsqu'une nouvelle session démarre, car un nouvel identifiant de session crée une nouvelle limite d'évaluation.

Soins de santé — contrôles des escalades

Un agent de santé accède aux dossiers des patients et peut également envoyer des messages à des systèmes de notification externes. Une politique temporelle impose qu'une fois que les données du patient ont été consultées, aucun appel d'API externe n'est autorisé pour le reste de la session. Cela empêche l'exfiltration de données même si les instructions de l'agent sont manipulées en cours de session :

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

La contrainte ne réside pas dans l'outil lui-même, mais send_notification est autorisé dans les sessions qui n'accèdent jamais aux données des patients. La politique tient compte de ce qui s'est passé plus tôt au cours de cette session particulière.

DevOps — contraintes de séquençage

Un agent de déploiement doit suivre une séquence obligatoire : les tests doivent réussir avant de procéder au déploiement. Une politique temporelle applique ce qui ne Deploy peut être appelé qu'après avoir RunTests été appelé au cours de la même session :

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)

Cela garantit la séquence de déploiement, quelle que soit la manière dont l'agent est invité ou quelle structure d'orchestration le contrôle.

Multi-tenant SaaS — application du budget par utilisateur

Une plateforme SaaS héberge des agents d'IA pour plusieurs utilisateurs finaux derrière un identifiant d'application partagé (CUSTOM_JWTavec des sub demandes par utilisateur via des flux On-Behalf-Of (OBO)). La session de chaque utilisateur reçoit un identifiant de session unique. Comme la passerelle lie la session à la fois à l'ID de session et au principal authentifié, les sessions des différents utilisateurs sont automatiquement isolées. Une politique temporelle impose « au maximum 100$ d'appels d'outils par session », évalués indépendamment par utilisateur, même si tout le trafic arrive via le même identifiant d'application.

Choix de la portée de la session : sessions larges par rapport à des sessions restreintes

L'ID de session que vous fournissez détermine la limite d'évaluation des politiques temporelles. Le choix du bon scope affecte à la fois la sécurité et la facilité d'utilisation :

Conseils :

Vérification des en-têtes et déploiements non liés à l'exécution

Comment la passerelle vérifie l'ID de session

Lorsque la passerelle reçoit l'x-amzn-bedrock-agentcore-policy-session-iden-tête, elle effectue la validation suivante :

Si vous appelez directement la passerelle (sans AgentCore Runtime)

Lorsque votre application appelle directement le point de terminaison de la passerelle (par exemple, un service principal effectuant des requêtes HTTP vers l'URL de la passerelle), vous gérez vous-même l'ID de session :

Aucune configuration, autorisation ou appel d'API supplémentaire n'est nécessaire. La passerelle crée la session lors de la première utilisation et l'expire après 24 heures d'inactivité.

Si vos demandes passent par AgentCore Runtime

Lorsque les appels empruntent le chemin Utilisateur → Passerelle → Runtime (agent) → Gateway (appel d'outil), il vous suffit de transmettre l'ID de session de la demande initiale à la première passerelle. La plateforme intègre l'ID de session dans le jeton d'accès à la charge de travail (WAT) et le propage automatiquement à travers tous les sauts en aval. Votre code d'agent n'a pas besoin de lire, de stocker ou de transférer l'ID de session : il arrive à la passerelle de réception de manière transparente.

À propos du jeton d'accès à la charge de travail (WAT)

Le jeton d'accès à la charge de travail est un jeton opaque AWS signé qui contient le contexte d'identité d'une demande lorsqu'elle circule entre les AgentCore services. Lorsque la politique temporelle est active, le WAT contient :

Le WAT est de courte durée (TTL de 15 minutes), signé cryptographiquement par le service AgentCore d'identité et opaque pour tous les participants. Il ne peut pas être falsifié, falsifié ou décodé par les appelants ou les intermédiaires.

Vous n'interagissez pas directement avec le WAT. Il est porté sur l'X-Amz-Bedrock-AgentCore-Identity-WATen-tête interne, qui est entièrement géré par la plateforme. Cette explication est fournie afin que vous compreniez comment fonctionne la continuité de session entre les sauts. Vous n'avez aucune action à effectuer concernant le WAT.

Pour plus de détails sur l'identité de la charge de travail et les jetons d'accès, voir Obtenir un jeton d'accès à la charge de travail et Comprendre les identités de la charge de travail.