Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Prova una policy in modalità LOG_ONLY

Utilizzando la modalità di applicazione a livello di policy, puoi passare da ACTIVE e LOG_ONLY per rispondere alla domanda: «Cosa farebbe questa policy al mio traffico se venisse applicata?» La LOG_ONLY modalità Per policy consente di testare una policy 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 come risultato di una policy la cui modalità di applicazione è. LOG_ONLY Una volta che ti fidi dei risultati, promuovili aACTIVE.

Come funziona la modalità LOG_ONLY

Ogni policy in un policy engine ha una modalità di applicazione pari a una oACTIVE. LOG_ONLY L'impostazione predefinita è ACTIVE che le policy esistenti e tutte le nuove policy create senza specificare il campo continueranno ad essere applicate come prima. Quando il motore delle policy valuta una richiesta, valuta ACTIVE le tue policy e le tue policy fianco a fianco, ma si applica solo alle tue LOG_ONLY policy. ACTIVE

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

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

Una richiesta viene valutata in due fasi:

ACTIVEe LOG_ONLY sono trattati come due set isolati; una LOG_ONLY policy non può mai cambiare l'esperienza dei chiamanti. La decisione ricevuta da una richiesta non è influenzata da alcuna LOG_ONLY politica.

Oltre a registrare le LOG_ONLY politiche che corrispondono a una richiesta, il motore delle politiche riporta quali di tali politiche avrebbero modificato la decisione se lo fossero stateACTIVE. Questo è 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 delle politiche di ribaltamento delle decisioni. Tuttavia, ogni valutazione delle LOG_ONLY politiche prende in considerazione tutte le politiche attualiACTIVE.

Politiche LOG_ONLY e motori di policy LOG_ONLY

La 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 Policy Engine: controlla il comportamento generale del motore. Se 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 policy engine 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. Quando è 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 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 policy

È 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 un criterio in LOG_ONLY modalità Crea un criterio in LOG_ONLY modalità enforcementMode impostando CreatePolicy su LOG_ONLY nella richiesta. L'esempio seguente crea un guardrail in una policy che vieta i contenuti violenti al di sopra di una soglia di confidenza, ma si limita a rispettarli. Per ulteriori informazioni sui guardrail nelle policy, vedi guardrail nelle policy. Guardrail nelle politiche

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 policy con «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 viene riportato 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 tramite osservabilità.

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

Tracce e intervalli: quando abiliti il tracciamento sul tuo gateway, gli intervalli di valutazione delle policy includono le informazioni sulle corrispondenze. LOG_ONLY Puoi controllare questi intervalli nella console di AgentCore Observability per vedere quali LOG_ONLY policy sono state attivate su una determinata richiesta e se avrebbero ribaltato la decisione. Per ulteriori informazioni, consulta Osservare le applicazioni dei tuoi agenti su Amazon Bedrock Observability. AgentCore

CloudWatch metriche: politica in termini di metriche di AgentCore emissione nel namespace. AWS/Bedrock-AgentCore Le seguenti metriche sono specifiche per la valutazione: LOG_ONLY

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

Per ulteriori informazioni sulla visualizzazione delle metriche per le 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, enforcementMode stabilendoACTIVE. Non sono necessarie altre modifiche e la policy 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

È supportato anche il contrario: è possibile spostare nuovamente una ACTIVE policy in LOG_ONLY per renderla non più applicabile, mantenendola in vigore e continuando a osservarla.

Un ciclo di vita tipico consiste quindi nel creare una policy inLOG_ONLY, osservare il traffico e le metriche, quindi promuoverla e, se necessario, ridurla di livello LOG_ONLY senza eliminare e ricreare la policy. ACTIVE

Scelta di una soglia con la modalità LOG_ONLY

LOG_ONLYla modalità è particolarmente utile per le politiche guardrail, in cui è necessario selezionare una soglia di confidenza che bilanci la sicurezza con le interruzioni 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 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à reale. Se disponi di un set di test etichettato (istruzioni contrassegnate come innocue o dannose), puoi calcolare la precisione e il richiamo per ogni valore di soglia e selezionare quello che meglio soddisfa i tuoi obiettivi. Se non disponi di dati etichettati, campiona i prompt dall'intervallo del punteggio più alto (ad esempio, 0,8—1,0), dall'intervallo del punteggio basso (0—0,2) e dall'ambigua zona centrale (0,4—0,7), quindi classifica ogni campione per aumentare la fiducia nella scelta della soglia. Aggiorna ACTIVE la policy 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 valore predefinito generico.

Considerazioni e limitazioni

LOG_ONLYle politiche non influiscono mai sulle decisioni. Una LOG_ONLY politica non può far sì che un'azione sia autorizzata o negata. 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. Pianificate le finestre di osservazione e le fasi di promozione di conseguenza, anziché aspettarvi un cambio istantaneo.

Gli elenchi dei risultati sono limitati. LOG_ONLYle liste di abbinamento e di ribaltamento decisionale 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 i conteggi aggregati completi.

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