Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Kebijakan temporal
Kebijakan di Amazon Bedrock AgentCore mendukung kebijakan temporal: kebijakan yang keputusannya bergantung pada riwayat tindakan agen dalam sesi, bukan pada permintaan saat ini saja. Dengan mereka, Anda dapat menerapkan aturan yang mencakup beberapa tindakan, seperti memerlukan persetujuan sebelum tindakan, membatasi berapa kali tindakan berjalan dalam jendela waktu, atau menjaga total berjalan di bawah ambang batas.
Kebijakan temporal adalah forbid aturan permit atau yang berisi satu atau lebih operator temporal. Setiap kondisi cocok dengan peristiwa sebelumnya yang direkam untuk sesi berdasarkan tindakan, prinsip, dan bidang input atau output tindakan, dan hanya mempertimbangkan peristiwa dalam jendela waktu yang diperlukan. Suatu kondisi dapat mengkorelasikan peristiwa yang cocok dengan permintaan saat ini, sehingga aturan dapat mengharuskan, misalnya, bahwa permintaan saat ini bertindak pada sumber daya yang telah disetujui tindakan sebelumnya. Mesin kebijakan merekam setiap peristiwa sesi dan mengevaluasi kondisi ini pada setiap permintaan, sehingga Anda menyatakan aturan yang sadar sesi sebagai kebijakan alih-alih melacak peristiwa di agen atau kode alat Anda.
Kebijakan temporal ditulis dalam Dogwood, yang kompatibel dengan Cedar dan mendukung semua kebijakan Cedar yang ada. Kebijakan standar Cedar tidak memiliki kewarganegaraan dan hanya mempertimbangkan permintaan saat ini. Kebijakan temporal mengikuti model penolakan secara default yang sama: permintaan hanya diperbolehkan jika permit berlaku dan tidak ada forbid yang mengesampingkannya. Kondisi temporal berbeda dari kondisi berbasis waktu, yang membatasi akses berdasarkan waktu jam dinding (context.system.now) daripada riwayat sesi. Anda juga dapat menjalankan kebijakan temporal dalam LOG_ONLY mode untuk mengamati apa yang akan diputuskan sebelum mempromosikannyaENFORCE; lihat Mode penegakan kebijakan.
Topik
Konsep Utama
Kebijakan temporal dibangun di atas dua hal: bahasa kebijakan Dogwood, yang mengekspresikan aturan sadar sesi, dan sesi kebijakan, yang mencakup riwayat yang dapat dilihat oleh aturan.
Bahasa kebijakan Dogwood
Kebijakan temporal ditulis dalam Dogwood, bahasa kebijakan sumber terbuka yang digunakan Kebijakan untuk otor AgentCore isasi sadar sesi. Dogwood dibangun di atas Cedar dan menggunakan model otorisasi yang sama: Anda menulis permit forbid dan mengatur prinsip, tindakan, dan sumber daya, dan permintaan hanya diizinkan ketika permit berlaku dan tidak ada yang mengesamping forbid kannya. Dogwood kompatibel dengan Cedar dan mendukung semua kebijakan Cedar yang ada, jadi setiap kebijakan Cedar yang valid juga merupakan kebijakan Dogwood yang valid. Kebijakan point-in-time Anda yang ada terus berfungsi tanpa perubahan, dan Anda menambahkan kondisi temporal hanya jika aturan harus mempertimbangkan lebih dari permintaan saat ini.
Dengan Dogwood, Anda mengekspresikan aturan sadar sesi secara deklaratif sebagai kebijakan alih-alih menerapkan logika pelacakan peristiwa di agen atau kode alat Anda. Mesin kebijakan mencatat peristiwa yang relevan dan mengevaluasi kondisi pada setiap permintaan. Misalnya, kebijakan berikut mengizinkan penjualan hanya jika persetujuan pencocokan terjadi dalam jam sebelumnya:
permit ( principal, action == AgentCore::Action::"TradingTarget___SellShares", resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway" ) when temporal { formerly within 1h AgentCore::Action::"TradingTarget___ApproveSale"::response{ eventResource: resource, input.stock: context.input.stock, input.shares: context.input.shares, output.approved: true } };
Dogwood menyediakan operator temporal untuk pola umum: formerly within (peristiwa pencocokan terjadi sebelumnya di jendela), since within (suatu kondisi telah berlaku sejak peristiwa jangkar), dan agregasi count dan di sum atas peristiwa yang cocok di jendela.
Untuk sintaks temporal lengkap, lihat panduan bahasa Dogwood
Sesi kebijakan dan ID sesi
Kebijakan temporal mengevaluasi terhadap sesi kebijakan: urutan pemanggilan Gateway terkait yang dikelompokkan di bawah satu ID sesi. Riwayat temporal dicakup ke sesi, jadi suatu kondisi hanya mempertimbangkan peristiwa yang direkam untuk sesi yang sama dengan permintaan yang diotorisasi. Anda menghasilkan ID sesi dan mengirimkannya pada setiap permintaan di x-amzn-bedrock-agentcore-policy-session-id header, dimulai dengan permintaan pertama Anda. Gateway tidak menghasilkan ID sesi atas nama Anda. 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 detail tentang meneruskan ID sesi, siklus hidup sesi, dan bagaimana identitas menyebar di seluruh panggilan multi-hop, lihat Sesi kebijakan dan propagasi identitas.
Pembatalan sesi
Kebijakan temporal memutuskan apakah akan mengizinkan tindakan dengan melihat apa yang terjadi sebelumnya di sesi yang sama. Sejarah itu hanya bermakna terhadap kebijakan temporal yang berlaku ketika sesi dimulai. Jika Anda mengubah kebijakan temporal engine saat sesi terbuka, riwayat yang direkam tidak lagi sesuai dengan aturan saat ini, sehingga layanan mengakhiri sesi alih-alih membuat keputusan terhadap data yang tidak konsisten.
Menambahkan atau memperbarui kebijakan temporal pada mesin akan membatalkan sesi kebijakan temporal aktif engine. Setelah perubahan seperti itu, permintaan berikutnya yang menggunakan kembali sesi yang tidak valid gagal dengan HTTP 409. ConflictException
Untuk memulihkan, mulai sesi baru dan kirim permintaan lagi. Sesi baru dimulai dengan riwayat kosong dan dievaluasi terhadap kebijakan Anda yang diperbarui.
Didukung AWS Wilayah
Kebijakan temporal tersedia di Wil AWS ayah yang ditandai dalam tabel berikut.
| Nama wilayah | Kebijakan temporal |
|---|---|
|
Asia Pasifik (Hyderabad) |
Tidak |
|
Asia Pasifik (Malaysia) |
Tidak |
|
Asia Pasifik (Mumbai) |
✓ Ya |
|
Asia Pasifik (Seoul) |
✓ Ya |
|
Asia Pasifik (Singapura) |
✓ Ya |
|
Asia Pasifik (Sydney) |
✓ Ya |
|
Asia Pasifik (Thailand) |
Tidak |
|
Asia Pasifik (Tokyo) |
✓ Ya |
|
Kanada (Pusat) |
✓ Ya |
|
Eropa (Frankfurt) |
✓ Ya |
|
Eropa (Irlandia) |
✓ Ya |
|
Eropa (London) |
✓ Ya |
|
Europe (Milan) |
Tidak |
|
Eropa (Paris) |
✓ Ya |
|
Eropa (Spanyol) |
✓ Ya |
|
Eropa (Stockholm) |
✓ Ya |
|
Amerika Selatan (Sao Paulo) |
✓ Ya |
|
AS Timur (Virginia Utara) |
✓ Ya |
|
AS Timur (Ohio) |
✓ Ya |
|
AS Barat (California Utara) |
Tidak |
|
AS Barat (Oregon) |
✓ Ya |
Pertimbangan-pertimbangan
Cross-account dan permintaan lintas wilayah
Sesi kebijakan temporal tidak mendukung propagasi lintas wilayah atau lintas akun. Kebijakan temporal tidak mengontrol permintaan antara AgentCore Gateway dan target Runtime mereka ketika sumber daya tersebut berada di akun yang berbeda atau Wil AWS ayah yang berbeda. Agar kebijakan temporal dapat mengontrol tindakan agen Anda, gateway dan semua targetnya harus berada di AWS akun dan AWS Wilayah yang sama.
Kebijakan temporal memberlakukan akses hanya ketika Token Akses Beban Kerja (WAT) berjalan melalui rantai permintaan (lihat S esi kebijakan dan propagasi identitas). Ketika rantai permintaan Anda seluruhnya terdiri dari komponen AgentCore Gateway dan Runtime AgentCore, menyebarkan header WAT secara otomatis dari satu hop ke yang berikutnya. Propagasi ini terjadi dalam satu AWS Wilayah dan akun. Kebijakan temporal berlaku di seluruh rantai. Sebuah rantai seperti Gateway to Runtime to Gateway to Runtime membawa token ujung ke ujung tanpa pekerjaan tambahan di pihak Anda.
Rantain yang menyertakan komponen non-gateway atau Runtime berperilaku berbeda. Permintaan mungkin melewati infrastruktur yang Anda operasikan sendiri, seperti gateway API pihak ketiga atau cluster Kubernetes. Komponen itu harus meneruskan header WAT, dan Anda harus menambahkan logika khusus untuk menyebarkan WAT melalui hop tersebut. Lokasi fisik non- AgentCore komponen tersebut tidak mempengaruhi ruang lingkup regional dan akun. Mereka dapat berjalan di mana saja, asalkan AgentCore komponen di kedua sisi kembali ke AWS akun dan AWS Wilayah yang sama di mana kebijakan temporal berlaku.
Izin IAM yang diperlukan
Kebijakan temporal juga membawa prasyarat IAM. Peran IAM yang dikonfigurasi untuk Gateway harus mengizinkan bedrock-agentcore:GetWorkloadAccessToken tindakan. Persyaratan ini berlaku bahkan ketika Anda menggunakan IAM untuk otorisasi keluar Anda. WAT memungkinkan kebijakan temporal untuk menghubungkan tindakan agen di seluruh sesi. Gateway harus dapat memperoleh WAT terlepas dari bagaimana Anda mengotentikasi panggilan keluar. Jika peran kehilangan izin ini, penegakan kebijakan temporal gagal. Ber bedrock-agentcore:GetWorkloadAccessToken ikan ke peran Gateway saat Anda mengonfigurasi kebijakan temporal. Untuk kebijakan izin lengkap, termasuk ARN sumber daya dan cakupan direktori identitas beban kerja, lihat izin IAM untuk kebijakan temporal.
Self-referential Kondisi termasuk permintaan saat ini
Ketika kondisi temporal mereferensikan tindakan yang sama yang sedang diotorisasi, peristiwa permintaan saat ini sendiri dimasukkan dalam evaluasi. Misalnya, kondisi yang menghitung berapa kali tindakan terjadi dalam jendela menghitung pemanggilan saat ini juga.
Tindakan sebelumnya harus diizinkan untuk dicatat sebagai tanggapan
Riwayat sesi mencatat setiap tindakan sebagai peristiwa yang jenisnya mencerminkan hasilnya: tindakan yang diizinkan yang diselesaikan dicatat sebagai response peristiwa, dan tindakan yang ditolak kebijakan dicatat sebagai error peristiwa. Kondisi temporal hanya cocok dengan peristiwa dari jenis namanya, jadi kondisi yang cocok dengan response peristiwa hanya mempertimbangkan tindakan sebelumnya yang diizinkan. Pastikan tindakan sebelumnya yang diandalkan kebijakan temporal itu sendiri diizinkan oleh kebijakan; jika ditolak, itu dicatat sebagai error bukan aresponse, dan response kondisi tidak pernah cocok dengannya.
Tindakan pengurutan yang bergantung pada respons sebelumnya
Riwayat sesi mencatat setiap response peristiwa tindakan setelah tindakan selesai. Jika kebijakan bergantung pada respons tindakan sebelumnya dalam sesi yang sama, seperti bidang keluaran atau since kondisi, keluarkan permintaan dependen setelah Anda menerima tanggapan tindakan sebelumnya. Menyelesaikan setiap tindakan sebelum memulai tindakan yang bergantung padanya, urutan alur kerja Anda tetap selaras dengan riwayat yang dievaluasi kebijakan.
Kuota
Kuota berikut berlaku untuk kebijakan temporal:
| Kuota | Nilai |
|---|---|
|
Kebijakan temporal per mesin kebijakan |
25 |
|
Operator temporal per kebijakan |
3 |
|
Jendela waktu maksimum per kondisi temporal |
24 jam |
Observabilitas
Amazon Bedrock AgentCore menerbitkan metrik dan data rentang yang memungkinkan Anda mengamati evaluasi kebijakan temporal. Metrik dipublikasikan ke AWS/Bedrock-AgentCore CloudWatch namespace secara default. Data rentang tersedia setelah Anda mengaktifkan pelacakan untuk sumber daya AgentCore Gateway terlampir, dan dapat ditemukan di grup CloudWatch aws/spans log.
Sinyal-sinyal berikut khusus untuk kebijakan temporal:
-
TemporalLatency(metrik): waktu yang dihabiskan untuk mengevaluasi kebijakan temporal, dalam milidetik. Satu sampel dipancarkan untuk setiap evaluasi temporal, sehingga Anda dapat menggunakanSampleCountstatistik untuk menghitung evaluasi. -
aws.agentcore.policy.temporal.latency_ms(atribut span): waktu yang dihabiskan untuk mengevaluasi kebijakan temporal untuk permintaan, dalam milidetik. -
aws.agentcore.policy.temporal.evaluation_invoked(atribut span): apakah evaluasi temporal berjalan untuk permintaan. Ini tidak menunjukkan bahwa kebijakan temporal cocok atau menentukan keputusan. -
aws.agentcore.policy.temporal.event_timestamp_ns(atribut span): stempel waktu peristiwa yang tepat yang digunakan evaluator untuk memesan acara permintaan, dalam nanodetik.
Untuk daftar lengkap metrik kebijakan, dimensi, dan atribut rentang, serta cara mengaktifkan observabilitas, lihat Kebijakan dalam data AgentCore pengamatan.
Pertimbangan keamanan
Pembatasan tarif dengan kebijakan temporal berlaku dalam satu sesi. Karena riwayat temporal dicakup ke sesi dan ID sesi disediakan oleh pemanggil, batas count berbasis seperti “paling banyak N panggilan per sesi” hanya menghitung peristiwa yang direkam untuk sesi itu. Memulai sesi baru memulai penghitungan baru, jadi batas tarif temporal membatasi aktivitas dalam sesi daripada di semua sesi pemanggil.