本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

政策工作階段和身分傳播

透過暫時政策，您可以根據工作階段中過去發生的事件來定義規則，而不只是目前請求。您可以強制執行限制，例如：

政策工作階段會將多個閘道調用分組為單一邏輯工作階段。工作階段是評估時間政策規則的邊界。

運作方式

傳遞政策工作階段 ID

在對閘道的請求中包含 x-amzn-bedrock-agentcore-policy-session-id標頭。您必須產生工作階段 ID，並在每次請求時傳送，從第一個請求開始。Gateway 不會代表您產生工作階段 ID。此值是可識別工作階段的字串，我們建議使用 UUIDv4。傳送與相同工作階段中每個請求相同的 ID。

如果您省略 標頭，或傳送空值，閘道不會建立工作階段。如果關聯的政策引擎包含暫時政策，則沒有工作階段 ID 的請求會失敗並出現驗證錯誤。

如需可接受的格式以及閘道驗證方式，請參閱標頭驗證和非執行時間部署。

第一個請求 （建立工作階段）：

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

後續請求 （繼續工作階段）：

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

如果您的暫時政策將每個工作階段限制為 1 次轉移，則上述範例中顯示的第二個請求將被拒絕。

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

工作階段生命週期

多躍點案例中的身分傳播

在代理式架構中，請求通常會流經多個 AgentCore 基本概念：

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

若要讓暫時政策跨這些躍點運作，必須保留工作階段身分。AgentCore 會使用工作負載身分鏈 (WIC) 自動處理此問題：

這對您的意義：

End-to-end流程：

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

重要考量

搭配 SDKs使用工作階段 ID

您可以透過在閘道請求上支援自訂標頭的任何用戶端傳遞政策工作階段 ID。下列範例示範如何在使用 MCP Python SDK 和 Strands Agents 時包含它。

在相同邏輯工作階段中的所有呼叫中使用相同的工作階段 ID 值。當新的對話開始時，產生新的工作階段 ID。

MCP 用戶端 (Python SDK)：

當您使用 MCP Python SDK 搭配可串流的 HTTP 傳輸時，請在連線標頭中包含工作階段 ID：

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

Strands 代理程式：

當您使用 Strands Agents 搭配 AgentCore Gateway 做為工具來源時，請在 MCP 用戶端傳輸標頭中傳遞工作階段 ID。客服人員在工作階段期間進行的所有工具呼叫都具有相同的工作階段，而時間政策會評估完整的歷史記錄。

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

實際客戶使用案例

下列案例說明時間政策如何解決代理程式應用程式中常見的安全與合規挑戰。

金融服務 — 傳輸速率限制

金融科技應用程式可讓最終使用者透過對話式客服人員啟動銀行轉帳。如果沒有時間政策，遭入侵或迴圈代理程式可以在單一工作階段中執行無限制的傳輸。使用工作階段範圍速率限制，Gateway 會強制執行每個工作階段的傳輸次數上限：

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

每個使用者工作階段都會使用自己的工作階段 ID。速率限制會在新的工作階段開始時重設，因為新的工作階段 ID 會建立新的評估界限。

醫療保健 — 呈報控制

醫療保健代理程式會存取患者記錄，也可以傳送訊息至外部通知系統。暫時政策會強制執行存取病患資料後，工作階段的其餘部分不允許外部 API 呼叫。即使代理程式的提示在工作階段中被操作，這也可防止資料外洩：

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

限制條件不在工具本身 - send_notification 在永遠不會存取病患資料的工作階段中是允許的。此政策會考量此特定工作階段先前發生的情況。

DevOps — 排序限制條件

部署代理程式必須遵循強制性序列：測試必須通過，才能繼續部署。暫時政策會強制執行只能在相同工作階段中呼叫 RunTests 之後Deploy才能呼叫 ：

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)

無論代理程式的提示方式或哪個協同運作架構控制它，這都能保證部署序列。

多租戶 SaaS — 每個使用者預算強制執行

SaaS 平台會在共用應用程式登入資料後方，為多個最終使用者託管 AI 代理程式 (CUSTOM_JWT透過On-Behalf-Of(OBO) 流程使用每個使用者sub宣告）。每個使用者的工作階段都會收到唯一的工作階段 ID。由於閘道會將工作階段繫結至工作階段 ID 和已驗證的主體，因此會自動隔離不同使用者的工作階段。時間政策會強制執行「每個工作階段最多 100 USD 的工具呼叫」，即使所有流量都透過相同的應用程式登入資料抵達，也要為每個使用者獨立評估。

選擇工作階段範圍：廣泛或窄的工作階段

您提供的工作階段 ID 會決定暫時政策的評估界限。選擇正確的範圍會影響安全性和可用性：

指導：

標頭驗證和非執行時間部署

閘道如何驗證工作階段 ID

當閘道收到 x-amzn-bedrock-agentcore-policy-session-id標頭時，會執行下列驗證：

如果您直接呼叫閘道 （不含 AgentCore 執行期）

當您的應用程式直接呼叫閘道端點時，例如向閘道 URL 發出 HTTP 請求的後端服務，您可以自行管理工作階段 ID：

不需要額外的組態、許可或 API 呼叫。Gateway 會在第一次使用時建立工作階段，並在閒置 24 小時後將其過期。

如果您的請求流經 AgentCore 執行期

當 呼叫周遊路徑 使用者 → 閘道 → 執行時間 （代理程式） → 閘道 （工具呼叫） 時，您只需將初始請求上的工作階段 ID 傳遞給第一個閘道。平台會將工作階段 ID 嵌入工作負載存取字符 (WAT)，並自動傳播到所有下游躍點。您的代理程式程式碼不需要讀取、儲存或轉送工作階段 ID，它會透明地抵達接收的閘道。

關於工作負載存取字符 (WAT)

工作負載存取字符是一種 AWS簽署的不透明字符，在 AgentCore 服務之間流動時攜帶請求的身分內容。當暫時政策處於作用中狀態時，WAT 會包含：

WAT 是短期 (15 分鐘 TTL)，由 AgentCore Identity 服務以密碼編譯方式簽署，並對所有參與者不透明。它不能被發起人或中介人偽造、竄改或解碼。

您不會直接與 WAT 互動。它在內部X-Amz-Bedrock-AgentCore-Identity-WAT標頭上進行，該標頭完全由 平台管理。提供此說明是為了讓您了解工作階段持續性如何跨躍點運作，您不需要對 WAT 採取任何動作。

如需工作負載身分和存取字符的詳細資訊，請參閱取得工作負載存取字符和了解工作負載身分。