Uji kebijakan dalam mode LOG_ONLY

Dengan 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 tentang lalu lintas nyata tanpa memengaruhi keputusan otorisasi. Kebijakan mengevaluasi setiap permintaan seolah-olah ditegakkan, tetapi hanya menulis hasil ke log. Tidak ada yang diblokir atau diizinkan sebagai akibat dari kebijakan yang modus 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 bidangnya, terus diberlakukan seperti sebelumnya. Ketika mesin kebijakan mengevaluasi permintaan, itu mengevaluasi ACTIVE kebijakan dan kebijakan Anda secara berdampingan, tetapi hanya memberlakukan LOG_ONLY kebijakan Anda. ACTIVE

ACTIVEkebijakan menentukan keputusan yang dikembalikan ke AgentCore Gateway dan diberlakukan. Mesin kebijakan menerapkan semantik “default-deny” dan “forbid-win”, yang berarti bahwa permintaan hanya diperbolehkan jika kebijakan mengizinkannya, dan satu larangan dari kebijakan aktif menyangkalnya.

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

Permintaan dievaluasi dalam dua tahap:

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

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

Kebijakan LOG_ONLY dan mesin kebijakan LOG_ONLY

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

Mode penegakan mesin kebijakan: mengontrol perilaku mesin secara keseluruhan. Jika 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 mode menerima adalah ENFORCE (default) danLOG_ONLY.

Mode kebijakan mengontrol perilaku kebijakan tunggal dalam mesin penegak. Saat disetel ke LOG_ONLY, kebijakan itu masih dievaluasi, tetapi keputusannya dicatat daripada diberlakukan. Semua ACTIVE kebijakan lain di mesin terus ditegakkan secara normal. Dua nilai yang enforcementMode menerima adalah ACTIVE (default) danLOG_ONLY.

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

Mengatur mode penegakan kebijakan

Anda dapat menyetel enforcementMode bidang pada kebijakan saat membuat atau memperbarui kebijakan (yaitu, CreatePolicy danUpdatePolicy), dan akan ditampilkan oleh GetPolicy danListPolicies.

Buat kebijakan dalam LOG_ONLY mode Buat kebijakan dalam LOG_ONLY mode dengan menyetel enforcementMode ke LOG_ONLY dalam CreatePolicy permintaan. Contoh berikut membuat 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\")) };"}}'

Respons menggemakan kebijakan dengan “enforcementMode”: “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 mengembalikan enforcementMode 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}'

respon

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

Amati hasil LOG_ONLY

Saat penelepon membuat tools/call permintaan melalui AgentCore Gateway, gateway mengevaluasi semua kebijakan — termasuk LOG_ONLY kebijakan — sebelum mengembalikan respons MCP ke pemanggil. Respons penelepon tidak pernah terpengaruh oleh LOG_ONLY kebijakan; hasil tersebut dilaporkan hanya melalui observabilitas.

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

Jejak dan bentang: Saat Anda mengaktifkan penelusuran di gateway, rentang evaluasi kebijakan menyertakan LOG_ONLY informasi kecocokan. Anda dapat memeriksa rentang ini di konsol AgentCore Observability untuk melihat LOG_ONLY kebijakan mana yang ditembakkan pada permintaan tertentu dan apakah kebijakan tersebut akan membalik keputusan. Untuk informasi selengkapnya, lihat Mengamati aplikasi agen Anda di Amazon Bedrock AgentCore Observability.

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

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

Untuk informasi selengkapnya tentang melihat metrik untuk AgentCore sumber daya Anda, lihat Data observabilitas yang AgentCore dihasilkan oleh Bedrock.

Mempromosikan kebijakan untuk penegakan

Ketika Anda yakin dengan suatu LOG_ONLY kebijakan, promosikan ke penegakan hukum denganUpdatePolicy, tetapkan 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 untuk mengeluarkannya dari penegakan hukum sambil mempertahankannya dan terus mengamatinya.

Oleh karena itu, siklus hidup yang khas adalah membuat kebijakanLOG_ONLY, mengamati lalu lintas dan metrik, dan kemudian mempromosikannya ke ACTIVE — dan, jika perlu, menurunkannya kembali 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 skor kepercayaan yang menyeimbangkan keamanan terhadap gangguan 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 menurut Anda masuk akal (misalnya, 0,7). Kebijakan mengevaluasi setiap permintaan dan mengeluarkan skor kepercayaan ke CloudWatch metrik, tetapi tidak pernah memblokir lalu lintas.

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

Menganalisis skor terhadap kebenaran dasar. Jika Anda memiliki set pengujian berlabel (prompt ditandai sebagai jinak atau berbahaya), Anda dapat menghitung presisi dan mengingat pada setiap nilai ambang batas dan memilih salah satu yang paling sesuai dengan tujuan Anda. Jika Anda tidak memiliki data berlabel, contoh diminta dari rentang skor tinggi (misalnya, 0,8-1,0), kisaran 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 generik.

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 tersebut 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 Anda dan langkah-langkah promosi yang sesuai daripada mengharapkan peralihan seketika.

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

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