

# Testen Sie eine Richtlinie im LOG\_ONLY-Modus
<a name="policy-test-a-policy"></a>

Im Erzwingungsmodus auf Richtlinienebene können Sie zwischen `ACTIVE` und wechseln, um die Frage `LOG_ONLY` zu beantworten: „Was würde diese Richtlinie für meinen Datenverkehr bedeuten, wenn sie angewendet würde?“ `LOG_ONLY`Im Modus „Pro Richtlinie“ können Sie eine Richtlinie am realen Datenverkehr testen, ohne die Autorisierungsentscheidungen zu beeinflussen. Die Richtlinie bewertet jede Anfrage so, als ob sie durchgesetzt worden wäre, schreibt jedoch nur die Ergebnisse in die Protokolle. Durch eine Richtlinie, deren Erzwingungsmodus aktiviert ist, wird nichts blockiert oder zugelassen. `LOG_ONLY` Wenn Sie den Ergebnissen vertrauen, bewerben Sie sie bei`ACTIVE`.

**Topics**
+ [Wie funktioniert der LOG\_ONLY-Modus](#how-log-only-mode-works)
+ [LOG\_ONLY-Richtlinien und LOG\_ONLY-Policy-Engines](#log-only-policies-and-log-only-policy-engines)
+ [Legen Sie den Durchsetzungsmodus einer Richtlinie fest](#set-the-enforcement-mode-of-a-policy)
+ [Beachten Sie die LOG\_ONLY-Ergebnisse](#observe-log-only-results)
+ [Machen Sie eine Richtlinie zur Durchsetzung bekannt](#promote-a-policy-to-enforcement)
+ [Auswahl eines Schwellenwerts im LOG\_ONLY-Modus](#choosing-a-threshold-with-log-only-mode)
+ [Überlegungen und Einschränkungen](#policy-log-only-considerations-and-limitations)

## Wie funktioniert der LOG\_ONLY-Modus
<a name="how-log-only-mode-works"></a>

Jede Richtlinie in einer Policy-Engine hat den Erzwingungsmodus entweder oder`ACTIVE`. `LOG_ONLY` Die Standardeinstellung ist`ACTIVE`, dass bestehende Richtlinien und alle neuen Richtlinien, die Sie ohne Angabe des Felds erstellen, weiterhin wie zuvor durchgesetzt werden. Wenn die Policy-Engine eine Anfrage bewertet, bewertet sie Ihre `ACTIVE` Richtlinien und Ihre `LOG_ONLY` Richtlinien nebeneinander, setzt aber nur Ihre Richtlinien durch. `ACTIVE`

 `ACTIVE`Richtlinien bestimmen die Entscheidung, die an das AgentCore Gateway zurückgesendet und durchgesetzt wird. Die Policy-Engine wendet die Semantik „Default-Deny“ und „Forbid-Wins“ an, was bedeutet, dass eine Anfrage nur zulässig ist, wenn eine Richtlinie sie zulässt, und ein einzelnes Verbot von jeder aktiven Richtlinie verweigert sie.

 `LOG_ONLY`Richtlinien werden anhand derselben Anfrage bewertet, ihre Ergebnisse werden jedoch getrennt behandelt. Sie werden in Spuren gemeldet und als CloudWatch Amazon-Metriken ausgegeben. Sie werden niemals in der erzwungenen Entscheidung zusammengefasst.


| Durchsetzungsmodus | Bei jeder Anfrage bewertet? | Wirkt sich auf die zurückgegebene Entscheidung aus? | 
| --- | --- | --- | 
|  `ACTIVE` (Standard) | Ja | Ja | 
|  `LOG_ONLY`  | Ja | Nein | 

Eine Anfrage wird in zwei Phasen bewertet:

1. Die Policy-Engine berechnet eine Entscheidung. Nur `ACTIVE` Richtlinien tragen dazu bei. `LOG_ONLY`Politiken werden getrennt bewertet und gemeldet, aber nie berücksichtigt.

1. Wenn die Engine im `ENFORCE` Modus einem Gateway zugeordnet ist, erlaubt oder verweigert das Gateway die Aktion entsprechend der Entscheidung der Policy-Engine. Wenn die Engine im `LOG_ONLY` Modus einem Gateway zugeordnet ist, ergreift das Gateway keine Aktion. Die Entscheidung wird zwar aufgezeichnet, aber nicht durchgesetzt.

 `ACTIVE`und `LOG_ONLY` werden als zwei isolierte Gruppen behandelt. Eine `LOG_ONLY` Richtlinie kann niemals ändern, was Ihre Anrufer erleben. Die Entscheidung, die eine Anfrage erhält, wird durch keine `LOG_ONLY` Richtlinien beeinflusst.

Die Policy-Engine zeichnet nicht nur die `LOG_ONLY` Richtlinien auf, die einer Anfrage entsprachen, sondern meldet auch, welche dieser Richtlinien die Entscheidung geändert hätten, wenn dies der Fall gewesen `ACTIVE` wäre. Dies ist ein wichtiges Signal, das bei der Bewertung der Wirksamkeit und Sicherheit einer Maßnahme (d. h. der Frage, ob sie gefördert werden kann`ACTIVE`) verwendet werden kann. Beispielsweise hätte eine `LOG_ONLY` Richtlinie, die häufig übereinstimmt und in der Auswahlliste erscheint, Ihren Traffic während des Beobachtungsfensters blockiert. Jede `LOG_ONLY` Richtlinie wird unabhängig von allen anderen `LOG_ONLY` Richtlinien bewertet, um zu ermitteln, welche Richtlinien die Entscheidungsfindung beeinflussen. Bei jeder `LOG_ONLY` politischen Bewertung werden jedoch alle aktuellen `ACTIVE` Politiken berücksichtigt.

## LOG\_ONLY-Richtlinien und LOG\_ONLY-Policy-Engines
<a name="log-only-policies-and-log-only-policy-engines"></a>

Policy in AgentCore hat zwei separate Steuerelemente, die beide den Wert LOG\_ONLY verwenden. Sie funktionieren auf verschiedenen Ebenen und beantworten unterschiedliche Fragen. Daher ist es wichtig zu verstehen, welche Sie festlegen.

 **Durchsetzungsmodus der Policy-Engine:** Steuert das allgemeine Verhalten der Engine. Wenn diese Option auf gesetzt ist`LOG_ONLY`, wird keine Richtlinie in der Engine durchgesetzt, unabhängig vom jeweiligen Richtlinienmodus. Alle Entscheidungen werden protokolliert. Dies wird anhand des `mode` Felds festgelegt, `policyEngineConfiguration` wenn Sie einem Gateway mithilfe der `UpdateGateway` Operationen `CreateGateway` oder eine Policy-Engine zuordnen. Die beiden `mode` akzeptierten Werte sind `ENFORCE` (Standard) und`LOG_ONLY`.

Der Richtlinienmodus steuert das Verhalten einer einzelnen Richtlinie innerhalb einer Enforcement-Engine. Wenn diese Richtlinie auf LOG\_ONLY gesetzt ist, wird sie trotzdem ausgewertet, aber ihre Entscheidung wird protokolliert und nicht durchgesetzt. Alle anderen `ACTIVE` Richtlinien in der Engine werden weiterhin normal durchgesetzt. Die beiden `enforcementMode` akzeptierten Werte sind `ACTIVE` (Standard) und`LOG_ONLY`.

Verwenden Sie LOG\_ONLY auf Richtlinienebene, um eine neue Leitplanke in der Produktion im Schatten zu testen, ohne den Traffic zu beeinträchtigen. Verwenden Sie LOG\_ONLY auf Engine-Ebene, um das Verhalten aller Richtlinien zu beobachten, bevor Sie die Durchsetzung aktivieren.


<table>
<tbody>
  <tr><td rowspan="2" colspan="2"></td><td colspan="2"> **Modus zur Durchsetzung von Richtlinien** </td></tr>
  <tr><td> `ACTIVE` </td><td> `LOG_ONLY` </td></tr>
  <tr><td rowspan="2"> **Modus zur Durchsetzung der Policy-Engine** </td><td> `ENFORCE` </td><td>Evaluiert und durchgesetzt. Kann Anfragen blockieren oder ändern.</td><td>Ausgewertet, aber nicht durchgesetzt. Die Entscheidung wird nur protokolliert. Andere `ACTIVE` Richtlinien in der Engine gelten weiterhin.</td></tr>
  <tr><td> `LOG_ONLY` </td><td>Ausgewertet, aber nicht durchgesetzt. Die Entscheidung wird nur protokolliert.</td><td>Ausgewertet, aber nicht durchgesetzt. Die Entscheidung wird nur protokolliert.</td></tr>
</tbody>
</table>


**Anmerkung**  
Der Durchsetzungsmodus der Policy-Engine hat Vorrang. Wenn eine Policy-Engine im Modus LOG\_ONLY verknüpft ist, kann keine Richtlinie eine Gateway-Aktion verweigern — nicht einmal eine Richtlinie im `ACTIVE` Erzwingungsmodus —, weil das Gateway die Entscheidung der Policy-Engine überhaupt nicht befolgt. Die Engine berechnet immer noch die Entscheidung und Sie erhalten weiterhin `LOG_ONLY` Telemetriedaten. Die Entscheidung wird einfach nicht durchgesetzt.

## Legen Sie den Durchsetzungsmodus einer Richtlinie fest
<a name="set-the-enforcement-mode-of-a-policy"></a>

Sie können das `enforcementMode` Feld für eine Richtlinie festlegen, wenn Sie die Richtlinie erstellen oder aktualisieren (d. h., `CreatePolicy` und`UpdatePolicy`), und es wird mit `GetPolicy` und zurückgegeben`ListPolicies`.

 **Erstellen Sie eine Richtlinie im `LOG_ONLY` Modus** Erstellen Sie eine Richtlinie im `LOG_ONLY` Modus, indem Sie `LOG_ONLY` in der `CreatePolicy` Anfrage `enforcementMode` auf festlegen. Im folgenden Beispiel wird eine Leitplanke in einer Richtlinie erstellt, die gewalttätige Inhalte, die einen Vertrauensschwellenwert überschreiten, verbietet, diesen aber nur einhält. [Weitere Informationen zu Leitplanken in Richtlinien finden Sie unter Leitplanken in Richtlinien.](policy-guardrails-in-policies.md)

```
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\")) };"}}'
```

Die Antwort entspricht der Richtlinie mit „EnforcementMode“: „LOG\_ONLY“. Die Richtlinie beginnt mit der Auswertung anhand des Datenverkehrs, und ab diesem Zeitpunkt werden die Treffer in Traces und CloudWatch Metriken angezeigt — ohne dass sich dies auf eine Entscheidung auswirkt.

 **Führen Sie die Richtlinien und ihre Durchsetzungsmodalitäten auf** 

ListPolicies wird `enforcementMode` in jeder Richtlinienübersicht aufgeführt, sodass Sie auf einen Blick sehen können, welche Richtlinien eingehalten und welche durchgesetzt werden.

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

 **Antwort** 

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

## Beachten Sie die LOG\_ONLY-Ergebnisse
<a name="observe-log-only-results"></a>

Wenn ein Anrufer eine tools/call Anfrage über das Gateway stellt, bewertet das AgentCore Gateway alle Richtlinien — einschließlich der Richtlinien —, bevor es `LOG_ONLY` die MCP-Antwort an den Anrufer zurücksendet. Die Antwort des Anrufers wird niemals durch `LOG_ONLY` Richtlinien beeinflusst. Diese Ergebnisse werden nur im Rahmen von Observability gemeldet.

Sie beobachten das Verhalten von `LOG_ONLY` Richtlinien anhand von Traces und CloudWatch Amazon-Metriken:

 **Traces und Spans:** Wenn Sie Tracing auf Ihrem Gateway aktivieren, enthalten `LOG_ONLY` die Bewertungsintervalle der Richtlinien Übereinstimmungsinformationen. Sie können diese Zeitspannen in der AgentCore Observability-Konsole überprüfen, um zu sehen, welche `LOG_ONLY` Richtlinien bei einer bestimmten Anfrage ausgelöst wurden und ob sie die Entscheidung umgedreht hätten. Weitere Informationen finden Sie unter [Beobachte deine Agentenanwendungen auf Amazon Bedrock AgentCore Observability](observability.md).

 **CloudWatch Metriken:** Die Richtlinie in AgentCore gibt Metriken unter dem Namespace aus. AWS/Bedrock-AgentCore Die folgenden Metriken sind bewertungsspezifisch`LOG_ONLY`:


| Metrik | Was es dir sagt | 
| --- | --- | 
|  `ConfidenceScore`(mit PolicyEnforcementMode =`LOG_ONLY`) | Der Vertrauenswert, den die Leitplanke für eine entsprechende Police zurückgegeben hat. `LOG_ONLY` Verwenden Sie diesen Wert, um die Punkteverteilung Ihres Traffics bei der Auswahl eines Schwellenwerts zu verstehen. | 
|  `ConfidenceThreshold` (mit `PolicyEnforcementMode=LOG_ONLY`) | Der in der `LOG_ONLY` Richtlinie konfigurierte Schwellenwert. Nützlich beim Vergleich der Punktzahl mit dem Schwellenwert verschiedener Richtlinien. | 
|  `LogOnlyMatches`  | Die Anzahl der Anfragen, bei denen eine `LOG_ONLY` Richtlinie ausgelöst wurde. Wird pro Richtlinie und als Gruppen-Rollup `LOG_ONLY` für alle Richtlinien auf der Engine ausgegeben. | 
|  `LogOnlyDecisionFlips`  | Die Anzahl der Anfragen, bei denen eine `LOG_ONLY` Richtlinie die Entscheidung geändert hätte, wenn sie befördert worden wäre. Dies ist das wichtigste Werbesignal: Eine anhaltende Null bedeutet, dass die Förderung der Richtlinie den aktuellen Verkehr nicht blockiert. | 
|  `LogOnlyEvalIncomplete`  | Wird ausgegeben, wenn die `LOG_ONLY` Bewertung unvollständig war. Verwenden Sie diese Option, um auf eine anhaltende Anzahl unvollständiger Bewertungen aufmerksam zu machen. | 

Alle Metriken enthalten PolicyEngine auch OperationName Dimensionen für die Filterung. Per-policy Metriken enthalten zusätzlich eine Policy-Dimension mit der Policy-ID.

Weitere Informationen zum Anzeigen von Metriken für Ihre AgentCore Ressourcen finden Sie unter Von [Bedrock AgentCore generierte Observabilitätsdaten](observability.md).

## Machen Sie eine Richtlinie zur Durchsetzung bekannt
<a name="promote-a-policy-to-enforcement"></a>

Wenn Sie von einer `LOG_ONLY` Richtlinie überzeugt sind, machen Sie sie mit`UpdatePolicy`, indem Sie sie `enforcementMode` durchsetzen`ACTIVE`. Es sind keine weiteren Änderungen erforderlich, und die Richtlinie behält ihre ID, ihren Namen und ihre Definition.

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

Auch der umgekehrte Weg wird unterstützt: Sie können eine `ACTIVE` Richtlinie zurückverschieben, `LOG_ONLY` um sie außer Kraft zu setzen und sie gleichzeitig beizubehalten und einzuhalten.

Ein typischer Lebenszyklus besteht daher darin, eine Richtlinie zu erstellen`LOG_ONLY`, den Traffic und die Kennzahlen zu beobachten und sie dann hochzustufen `ACTIVE` — und sie bei Bedarf wieder herabzustufen, `LOG_ONLY` ohne die Richtlinie zu löschen und neu zu erstellen.

## Auswahl eines Schwellenwerts im LOG\_ONLY-Modus
<a name="choosing-a-threshold-with-log-only-mode"></a>

 `LOG_ONLY`Der Modus ist besonders nützlich für Guardrail-Richtlinien, bei denen Sie einen Schwellenwert für die Vertrauensbewertung auswählen müssen, der ein ausgewogenes Verhältnis zwischen Sicherheit und Unterbrechung des legitimen Datenverkehrs gewährleistet. Ein zu niedriger Schwellenwert blockiert legitime Anfragen; ein zu hoher Schwellenwert kann Bedrohungen durchlassen.

 **Der empfohlene Arbeitsablauf:** Stellen Sie die Leitplanke im `LOG_ONLY` Modus mit einem Schwellenwert bereit, den Sie für angemessen halten (z. B. 0,7). Die Richtlinie bewertet jede Anfrage und gibt einen Vertrauenswert für CloudWatch Metriken aus, blockiert jedoch niemals den Datenverkehr.

Sammeln Sie Daten über ein repräsentatives Zeitfenster — Tage oder Wochen echten Produktionsdatenverkehrs. Die ConfidenceScore Metrik (mit PolicyEnforcementMode =LOG\_ONLY) gibt Ihnen die Verteilung der Ergebnisse an, die Ihr Traffic generiert.

Analysieren Sie die Ergebnisse anhand von Ground Truth. Wenn Sie über einen Testsatz verfügen (Eingabeaufforderungen, die als harmlos oder bösartig gekennzeichnet sind), können Sie die Genauigkeit und den Erinnerungswert für jeden Schwellenwert berechnen und dann den auswählen, der Ihren Zielen am besten entspricht. Wenn Sie keine beschrifteten Daten haben, nehmen Sie Stichproben aus dem Bereich mit hohem Punktewert (z. B. 0,8—1,0), dem Bereich mit niedrigen Werten (0—0,2) und dem mehrdeutigen mittleren Bereich (0,4—0,7). Klassifizieren Sie dann jede Stichprobe, um Vertrauen in Ihre Schwellenwertauswahl zu gewinnen. Aktualisieren Sie die Richtlinie mit dem von Ihnen ausgewählten Schwellenwert und erhöhen Sie sie auf: `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\")) };"}}'
```

Dieser Workflow stellt sicher, dass der Schwellenwert Ihren tatsächlichen Verkehrsmustern entspricht und nicht einem generischen Standard entspricht.

## Überlegungen und Einschränkungen
<a name="policy-log-only-considerations-and-limitations"></a>

 `LOG_ONLY`Richtlinien wirken sich niemals auf Entscheidungen aus. Eine `LOG_ONLY` Richtlinie kann nicht dazu führen, dass eine Aktion zugelassen oder verweigert wird. Die Entscheidung, die eine Anfrage erhält, ist identisch mit der Entscheidung, die sie erhalten würde, wenn die `LOG_ONLY` Richtlinie nicht existieren würde. Dies ist die Kerngarantie der Funktion.

Die Änderungen sind letztendlich konsistent. Das Erstellen, Aktualisieren oder Heraufstufen einer Richtlinie wird innerhalb weniger Sekunden auf den Evaluierungspfad angewendet. Planen Sie Ihre Beobachtungsfenster und Beförderungsschritte entsprechend, anstatt mit einem sofortigen Wechsel zu rechnen.

Die Ergebnislisten sind begrenzt. `LOG_ONLY`Match- und Decision-Flipping-Listen sind jeweils auf 1.000 Einträge pro Anfrage begrenzt. Bei Engines mit einer sehr großen Anzahl von `LOG_ONLY` Richtlinien sollten Sie sich für die vollständige Gesamtzahl der Policen auf die CloudWatch Metriken verlassen.

Die Bewertung kann teilweise erfolgen. Wenn die `LOG_ONLY` Auswertung für eine Anfrage unvollständig ist, fehlen in den `LOG_ONLY` Signalen für diese Anfrage möglicherweise Einträge. Die erzwungene Entscheidung bleibt davon unberührt.