Verifica una politica in modalità LOG_ONLY

Utilizzando la modalità di applicazione a livello di policy, puoi passare da una all'altra ACTIVE e rispondere LOG_ONLY alla domanda: «Che effetto avrebbe questa policy sul mio traffico se venisse applicata?» La LOG_ONLY modalità per policy ti consente di testare una politica sul traffico reale senza influire sulle decisioni di autorizzazione. La policy valuta ogni richiesta come se fosse applicata, ma scrive solo i risultati nei log. Nulla è bloccato o consentito a seguito di una politica la cui modalità di applicazione è. LOG_ONLY Una volta che ti fidi dei risultati, promuovili aACTIVE.

Come funziona la modalità LOG_ONLY

Ogni politica in un motore di policy ha una modalità di applicazione pari a oACTIVE. LOG_ONLY L'impostazione predefinita è ACTIVE che le politiche esistenti e qualsiasi nuova politica creata senza specificare il campo continueranno ad essere applicate come prima. Quando il motore delle politiche valuta una richiesta, valuta ACTIVE le politiche e le LOG_ONLY politiche in modo parallelo, ma applica solo le politiche stesse. ACTIVE

ACTIVEle politiche determinano la decisione che viene restituita al AgentCore Gateway e applicata. Il motore delle politiche applica le semantiche «default-deny» e «bann-wins», il che significa che una richiesta è consentita solo se una policy lo consente e un unico divieto proveniente da qualsiasi policy attiva la nega.

LOG_ONLYle politiche vengono valutate sulla base della stessa richiesta, ma i loro risultati vengono mantenuti separati. Vengono riportati in tracce ed emessi come CloudWatch metriche Amazon. Non vengono mai combinati nella decisione applicata.

Una richiesta viene valutata in due fasi:

ACTIVEe LOG_ONLY vengono trattati come due insiemi isolati; una LOG_ONLY policy non può mai cambiare l'esperienza di chi chiama. La decisione ricevuta da una richiesta non è influenzata da alcuna LOG_ONLY politica.

Oltre a registrare le LOG_ONLY politiche corrispondenti a una richiesta, il motore delle politiche riporta quali di tali politiche avrebbero modificato la decisione se lo fossero state. ACTIVE Si tratta di un segnale chiave da utilizzare per valutare l'efficacia e la sicurezza di una politica (ad esempio, se può essere promossa aACTIVE). Ad esempio, una LOG_ONLY politica che corrisponde frequentemente e compare nel set decisionale avrebbe bloccato il traffico durante la finestra di osservazione. Ogni LOG_ONLY politica viene valutata indipendentemente da tutte le altre LOG_ONLY politiche per determinare l'insieme di politiche che determinano l'adozione di decisioni. Tuttavia, ogni valutazione delle LOG_ONLY politiche prende in considerazione tutte le politiche attuali. ACTIVE

Politiche LOG_ONLY e motori di policy LOG_ONLY

Policy in AgentCore ha due controlli separati che utilizzano entrambi il valore LOG_ONLY. Funzionano a livelli diversi e rispondono a domande diverse, quindi è importante capire quale si sta impostando.

Modalità di applicazione del motore delle politiche: controlla il comportamento generale del motore. Quando è impostata suLOG_ONLY, non viene applicata alcuna policy nel motore, indipendentemente dalla modalità di policy individuale. Tutte le decisioni vengono registrate. Questo viene impostato utilizzando il mode campo di policyEngineConfiguration quando si associa un motore di policy a un gateway utilizzando le UpdateGateway operazioni CreateGateway or. I due valori mode accettati sono ENFORCE (impostazione predefinita) eLOG_ONLY.

La modalità policy controlla il comportamento di una singola policy all'interno di un motore di applicazione. Se impostata su LOG_ONLY, tale policy viene comunque valutata, ma la sua decisione viene registrata anziché applicata. Tutte le altre ACTIVE politiche del motore continuano a essere applicate normalmente. I due valori enforcementMode accettati sono ACTIVE (impostazione predefinita) eLOG_ONLY.

Utilizzate LOG_ONLY a livello di policy per testare in modalità shadow-test un nuovo guardrail in produzione senza influire sul traffico. Utilizzate LOG_ONLY a livello di motore per osservare il comportamento di tutte le policy prima di abilitarne l'applicazione.

Imposta la modalità di applicazione di una politica

È possibile impostare il enforcementMode campo su una politica quando si crea o si aggiorna la politica (ad esempio, CreatePolicy eUpdatePolicy) e viene restituito da GetPolicy eListPolicies.

Crea una politica in LOG_ONLY modalità Crea una politica in LOG_ONLY modalità enforcementMode impostando CreatePolicy su LOG_ONLY nella richiesta. L'esempio seguente crea un guardrail nelle policy che proibisce i contenuti violenti al di sopra di una soglia di confidenza, ma si limita a rispettarli. Per ulteriori informazioni sui guardrails nelle policy, consulta guardrails in policies.

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

La risposta fa eco alla politica di «EnforcementMode»: «LOG_ONLY». La policy inizia a valutare in base al traffico e da quel momento le corrispondenze vengono visualizzate in tracce e metriche, senza influire su alcuna decisione. CloudWatch

Elenca le politiche e le relative modalità di applicazione

ListPolicies i risultati sono riportati enforcementMode in ogni riepilogo delle politiche, in modo da poter vedere a colpo d'occhio quali politiche vengono rispettate e quali vengono applicate.

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

risposta

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

Osserva i risultati LOG_ONLY

Quando un chiamante effettua una tools/call richiesta tramite il AgentCore gateway, il gateway valuta tutte le politiche, incluse le politiche, prima LOG_ONLY di restituire la risposta MCP al chiamante. La risposta del chiamante non è mai influenzata dalle LOG_ONLY politiche; tali risultati vengono riportati solo attraverso l'osservabilità.

Osservi il comportamento LOG_ONLY delle policy attraverso trace e CloudWatch metriche Amazon:

Tracce e intervalli: quando abiliti il tracciamento sul gateway, gli intervalli di valutazione delle policy includono le informazioni sulle corrispondenze. LOG_ONLY Puoi esaminare questi intervalli nella console AgentCore Observability per vedere quali LOG_ONLY politiche sono state attivate su una determinata richiesta e se avrebbero invertito la decisione. Per ulteriori informazioni, consulta Osserva le tue applicazioni agente su Amazon Bedrock AgentCore Observability.

CloudWatch metriche: Policy in AgentCore emette metriche nel namespace. AWS/Bedrock-AgentCore Le seguenti metriche sono specifiche per la valutazione: LOG_ONLY

Tutte le metriche includono le OperationName dimensioni per PolicyEngine il filtraggio. Per-policy le metriche includono inoltre una dimensione Policy con l'ID della policy.

Per ulteriori informazioni sulla visualizzazione delle metriche per le tue AgentCore risorse, consulta i dati di osservabilità AgentCore generati da Bedrock.

Promuovi una politica di applicazione

Quando hai fiducia in una LOG_ONLY politica, promuovila fino all'applicazione conUpdatePolicy, setting enforcementMode toACTIVE. Non sono necessarie altre modifiche e la politica mantiene l'ID, il nome e la definizione.

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

È supportata anche l'ipotesi inversa: è possibile LOG_ONLY riportare una ACTIVE politica in modo da renderla inapplicabile mantenendola in vigore e continuando a rispettarla.

Un tipico ciclo di vita consiste quindi nel creare una politicaLOG_ONLY, osservare il traffico e le metriche, quindi promuoverla e, se necessario, ridurla di livello LOG_ONLY senza eliminarla e ricrearla. ACTIVE

Scelta di una soglia con la modalità LOG_ONLY

LOG_ONLYla modalità è particolarmente utile per le politiche di guardrail, in cui è necessario selezionare una soglia di punteggio di fiducia che bilanci la sicurezza dall'interruzione del traffico legittimo. Una soglia troppo bassa blocca le richieste legittime; una soglia troppo alta può far passare le minacce.

Il flusso di lavoro consigliato: implementa il guardrail in LOG_ONLY modalità con una soglia che ritieni ragionevole (ad esempio 0,7). La policy valuta ogni richiesta e assegna un punteggio di affidabilità alle CloudWatch metriche, ma non blocca mai il traffico.

Accumula i dati in una finestra rappresentativa: giorni o settimane di traffico di produzione reale. La ConfidenceScore metrica (con PolicyEnforcementMode =LOG_ONLY) fornisce la distribuzione dei punteggi prodotti dal traffico.

Analizza i punteggi confrontandoli con la realtà. Se disponi di un set di test etichettato (istruzioni contrassegnate come benigne o dannose), puoi calcolare con precisione e richiamare ogni valore di soglia e selezionare quello che meglio soddisfa i tuoi obiettivi. Se non disponi di dati etichettati, campiona i prompt dell'intervallo con il punteggio più alto (ad esempio 0,8—1,0), dell'intervallo con il punteggio più basso (0-0,2) e della zona centrale ambigua (0,4-0,7), quindi classifica ogni campione per aumentare la fiducia nella scelta della soglia. Aggiorna ACTIVE la politica con la soglia prescelta e promuovila a:

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

Questo flusso di lavoro garantisce che la soglia rifletta i modelli di traffico effettivi anziché un'impostazione predefinita generica.

Considerazioni e limitazioni

LOG_ONLYle politiche non influiscono mai sulle decisioni. Una LOG_ONLY politica non può consentire o negare un'azione. La decisione ricevuta da una richiesta è identica alla decisione che riceverebbe se la LOG_ONLY politica non esistesse. Questa è la garanzia principale della funzionalità.

Le modifiche alla fine sono coerenti. La creazione, l'aggiornamento o la promozione di una politica vengono applicati al percorso di valutazione in pochi secondi. Pianifica le finestre di osservazione e le fasi di promozione di conseguenza anziché aspettarti un cambiamento istantaneo.

Gli elenchi dei risultati sono limitati. LOG_ONLYle liste degli abbinamenti e delle decisioni sono limitate ciascuna a 1.000 voci per richiesta. Per i motori con un numero molto elevato di LOG_ONLY policy, affidati alle CloudWatch metriche per conteggi aggregati completi.

La valutazione può essere parziale. Quando LOG_ONLY la valutazione di una richiesta è incompleta, nei LOG_ONLY segnali relativi a tale richiesta potrebbero mancare delle voci. La decisione applicata non viene mai influenzata.