Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Sesi kebijakan dan propagasi identitas

Dengan kebijakan temporal, Anda dapat menentukan aturan berdasarkan peristiwa masa lalu yang telah terjadi dalam sesi, bukan hanya permintaan saat ini. Anda dapat menerapkan batasan seperti:

Sesi kebijakan mengelom pokkan beberapa pemanggilan Gateway ke dalam satu sesi logis. Sesi adalah batas di mana aturan kebijakan temporal dievaluasi.

Cara kerjanya

Meneruskan ID sesi kebijakan

Sertakan x-amzn-bedrock-agentcore-policy-session-id header pada permintaan Anda ke Gateway. Anda harus membuat ID sesi dan mengirimkannya pada setiap permintaan, dimulai dengan permintaan pertama Anda. Gateway tidak menghasilkan ID sesi atas nama Anda. Nilai adalah string yang mengidentifikasi sesi, dan kami merekomendasikan UUIDv4. Kirim ID yang sama dengan setiap permintaan dalam sesi yang sama.

Jika Anda menghilangkan header, atau mengirim nilai kosong, Gateway tidak membuat sesi. Jika mesin kebijakan terkait berisi kebijakan temporal, permintaan tanpa ID sesi gagal dengan kesalahan validasi.

Untuk format yang diterima dan cara Gateway memvalidasinya, lihat Verifikasi header dan penerapan non-Runtime.

Permintaan pertama (membuat sesi):

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

Permintaan selanjutnya (lanjutkan sesi):

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

Jika kebijakan temporal Anda membatasi setiap sesi ke 1 transfer, permintaan kedua yang ditunjukkan pada contoh sebelumnya akan ditolak.

Contoh 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

Siklus hidup sesi

Propagasi identitas dalam skenario multi-hop

Dalam arsitektur agentic, permintaan sering mengalir melalui beberapa AgentCore primitif:

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

Agar kebijakan temporal berfungsi di seluruh hop ini, identitas sesi harus dipertahankan. AgentCoremenangani ini secara otomatis menggunakan Work load Identity Chain (WIC):

Apa artinya ini bagi Anda:

End-to-end aliran:

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

Pertimbangan penting

Menggunakan ID sesi dengan SDK

Anda dapat meneruskan ID sesi kebijakan melalui klien mana pun yang mendukung header khusus pada permintaan Gateway. Contoh berikut menunjukkan cara memasukkannya saat menggunakan MCP Python SDK dan Strands Agents.

Gunakan nilai ID sesi yang sama di semua panggilan dalam sesi logis yang sama. Saat percakapan baru dimulai, buat ID sesi baru.

Klien MCP (Python SDK):

Saat Anda menggunakan MCP Python SDK dengan transportasi HTTP yang dapat dialirkan, sertakan ID sesi di header koneksi:

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

Agen helai:

Saat Anda menggunakan Strands Agents dengan AgentCore Gateway sebagai sumber alat, berikan ID sesi di header transportasi klien MCP. Semua panggilan alat yang dilakukan agen selama sesi membawa sesi yang sama, dan kebijakan temporal mengevaluasi riwayat lengkap.

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 kasus penggunaan pelanggan

Skenario berikut menggambarkan bagaimana kebijakan temporal mengatasi tantangan keamanan dan kepatuhan umum dalam aplikasi agen.

Layanan keuangan — pembatasan tingkat transfer

Aplikasi fintech memungkinkan pengguna akhir untuk memulai transfer bank melalui agen percakapan. Tanpa kebijakan temporal, agen yang dikompromikan atau pengulangan dapat mengeksekusi transfer tak terbatas dalam satu sesi. Dengan batas tarif bercakupan sesi, Gateway memberlakukan jumlah transfer maksimum per sesi:

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

Setiap sesi pengguna menggunakan ID sesinya sendiri. Batas tarif diatur ulang saat sesi baru dimulai, karena ID sesi baru membuat batas evaluasi baru.

Perawatan kesehatan — kontrol eskalasi

Seorang agen perawatan kesehatan mengakses catatan pasien dan juga dapat mengirim pesan ke sistem notifikasi eksternal. Kebijakan temporal memberlakukan bahwa setelah data pasien diakses, tidak ada panggilan API eksternal yang diizinkan untuk sisa sesi. Ini mencegah eksfiltrasi data bahkan jika perintah agen dimanipulasi di tengah sesi:

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

Kendala tidak ada pada alat itu sendiri - send_notification diizinkan dalam sesi yang tidak pernah mengakses data pasien. Kebijakan tersebut mempertimbangkan apa yang terjadi sebelumnya dalam sesi khusus ini.

DevOps — kendala sekuensing

Agen penerapan harus mengikuti urutan wajib: pengujian harus lulus sebelum penerapan berlanjut. Kebijakan temporal memberlakukan yang hanya Deploy dapat dipanggil setelah di RunTests panggil dalam sesi yang sama:

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)

Ini menjamin urutan penerapan terlepas dari bagaimana agen diminta atau kerangka orkestrasi mana yang mengendalikannya.

Multi-tenant SaaS — penegakan anggaran per pengguna

Platform SaaS menghosting agen AI untuk beberapa pengguna akhir di balik kredenSIAL aplikasi bersama (CUSTOM_JWTdengan sub klaim per pengguna melalui aliran On-Behalf-Of (OBO)). Setiap sesi pengguna menerima ID sesi unik. Karena Gateway mengikat sesi ke ID sesi dan prinsipal yang diautentikasi, sesi pengguna yang berbeda secara otomatis diisolasi. Kebijakan temporal memberlakukan “paling banyak $100 dalam panggilan alat per sesi” — dievaluasi secara independen per pengguna, meskipun semua lalu lintas tiba melalui kredensi aplikasi yang sama.

Memilih ruang lingkup sesi: sesi luas versus sempit

ID sesi yang Anda berikan menentukan batas evaluasi untuk kebijakan temporal. Memilih ruang lingkup yang tepat memengaruhi keamanan dan kegunaan:

Bimbingan:

Verifikasi header dan penerapan non-runtime

Cara Gateway memverifikasi ID sesi

Ketika Gateway menerima x-amzn-bedrock-agentcore-policy-session-id header, ia melakukan validasi berikut:

Jika Anda memanggil Gateway secara langsung (tanpa AgentCore Runtime)

Ketika aplikasi Anda memanggil titik akhir Gateway secara langsung — misalnya, layanan backend yang membuat permintaan HTTP ke URL Gateway — Anda mengelola ID sesi sendiri:

Tidak diperlukan konfigurasi tambahan, izin, atau panggilan API. Gateway membuat sesi pada penggunaan pertama dan kedaluwarsa setelah 24 jam tidak aktif.

Jika permintaan Anda mengalir melalui AgentCore Runtime

Ketika panggilan melintasi jalur Pengguna → Gateway → Runtime (agen) → Gateway (panggilan alat), Anda hanya perlu meneruskan ID sesi pada permintaan awal ke Gateway pertama. Platform menyematkan ID sesi di dalam Token Akses Beban Kerja (WAT) dan menyebarkannya secara otomatis melalui semua hop hilir. Kode agen Anda tidak perlu membaca, menyimpan, atau meneruskan ID sesi — kode tersebut tiba di Gateway penerima secara transparan.

Tentang Token Akses Beban Kerja (WAT)

Token Akses Beban AWS Kerja adalah token buram yang ditandatangani yang membawa konteks identitas permintaan saat mengalir antar AgentCore layanan. Ketika kebijakan temporal aktif, WAT berisi:

WAT berumur pendek (TTL 15 menit), ditandatangani secara kriptografis oleh layanan AgentCore Identity, dan buram untuk semua peserta. Itu tidak dapat dipalsukan, dirusak, atau diterjemahkan oleh penelepon atau perantara.

Anda tidak berinteraksi dengan WAT secara langsung. Itu dilakukan pada X-Amz-Bedrock-AgentCore-Identity-WAT header internal, yang dikelola sepenuhnya oleh platform. Penjelasan ini disediakan agar Anda memahami bagaimana kontinuitas sesi bekerja di seluruh hop — Anda tidak perlu mengambil tindakan apa pun terkait WAT.

Untuk detail selengkapnya tentang identitas beban kerja dan token akses, lihat Mend apatkan token akses beban kerja dan Memahami identitas beban kerja.