# Uji kebijakan dalam mode LOG\_ONLY
<a name="policy-test-a-policy"></a>

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_ONLY`Mode 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 penegakannya`LOG_ONLY`. Setelah Anda mempercayai hasilnya, promosikan ke`ACTIVE`.

**Topics**
+ [Cara kerja mode LOG\_ONLY](#how-log-only-mode-works)
+ [Kebijakan LOG\_ONLY dan mesin kebijakan LOG\_ONLY](#log-only-policies-and-log-only-policy-engines)
+ [Mengatur mode penegakan kebijakan](#set-the-enforcement-mode-of-a-policy)
+ [Amati hasil LOG\_ONLY](#observe-log-only-results)
+ [Mempromosikan kebijakan untuk penegakan](#promote-a-policy-to-enforcement)
+ [Memilih ambang batas dengan mode LOG\_ONLY](#choosing-a-threshold-with-log-only-mode)
+ [Pertimbangan dan batasan](#policy-log-only-considerations-and-limitations)

## Cara kerja mode LOG\_ONLY
<a name="how-log-only-mode-works"></a>

Setiap kebijakan dalam mesin kebijakan memiliki mode penegakan salah satu `ACTIVE` atau`LOG_ONLY`. Defaultnya adalah`ACTIVE`, 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`

 `ACTIVE`kebijakan 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_ONLY`Kebijakan 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.


| Mode Penegakan | Dievaluasi pada setiap permintaan? | Mempengaruhi keputusan yang dikembalikan? | 
| --- | --- | --- | 
|  `ACTIVE` (default) | Ya | Ya | 
|  `LOG_ONLY`  | Ya | Tidak | 

Permintaan dievaluasi dalam dua tahap:

1. Mesin kebijakan menghitung keputusan. Hanya `ACTIVE` kebijakan yang berkontribusi padanya. `LOG_ONLY`Kebijakan dievaluasi dan dilaporkan secara terpisah, tetapi tidak pernah diperhitungkan.

1. Jika mesin dikaitkan dengan gateway dalam `ENFORCE` mode, Gateway mengizinkan atau menolak tindakan sesuai dengan keputusan mesin kebijakan. Jika mesin dikaitkan dengan gateway dalam `LOG_ONLY` mode, Gateway tidak mengambil tindakan; keputusan dicatat tetapi tidak diberlakukan.

 `ACTIVE`dan `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
<a name="log-only-policies-and-log-only-policy-engines"></a>

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 ke`LOG_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) dan`LOG_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) dan`LOG_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.


<table>
<tbody>
  <tr><td rowspan="2" colspan="2"></td><td colspan="2"> <b>Mode Penegakan Kebijakan</b> </td></tr>
  <tr><td> <code>ACTIVE</code> </td><td> <code>LOG_ONLY</code> </td></tr>
  <tr><td rowspan="2"> <b>Mode Penegakan Mesin Kebijakan</b> </td><td> <code>ENFORCE</code> </td><td>Dievaluasi dan ditegakkan. Dapat memblokir atau memodifikasi permintaan.</td><td>Dievaluasi tetapi tidak ditegakkan. Keputusan hanya dicatat; <code>ACTIVE</code> kebijakan lain di mesin masih berlaku.</td></tr>
  <tr><td> <code>LOG_ONLY</code> </td><td>Dievaluasi tetapi tidak ditegakkan. Keputusan hanya dicatat.</td><td>Dievaluasi tetapi tidak ditegakkan. Keputusan hanya dicatat.</td></tr>
</tbody>
</table>


**catatan**  
Mode penegakan mesin kebijakan diutamakan. Ketika mesin kebijakan dikaitkan dalam mode LOG\_ONLY, tidak ada kebijakan yang dapat menolak tindakan Gateway — bahkan kebijakan dalam mode `ACTIVE` penegakan — karena Gateway sama sekali tidak bertindak atas keputusan mesin kebijakan. Mesin masih menghitung keputusan dan Anda masih menerima `LOG_ONLY` telemetri; keputusan sama sekali tidak ditegakkan.

## Mengatur mode penegakan kebijakan
<a name="set-the-enforcement-mode-of-a-policy"></a>

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

 **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](policy-guardrails-in-policies.md) 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
<a name="observe-log-only-results"></a>

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](observability.md).

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


| Metrik | Apa yang dikatakannya | 
| --- | --- | 
|  `ConfidenceScore`(dengan PolicyEnforcementMode =`LOG_ONLY`) | Skor kepercayaan pagar pembatas dikembalikan untuk kebijakan yang cocok`LOG_ONLY`. Gunakan ini untuk memahami distribusi skor lalu lintas Anda saat memilih ambang batas. | 
|  `ConfidenceThreshold` (dengan `PolicyEnforcementMode=LOG_ONLY`) | Ambang batas yang dikonfigurasi pada `LOG_ONLY` kebijakan. Berguna saat membandingkan skor terhadap ambang batas di seluruh kebijakan. | 
|  `LogOnlyMatches`  | Hitungan permintaan di mana `LOG_ONLY` kebijakan dipecat. Dipancarkan per kebijakan dan sebagai rollup grup di semua `LOG_ONLY` kebijakan di mesin. | 
|  `LogOnlyDecisionFlips`  | Hitungan permintaan di mana `LOG_ONLY` kebijakan akan mengubah keputusan jika dipromosikan. Ini adalah sinyal promosi utama: nol berkelanjutan berarti mempromosikan kebijakan tidak akan memblokir lalu lintas saat ini. | 
|  `LogOnlyEvalIncomplete`  | Dipancarkan ketika `LOG_ONLY` evaluasi sebagian. Gunakan ini untuk alarm pada tingkat berkelanjutan dari evaluasi yang tidak lengkap. | 

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](observability.md).

## Mempromosikan kebijakan untuk penegakan
<a name="promote-a-policy-to-enforcement"></a>

Ketika Anda yakin dengan suatu `LOG_ONLY` kebijakan, promosikan ke penegakan hukum dengan`UpdatePolicy`, tetapkan `enforcementMode` ke`ACTIVE`. 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 kebijakan`LOG_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
<a name="choosing-a-threshold-with-log-only-mode"></a>

 `LOG_ONLY`mode 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 ke`ACTIVE`:

```
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
<a name="policy-log-only-considerations-and-limitations"></a>

 `LOG_ONLY`Kebijakan tidak pernah mempengaruhi keputusan. `LOG_ONLY`Kebijakan 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_ONLY`daftar 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.