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

Menguji kebijakan dalam mode LOG_ONLY

Menggunakan mode penegakan tingkat kebijakan, Anda dapat beralih antara ACTIVE dan LOG_ONLY untuk menjawab pertanyaan: “Apa yang akan dilakukan kebijakan ini terhadap lalu lintas saya jika diterapkan?” LOG_ONLYMode per kebijakan memungkinkan Anda menguji kebijakan pada lalu lintas nyata tanpa memengaruhi keputusan otorisasi. Kebijakan mengevaluasi setiap permintaan seolah-olah diterapkan, tetapi hanya menulis hasil ke log. Tidak ada yang diblokir atau diizinkan sebagai akibat dari kebijakan yang mode penegakannyaLOG_ONLY. Setelah Anda mempercayai hasilnya, promosikan keACTIVE.

Cara kerja mode LOG_ONLY

Setiap kebijakan dalam mesin kebijakan memiliki mode penegakan salah satu ACTIVE atauLOG_ONLY. Defaultnya adalahACTIVE, jadi kebijakan yang ada, dan kebijakan baru apa pun yang Anda buat tanpa menentukan bidang, terus diberlakukan seperti sebelumnya. Ketika mesin kebijakan mengevaluasi permintaan, itu mengevaluasi ACTIVE kebijakan dan LOG_ONLY kebijakan Anda secara berdampingan, tetapi hanya memberlakukan ACTIVE kebijakan Anda.

ACTIVEkebijakan menentukan keputusan yang dikembalikan ke AgentCore Gateway dan ditegakkan. Mesin kebijakan menerapkan semantik “default-deny” dan “bid-wins”, yang berarti bahwa permintaan hanya diizinkan jika kebijakan mengizinkannya, dan larangan tunggal dari kebijakan aktif mana pun menyangkalnya.

LOG_ONLYkebijakan dievaluasi terhadap permintaan yang sama, tetapi hasilnya tetap terpisah. Mereka dilaporkan dalam jejak dan dipancarkan sebagai CloudWatch metrik Amazon. Mereka tidak pernah digabungkan ke dalam keputusan yang ditegakkan.

Permintaan dievaluasi dalam dua tahap:

ACTIVEdan LOG_ONLY diperlakukan sebagai dua set terisolasi; LOG_ONLY kebijakan tidak pernah dapat mengubah apa yang dialami penelepon Anda. Keputusan yang diterima permintaan tidak terpengaruh oleh LOG_ONLY kebijakan apa pun.

Selain merekam LOG_ONLY kebijakan yang sesuai dengan permintaan, mesin kebijakan melaporkan kebijakan mana yang akan mengubah keputusan jika memang demikianACTIVE. Ini adalah sinyal kunci untuk digunakan ketika menilai kemanjuran dan keamanan kebijakan (yaitu, apakah dapat dipromosikanACTIVE). Misalnya, LOG_ONLY kebijakan yang sering cocok dan muncul di kumpulan pembalikan keputusan akan memblokir lalu lintas Anda selama jendela pengamatan. Setiap LOG_ONLY kebijakan dievaluasi secara independen dari semua LOG_ONLY kebijakan lain untuk menentukan kumpulan kebijakan pembalikan keputusan. Namun, setiap evaluasi LOG_ONLY kebijakan mempertimbangkan semua ACTIVE kebijakan saat ini.

Kebijakan LOG_ONLY dan mesin kebijakan LOG_ONLY

Policy in AgentCore memiliki dua kontrol terpisah yang keduanya menggunakan nilai LOG_ONLY. Mereka beroperasi di lapisan yang berbeda dan menjawab pertanyaan yang berbeda, jadi penting untuk memahami mana yang Anda atur.

Mode penegakan mesin kebijakan: mengontrol perilaku keseluruhan mesin. Saat disetel keLOG_ONLY, tidak ada kebijakan di mesin yang diberlakukan, terlepas dari mode kebijakan individualnya. Semua keputusan dicatat. Ini diatur menggunakan mode bidang policyEngineConfiguration saat Anda mengaitkan mesin kebijakan dengan gateway menggunakan UpdateGateway operasi CreateGateway atau. Dua nilai yang diterima mode adalah ENFORCE (default) danLOG_ONLY.

Mode kebijakan mengontrol perilaku kebijakan tunggal dalam mesin penegakan. Ketika disetel ke LOG_ONLY, kebijakan itu masih dievaluasi, tetapi keputusannya dicatat dan bukan diberlakukan. Semua ACTIVE kebijakan lain di mesin terus diberlakukan secara normal. Dua nilai yang diterima enforcementMode adalah ACTIVE (default) danLOG_ONLY.

Gunakan LOG_ONLY tingkat kebijakan untuk menguji bayangan pagar pembatas baru dalam produksi tanpa mempengaruhi lalu lintas. Gunakan LOG_ONLY tingkat engine untuk mengamati perilaku semua kebijakan sebelum mengaktifkan penegakan.

Mengatur mode penegakan kebijakan

Anda dapat mengatur enforcementMode bidang pada kebijakan saat membuat atau memperbarui kebijakan (yaitu, CreatePolicy danUpdatePolicy), dan itu dikembalikan oleh GetPolicy danListPolicies.

Buat kebijakan dalam LOG_ONLY mode Buat kebijakan dalam LOG_ONLY mode dengan menyet enforcementMode el ke LOG_ONLY dalam CreatePolicy permintaan. Contoh berikut menciptakan pagar pembatas dalam kebijakan yang melarang konten kekerasan di atas ambang kepercayaan, tetapi hanya mengamatinya. Untuk informasi selengkapnya tentang pagar pembatas dalam kebijakan, lihat pagar pembatas dalam kebijakan.

aws bedrock-agentcore-control create-policy \
--policy-engine-id my-policy-engine-id \
--name "LogOnlyViolenceFilter" \
--enforcement-mode LOG_ONLY \
--validation-mode IGNORE_ALL_FINDINGS \
--definition '{"policy":{"statement":"forbid (principal, action == AgentCore::Action::\"MyTarget\", resource == AgentCore::Gateway::\"arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/my-gateway\") when guardrails { BedrockGuardrails::ContentFilter([\"VIOLENCE\"], [context.input.userMessage])[\"VIOLENCE\"].confidenceScore.greaterThan(decimal(\"0.7\")) };"}}'

Tanggapan menggemakan kebijakan dengan “enforcement Mode”: “LOG_ONLY”. Kebijakan mulai mengevaluasi terhadap lalu lintas dan sejak saat itu kecocokannya muncul dalam jejak dan CloudWatch metrik — tanpa mempengaruhi keputusan apa pun.

Daftar kebijakan dan mode penegakannya

ListPolicies pengembalian enforcementMode dalam setiap ringkasan kebijakan, sehingga Anda dapat melihat sekilas kebijakan mana yang diamati dan mana yang ditegakkan.

aws bedrock-agentcore-control list-policies \
--policy-engine-id my-policy-engine-id \
--query 'policies[].{name:name,enforcementMode:enforcementMode,status:status}'

tanggapan

[
  { "name": "LogOnlyViolenceFilter", "enforcementMode": "LOG_ONLY", "status": "ACTIVE" },
  { "name": "RefundLimit",           "enforcementMode": "ACTIVE",   "status": "ACTIVE" }
]

Amati hasil LOG_ONLY

Ketika penelepon membuat tools/call permintaan melalui AgentCore Gateway, gateway mengevaluasi semua kebijakan - termasuk LOG_ONLY kebijakan - sebelum mengembalikan respons MCP ke penelepon. Tanggapan penelepon tidak pernah terpengaruh oleh LOG_ONLY kebijakan; hasil tersebut dilaporkan hanya melalui pengamatan.

Anda mengamati perilaku LOG_ONLY kebijakan melalui jejak dan CloudWatch metrik Amazon:

Pelacakan dan rentang: Saat Anda mengaktifkan pelacakan di gateway, rentang evaluasi kebijakan menyertakan informasi kecocokanLOG_ONLY. Anda dapat memeriksa rentang ini di konsol AgentCore Observability untuk melihat LOG_ONLY kebijakan mana yang dijalankan pada permintaan tertentu dan apakah kebijakan tersebut akan membalik keputusan. Untuk informasi selengkapnya, lihat Mengamati aplikasi agen Anda di Amazon Bedrock AgentCore Observ ability.

CloudWatch metrik: Kebijakan dalam AgentCore memancarkan metrik di bawah AWS/Bedrock-AgentCore namespace. Metrik berikut khusus untuk LOG_ONLY evaluasi:

Semua metrik termasuk PolicyEngine dan OperationName dimensi untuk pemfilteran. Per-policy metrik juga menyertakan dimensi Kebijakan dengan ID kebijakan.

Untuk informasi selengkapnya tentang melihat metrik untuk AgentCore sumber daya Anda, lihat data pengam atan AgentCore yang dihasilkan oleh Bedrock.

Mempromosikan kebijakan untuk penegakan

Ketika Anda yakin dengan suatu LOG_ONLY kebijakan, promosikan ke penegakan denganUpdatePolicy, setel enforcementMode keACTIVE. Tidak ada perubahan lain yang diperlukan, dan kebijakan menyimpan ID, nama, dan definisinya.

aws bedrock-agentcore-control update-policy \
--policy-engine-id my-policy-engine-id \
--policy-id LogOnlyViolenceFilter-a1b2c3d4e5 \
--enforcement-mode ACTIVE

Kebalikannya juga didukung: Anda dapat memindahkan ACTIVE kebijakan kembali LOG_ONLY ke untuk mengeluarkannya dari penegakan sambil menjaganya tetap di tempatnya dan terus mengamatinya.

Oleh karena itu, siklus hidup tipikal adalah membuat kebijakanLOG_ONLY, mengamati lalu lintas dan metrik, lalu mempromosikannya ke ACTIVE — dan, jika perlu, menurunkannya kembali ke LOG_ONLY tanpa menghapus dan membuat ulang kebijakan.

Memilih ambang batas dengan mode LOG_ONLY

LOG_ONLYmode sangat berguna untuk kebijakan pagar pembatas, di mana Anda perlu memilih ambang batas skor kepercayaan yang menyeimbangkan keamanan terhadap gangguan terhadap lalu lintas yang sah. Ambang batas yang terlalu rendah memblokir permintaan yang sah; yang terlalu tinggi dapat membiarkan ancaman lewat.

Alur kerja yang disarankan: Terapkan pagar pembatas dalam LOG_ONLY mode dengan ambang batas yang Anda yakini masuk akal (misalnya, 0,7). Kebijakan mengevaluasi setiap permintaan dan memancarkan skor kepercayaan ke CloudWatch metrik, tetapi tidak pernah memblokir lalu lintas.

Mengumpulkan data melalui jendela representatif — hari atau minggu lalu lintas produksi nyata. Met ConfidenceScore rik (dengan PolicyEnforcementMode = LOG_ONLY) memberi Anda distribusi skor yang dihasilkan lalu lintas Anda.

Analisis skor terhadap kebenaran dasar. Jika Anda memiliki set pengujian berlabel (petunjuk yang ditandai sebagai jinak atau berbahaya), Anda dapat menghitung presisi dan penarikan pada setiap nilai ambang batas dan memilih salah satu yang paling sesuai dengan tujuan Anda. Jika Anda tidak memiliki data berlabel, contoh meminta dari rentang skor tinggi (misalnya, 0,8—1,0), rentang skor rendah (0-0,2), dan zona tengah ambigu (0,4—0,7), lalu klasifikasikan setiap sampel untuk membangun kepercayaan pada pilihan ambang batas Anda. Perbarui kebijakan dengan ambang batas yang Anda pilih dan promosikan keACTIVE:

aws bedrock-agentcore-control update-policy \
--policy-engine-id my-policy-engine-id \
--policy-id LogOnlyViolenceFilter-a1b2c3d4e5 \
--enforcement-mode ACTIVE \
--definition '{"policy":{"statement":"forbid (principal, action == AgentCore::Action::\"MyTarget\", resource == AgentCore::Gateway::\"arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/my-gateway\") when guardrails { BedrockGuardrails::ContentFilter([\"VIOLENCE\"], [context.input.userMessage])[\"VIOLENCE\"].confidenceScore.greaterThan(decimal(\"0.65\")) };"}}'

Alur kerja ini memastikan ambang batas mencerminkan pola lalu lintas aktual Anda daripada default umum.

Pertimbangan dan batasan

LOG_ONLYKebijakan tidak pernah mempengaruhi keputusan. LOG_ONLYKebijakan tidak dapat menyebabkan tindakan diizinkan atau ditolak. Keputusan yang diterima permintaan identik dengan keputusan yang akan diterimanya jika LOG_ONLY kebijakan tidak ada. Ini adalah jaminan inti dari fitur ini.

Perubahan pada akhirnya konsisten. Membuat, memperbarui, atau mempromosikan kebijakan diterapkan ke jalur evaluasi dalam beberapa detik. Rencanakan jendela pengamatan dan langkah-langkah promosi Anda sesuai dengan itu daripada mengharapkan peralihan instan.

Daftar hasil dibatasi. LOG_ONLYDaftar kecocokan dan pembalikan keputusan masing-masing dibatasi pada 1.000 entri per permintaan. Untuk mesin dengan jumlah LOG_ONLY kebijakan yang sangat besar, andalkan CloudWatch metrik untuk penghitungan agregat lengkap.

Evaluasi bisa bersifat parSIAL. Ketika LOG_ONLY evaluasi tidak lengkap untuk permintaan, LOG_ONLY sinyal untuk permintaan itu mungkin hilang entri. Keputusan yang ditegakkan tidak pernah terpengaruh.