Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Tester une politique en mode LOG_ONLY

À l'aide du mode d'application au niveau des règles, vous pouvez basculer entre l'un ACTIVE et l'autre et répondre LOG_ONLY à la question suivante : « Quels seraient les effets de cette politique sur mon trafic si elle était appliquée ? » LOG_ONLYLe mode Par politique vous permet de tester une politique sur le trafic réel sans affecter les décisions d'autorisation. La politique évalue chaque demande comme si elle était appliquée, mais enregistre uniquement les résultats dans les journaux. Rien n'est bloqué ou autorisé en raison d'une politique dont le mode d'application est le mode d'applicationLOG_ONLY. Une fois que vous avez confiance dans les résultats, faites-en la promotionACTIVE.

Comment fonctionne le mode LOG_ONLY

Chaque politique d'un moteur de politiques possède un mode d'application de l'un ACTIVE ou l'autreLOG_ONLY. Par défautACTIVE, les politiques existantes et toute nouvelle stratégie que vous créez sans spécifier le champ continuent de s'appliquer comme auparavant. Lorsque le moteur de politiques évalue une demande, il évalue vos ACTIVE politiques et vos LOG_ONLY politiques côte à côte, mais ne les applique qu'à vos politiques. ACTIVE

ACTIVEles politiques déterminent la décision qui est renvoyée à la AgentCore passerelle et appliquée. Le moteur de politique applique les sémantiques « default-deny » et « forbid-wins », ce qui signifie qu'une demande n'est autorisée que si une politique l'autorise, et qu'une seule interdiction parmi toutes les politiques actives la refuse.

LOG_ONLYles politiques sont évaluées par rapport à la même demande, mais leurs résultats sont conservés séparément. Ils sont signalés sous forme de traces et émis sous forme de CloudWatch métriques Amazon. Ils ne sont jamais combinés dans la décision exécutoire.

L'évaluation d'une demande se fait en deux étapes :

ACTIVEet LOG_ONLY sont traités comme deux ensembles isolés ; une LOG_ONLY politique ne peut jamais modifier l'expérience de vos appelants. La décision reçue par une demande n'est affectée par aucune LOG_ONLY politique.

En plus d'enregistrer les LOG_ONLY politiques qui correspondaient à une demande, le moteur de politiques indique lesquelles de ces politiques auraient modifié la décision si elles l'avaient étéACTIVE. Il s'agit d'un signal clé à utiliser pour évaluer l'efficacité et la sécurité d'une politique (c'est-à-dire pour savoir si elle peut être promueACTIVE). Par exemple, une LOG_ONLY politique qui correspond fréquemment et qui apparaît dans le jeu d'inversion des décisions aurait bloqué votre trafic pendant la fenêtre d'observation. Chaque LOG_ONLY politique est évaluée indépendamment de toutes les autres LOG_ONLY politiques afin de déterminer l'ensemble des politiques d'inversion des décisions. Cependant, chaque évaluation LOG_ONLY des politiques prend en compte toutes les ACTIVE politiques actuelles.

Politiques LOG_ONLY et moteurs de politiques LOG_ONLY

Policy in AgentCore possède deux contrôles distincts qui utilisent tous deux la valeur LOG_ONLY. Ils fonctionnent à différents niveaux et répondent à différentes questions. Il est donc important de comprendre laquelle vous définissez.

Mode d'application du moteur de politiques : contrôle le comportement général du moteur. Lorsque cette option est définie surLOG_ONLY, aucune politique du moteur n'est appliquée, quel que soit son mode de politique individuel. Toutes les décisions sont enregistrées. Ceci est défini à l'aide du mode champ policyEngineConfiguration lorsque vous associez un moteur de politiques à une passerelle à l'aide UpdateGateway des opérations CreateGateway ou. Les deux valeurs mode acceptées sont ENFORCE (par défaut) etLOG_ONLY.

Le mode Stratégie contrôle le comportement d'une politique unique au sein d'un moteur d'application. Lorsqu'elle est définie sur LOG_ONLY, cette politique est toujours évaluée, mais sa décision est enregistrée au lieu d'être appliquée. Toutes les autres ACTIVE politiques du moteur continuent de s'appliquer normalement. Les deux valeurs enforcementMode acceptées sont ACTIVE (par défaut) etLOG_ONLY.

Utilisez LOG_ONLY au niveau de la politique pour tester en mode parallèle un nouveau garde-corps en production sans affecter le trafic. Utilisez LOG_ONLY au niveau du moteur pour observer le comportement de toutes les politiques avant d'activer leur application.

Définir le mode d'application d'une politique

Vous pouvez définir le enforcementMode champ sur une politique lorsque vous créez ou mettez à jour la politique (c'est-à-dire CreatePolicy etUpdatePolicy), et il est renvoyé par GetPolicy etListPolicies.

Créer une politique en LOG_ONLY mode Créez une stratégie en LOG_ONLY mode en définissant enforcementMode sur LOG_ONLY dans la CreatePolicy demande. L'exemple suivant crée une règle de sécurité qui interdit les contenus violents dépassant un seuil de confiance, mais se contente de le respecter. Pour plus d'informations sur les garde-corps dans les politiques, voir les garde-corps dans les politiques.

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 réponse fait écho à la politique avec « EnforcementMode » : « LOG_ONLY ». La politique commence à être évaluée par rapport au trafic et, à partir de ce moment, ses correspondances apparaissent dans les traces et CloudWatch les mesures, sans affecter aucune décision.

Répertorier les politiques et leurs modes d'application

ListPolicies apparaît enforcementMode dans le résumé de chaque politique, afin que vous puissiez voir en un coup d'œil quelles politiques sont respectées et lesquelles sont appliquées.

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

réponse

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

Observez les résultats de LOG_ONLY

Lorsqu'un appelant fait une tools/call demande via la AgentCore passerelle, celle-ci évalue toutes les politiques, y compris LOG_ONLY les politiques, avant de renvoyer la réponse MCP à l'appelant. La réponse de l'appelant n'est jamais affectée par les LOG_ONLY politiques ; ces résultats sont communiqués uniquement par le biais de l'observabilité.

Vous observez le comportement des LOG_ONLY politiques grâce à des traces et à CloudWatch des métriques Amazon :

Traces et étendues : lorsque vous activez le suivi sur votre passerelle, les périodes d'évaluation des politiques incluent des informations de LOG_ONLY correspondance. Vous pouvez inspecter ces intervalles dans la console AgentCore Observability pour voir quelles LOG_ONLY politiques ont été déclenchées sur une demande donnée et si elles auraient inversé la décision. Pour plus d'informations, consultez la section Observez vos applications d'agent sur Amazon Bedrock AgentCore Observability.

CloudWatch metrics : la politique AgentCore émet des métriques sous l'espace de AWS/Bedrock-AgentCore noms. Les indicateurs suivants sont spécifiques à LOG_ONLY l'évaluation :

Toutes les mesures incluent PolicyEngine le filtrage et OperationName ses dimensions. Per-policy les métriques incluent également une dimension de stratégie avec l'ID de stratégie.

Pour plus d'informations sur l'affichage des statistiques de vos AgentCore ressources, consultez la section Données d'observabilité AgentCore générées par Bedrock.

Promouvoir une politique en vue de son application

Lorsque vous avez confiance en une LOG_ONLY politique, faites-en la promotion jusqu'à ce qu'elle soit appliquée avecUpdatePolicy, en réglant enforcementMode surACTIVE. Aucune autre modification n'est requise et la politique conserve son identifiant, son nom et sa définition.

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

L'inverse est également possible : vous pouvez revenir à une ACTIVE politique LOG_ONLY pour la retirer de son application tout en la maintenant en place et en continuant à la respecter.

Un cycle de vie typique consiste donc à créer une politiqueLOG_ONLY, à observer le trafic et les indicateurs, puis à ACTIVE la promouvoir et, si nécessaire, à la rétrograder LOG_ONLY sans supprimer ni recréer la politique.

Choix d'un seuil avec le mode LOG_ONLY

LOG_ONLYle mode est particulièrement utile pour les politiques de garde-corps, où vous devez sélectionner un seuil de confiance qui équilibre la sécurité et la perturbation du trafic légitime. Un seuil trop bas bloque les demandes légitimes ; un seuil trop élevé peut laisser passer les menaces.

Le flux de travail recommandé : Déployez le garde-corps en LOG_ONLY mode avec un seuil que vous jugez raisonnable (par exemple, 0,7). La politique évalue chaque demande et émet un score de confiance pour les CloudWatch métriques, mais ne bloque jamais le trafic.

Accumulez les données sur une période représentative : des jours ou des semaines de trafic de production réel. La ConfidenceScore métrique (avec PolicyEnforcementMode =LOG_ONLY) vous donne la distribution des scores produits par votre trafic.

Analysez les scores par rapport à la vérité sur le terrain. Si vous disposez d'un ensemble de tests étiqueté (instructions marquées comme bénignes ou malveillantes), vous pouvez calculer la précision et le rappel à chaque valeur de seuil et sélectionner celle qui correspond le mieux à vos objectifs. Si vous ne disposez pas de données étiquetées, échantillonnez des instructions provenant de la plage des scores les plus élevés (par exemple, 0,8 à 1,0), de la plage des scores les plus faibles (0 à 0,2) et de la zone médiane ambiguë (0,4 à 0,7), puis classez chaque échantillon pour renforcer la confiance dans votre choix de seuil. Mettez à jour la politique avec le seuil que vous avez choisi et faites-en la promotion pour 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\")) };"}}'

Ce flux de travail garantit que le seuil reflète vos modèles de trafic réels plutôt qu'une valeur par défaut générique.

Considérations et restrictions

LOG_ONLYles politiques n'influent jamais sur les décisions. Une LOG_ONLY politique ne peut pas autoriser ou refuser une action. La décision qu'une demande reçoit est identique à la décision qu'elle recevrait si la LOG_ONLY politique n'existait pas. Il s'agit de la garantie fondamentale de la fonctionnalité.

Les changements sont finalement cohérents. La création, la mise à jour ou la promotion d'une politique sont appliquées au parcours d'évaluation en quelques secondes. Planifiez vos fenêtres d'observation et vos étapes de promotion en conséquence plutôt que de vous attendre à un changement instantané.

Les listes de résultats sont limitées. LOG_ONLYles listes de correspondance et d'inversion des décisions sont chacune plafonnées à 1 000 entrées par demande. Pour les moteurs dotés d'un très grand nombre de LOG_ONLY politiques, fiez-vous aux CloudWatch métriques pour obtenir des comptes agrégés complets.

L'évaluation peut être partielle. Lorsque LOG_ONLY l'évaluation d'une demande est incomplète, les LOG_ONLY signaux de cette demande peuvent contenir des entrées manquantes. La décision exécutée n'est jamais affectée.