# Probar una política en el modo LOG\_ONLY Con el modo de aplicación a nivel de política, puede alternar entre `ACTIVE` y responder `LOG_ONLY` a la pregunta: «¿Qué afectaría esta política a mi tráfico si se aplicara?» `LOG_ONLY`El modo por política le permite probar una política en el tráfico real sin que ello afecte a las decisiones de autorización. La política evalúa cada solicitud como si se hubiera aplicado, pero solo escribe los resultados en los registros. No se bloquea ni se permite nada como resultado de una política cuyo modo de aplicación sea`LOG_ONLY`. Una vez que confíes en los resultados, promuévelo a`ACTIVE`. **Topics** + [Cómo funciona el modo LOG\_ONLY](#how-log-only-mode-works) + [Políticas LOG\_ONLY y motores de políticas LOG\_ONLY](#log-only-policies-and-log-only-policy-engines) + [Defina el modo de aplicación de una política](#set-the-enforcement-mode-of-a-policy) + [Observe los resultados de LOG\_ONLY](#observe-log-only-results) + [Promueva una política para su cumplimiento](#promote-a-policy-to-enforcement) + [Elegir un umbral con el modo LOG\_ONLY](#choosing-a-threshold-with-log-only-mode) + [Consideraciones y limitaciones](#policy-log-only-considerations-and-limitations) ## Cómo funciona el modo LOG\_ONLY Cada política de un motor de políticas tiene un modo de aplicación de uno u `ACTIVE` otro. `LOG_ONLY` El valor predeterminado es`ACTIVE`, por lo que las políticas existentes y cualquier política nueva que cree sin especificar el campo seguirán aplicándose como antes. Cuando el motor de políticas evalúa una solicitud, evalúa sus `ACTIVE` políticas y sus `LOG_ONLY` políticas en paralelo, pero solo las aplica. `ACTIVE` `ACTIVE`las políticas determinan la decisión que se devuelve al AgentCore Gateway y se hace cumplir. El motor de políticas aplica las semánticas «por defecto, se deniega» y «se prohíbe, gana», lo que significa que una solicitud solo se permite si una política lo permite, y una sola prohibición de cualquier política activa la deniega. `LOG_ONLY`las políticas se evalúan en función de la misma solicitud, pero sus resultados se mantienen separados. Se registran en trazas y se emiten como CloudWatch métricas de Amazon. Nunca se combinan en la decisión ejecutada. | Modo de ejecución | ¿Evaluado en cada solicitud? | ¿Afecta a la decisión devuelta? | | --- | --- | --- | | `ACTIVE` (predeterminado) | Sí | Sí | | `LOG_ONLY` | Sí | No | Una solicitud se evalúa en dos etapas: 1. El motor de políticas calcula una decisión. Solo `ACTIVE` las políticas contribuyen a ello. `LOG_ONLY`las políticas se evalúan e informan por separado, pero nunca se tienen en cuenta. 1. Si el motor está asociado a una puerta de enlace en `ENFORCE` modo, la puerta de enlace permite o deniega la acción de acuerdo con la decisión del motor de políticas. Si el motor está asociado a una puerta de enlace en `LOG_ONLY` modo, la puerta de enlace no realiza ninguna acción; la decisión se registra pero no se aplica. `ACTIVE`y `LOG_ONLY` se tratan como dos conjuntos aislados; una `LOG_ONLY` política nunca puede cambiar la experiencia de las personas que llaman. La decisión que recibe una solicitud no se ve afectada por ninguna `LOG_ONLY` política. Además de registrar las `LOG_ONLY` políticas que coincidieron en una solicitud, el motor de políticas informa cuáles de esas políticas habrían cambiado la decisión si lo hubieran sido`ACTIVE`. Esta es una señal clave que se debe utilizar al evaluar la eficacia y la seguridad de una política (es decir, si se puede promover su aprobación`ACTIVE`). Por ejemplo, una `LOG_ONLY` política que coincide con frecuencia y que aparece en el conjunto de opciones de cambio de decisiones habría bloqueado el tráfico durante el período de observación. Cada `LOG_ONLY` política se evalúa de forma independiente de todas las demás `LOG_ONLY` políticas para determinar el conjunto de políticas de cambio de decisiones. Sin embargo, cada evaluación `LOG_ONLY` de políticas considera todas las políticas actuales`ACTIVE`. ## Políticas LOG\_ONLY y motores de políticas LOG\_ONLY La política in AgentCore tiene dos controles independientes y ambos utilizan el valor LOG\_ONLY. Funcionan en distintos niveles y responden a distintas preguntas, por lo que es importante entender cuál está configurando. **Modo de aplicación del motor de políticas:** controla el comportamiento general del motor. Cuando se establece en`LOG_ONLY`, no se aplica ninguna política en el motor, independientemente de su modo de política individual. Se registran todas las decisiones. Se establece mediante el `mode` campo de `policyEngineConfiguration` cuando se asocia un motor de políticas a una puerta de enlace mediante las `UpdateGateway` operaciones `CreateGateway` o. Los dos valores que se `mode` aceptan son `ENFORCE` (predeterminado) y`LOG_ONLY`. El modo de política controla el comportamiento de una sola política dentro de un motor de aplicación. Si se establece en LOG\_ONLY, esa política se sigue evaluando, pero su decisión se registra en lugar de aplicarse. Todas `ACTIVE` las demás políticas del motor se siguen aplicando con normalidad. Los dos valores que se `enforcementMode` aceptan son `ACTIVE` (predeterminado) y`LOG_ONLY`. Utilice LOG\_ONLY, a nivel de política, para realizar pruebas paralelas de una nueva barandilla en producción sin que ello afecte al tráfico. Utilice LOG\_ONLY a nivel de motor para observar el comportamiento de todas las políticas antes de permitir su aplicación.
Modo de aplicación de políticas
ACTIVE LOG_ONLY
Modo de aplicación del motor de políticas ENFORCE Evaluado y aplicado. Puede bloquear o modificar las solicitudes.Se evalúa pero no se aplica. La decisión solo se registra; otras ACTIVE políticas del motor se siguen aplicando.
LOG_ONLY Se evalúa pero no se aplica. La decisión solo se registra.Se evalúa pero no se aplica. La decisión solo se registra.
**nota** El modo de aplicación del motor de políticas tiene prioridad. Cuando un motor de políticas está asociado en el modo LOG\_ONLY, ninguna política puede denegar una acción de Gateway (ni siquiera una política en modo de `ACTIVE` cumplimiento) porque el Gateway no actúa en absoluto según la decisión del motor de políticas. El motor sigue calculando la decisión y usted sigue recibiendo `LOG_ONLY` telemetría; simplemente, la decisión no se aplica. ## Defina el modo de aplicación de una política Puede configurar el `enforcementMode` campo de una política al crear o actualizar la política (es decir, `CreatePolicy` y`UpdatePolicy`), y se devuelve mediante `GetPolicy` y`ListPolicies`. **Cree una política en `LOG_ONLY` el modo** Cree una política en `LOG_ONLY` el modo `enforcementMode` configurándolo `LOG_ONLY` en la `CreatePolicy` solicitud. El siguiente ejemplo crea una barrera en la política que prohíbe el contenido violento por encima de un umbral de confianza, pero solo lo respeta. [Para obtener más información sobre las barreras de protección en la política, consulte las barreras de protección en las políticas.](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\")) };"}}' ``` La respuesta se hace eco de la política con «EnforcementMode»: «LOG\_ONLY». La política comienza evaluando en función del tráfico y, a partir de ese momento, las coincidencias aparecen en los registros y CloudWatch las métricas, sin que ello afecte a la decisión. **Enumere las políticas y sus modos de aplicación** ListPolicies aparece `enforcementMode` en el resumen de cada política, para que pueda ver de un vistazo qué políticas se cumplen y cuáles se están aplicando. ``` aws bedrock-agentcore-control list-policies \ --policy-engine-id my-policy-engine-id \ --query 'policies[].{name:name,enforcementMode:enforcementMode,status:status}' ``` **respuesta** ``` [ { "name": "LogOnlyViolenceFilter", "enforcementMode": "LOG_ONLY", "status": "ACTIVE" }, { "name": "RefundLimit", "enforcementMode": "ACTIVE", "status": "ACTIVE" } ] ``` ## Observe los resultados de LOG\_ONLY Cuando una persona que llama hace una tools/call solicitud a través de la puerta de AgentCore enlace, la puerta de enlace evalúa todas las políticas, incluidas las políticas, antes de devolver la respuesta `LOG_ONLY` del MCP a la persona que llama. La respuesta de la persona que llama nunca se ve afectada por `LOG_ONLY` las políticas; esos resultados se informan únicamente a través de la observabilidad. Se observa el comportamiento `LOG_ONLY` de las políticas a través de los rastreos y CloudWatch las métricas de Amazon: **Rastreos y intervalos:** cuando habilitas el rastreo en tu pasarela, los intervalos de evaluación de políticas incluyen `LOG_ONLY` información sobre las coincidencias. Puedes inspeccionar estos intervalos en la consola de AgentCore Observability para ver qué `LOG_ONLY` políticas se activaron en función de una solicitud determinada y si habrían cambiado la decisión. Para obtener más información, consulte [Observe sus solicitudes de agente en Amazon Bedrock AgentCore Observability](observability.md). **CloudWatch métricas:** Policy in AgentCore emite métricas en el espacio de nombres. AWS/Bedrock-AgentCore Las siguientes métricas son específicas de la evaluación: `LOG_ONLY` | Métrica | Qué te dice | | --- | --- | | `ConfidenceScore`(con PolicyEnforcementMode =`LOG_ONLY`) | La puntuación de confianza que obtuvo la barandilla para una póliza similar. `LOG_ONLY` Úselo para comprender la distribución de las puntuaciones de su tráfico a la hora de elegir un umbral. | | `ConfidenceThreshold` (con `PolicyEnforcementMode=LOG_ONLY`) | El umbral configurado en la `LOG_ONLY` política. Es útil para comparar la puntuación con el umbral en todas las políticas. | | `LogOnlyMatches` | El recuento de solicitudes en las que se activó una `LOG_ONLY` política. Se emiten por política y se agrupan en todas `LOG_ONLY` las políticas del motor. | | `LogOnlyDecisionFlips` | El recuento de solicitudes en las que una `LOG_ONLY` política habría cambiado la decisión si se hubiera promovido. Esta es la señal clave de promoción: un cero sostenido significa que la promoción de la política no bloqueará el tráfico actual. | | `LogOnlyEvalIncomplete` | Se emitió cuando `LOG_ONLY` la evaluación era parcial. Utilice esta opción para alertar sobre una tasa sostenida de evaluaciones incompletas. | Todas las métricas incluyen PolicyEngine OperationName dimensiones para el filtrado. Per-policy Las métricas también incluyen una dimensión de política con el ID de la política. Para obtener más información sobre la visualización de las métricas de sus AgentCore recursos, consulte los datos de [observabilidad AgentCore generados por Bedrock](observability.md). ## Promueva una política para su cumplimiento Cuando confíe en una `LOG_ONLY` política, promuévala para que se haga cumplir con`UpdatePolicy`, `enforcementMode` optando por`ACTIVE`. No se requiere ningún otro cambio y la política conserva su ID, nombre y definición. ``` aws bedrock-agentcore-control update-policy \ --policy-engine-id my-policy-engine-id \ --policy-id LogOnlyViolenceFilter-a1b2c3d4e5 \ --enforcement-mode ACTIVE ``` También se admite lo contrario: se puede volver a colocar una `ACTIVE` política `LOG_ONLY` para dejar de aplicarla y, al mismo tiempo, mantenerla en vigor y seguir respetándola. Por lo tanto, un ciclo de vida típico consiste en crear una política`LOG_ONLY`, observar el tráfico y las métricas y, luego, promocionarla `ACTIVE` y, si es necesario, volver a degradarla `LOG_ONLY` sin eliminarla ni volver a crearla. ## Elegir un umbral con el modo LOG\_ONLY `LOG_ONLY`este modo es especialmente útil para las políticas de protección, en las que es necesario seleccionar un umbral de confianza que equilibre la seguridad con la interrupción del tráfico legítimo. Un umbral demasiado bajo bloquea las solicitudes legítimas; uno demasiado alto puede dejar pasar las amenazas. **El flujo de trabajo recomendado:** despliegue la barandilla en un `LOG_ONLY` modo con un umbral que considere razonable (por ejemplo, 0,7). La política evalúa todas las solicitudes y emite una puntuación de confianza según CloudWatch las métricas, pero nunca bloquea el tráfico. Acumule datos en un período representativo: días o semanas de tráfico de producción real. La ConfidenceScore métrica (con PolicyEnforcementMode =LOG\_ONLY) te proporciona la distribución de las puntuaciones que genera tu tráfico. Analiza las puntuaciones comparándolas con la realidad básica. Si tiene un conjunto de pruebas etiquetado (las instrucciones están marcadas como benignas o maliciosas), puede calcular la precisión y la memoria en cada valor umbral y seleccionar el que mejor se adapte a sus objetivos. Si no tiene datos etiquetados, muestree las indicaciones del rango de puntuación alta (por ejemplo, 0,8 a 1,0), el rango de puntuación baja (0 a 0,2) y la zona media ambigua (0,4 a 0,7) y, a continuación, clasifique cada muestra para generar confianza en la elección del umbral. Actualice la política con el umbral que haya elegido y promuévala para: `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\")) };"}}' ``` Este flujo de trabajo garantiza que el umbral refleje tus patrones de tráfico reales y no un valor predeterminado genérico. ## Consideraciones y limitaciones `LOG_ONLY`las políticas nunca afectan a las decisiones. Una `LOG_ONLY` política no puede provocar que se permita o deniegue una acción. La decisión que recibe una solicitud es idéntica a la decisión que recibiría si la `LOG_ONLY` política no existiera. Esta es la principal garantía de la función. Los cambios son finalmente consistentes. La creación, actualización o promoción de una política se aplica a la ruta de evaluación en cuestión de segundos. Planifique sus períodos de observación y las etapas de promoción en consecuencia, en lugar de esperar un cambio instantáneo. Las listas de resultados están acotadas. `LOG_ONLY`Las listas de coincidencias y de cambio de decisiones tienen un límite máximo de 1000 entradas por solicitud. En el caso de motores con un gran número de `LOG_ONLY` políticas, confíe en las CloudWatch métricas para obtener recuentos agregados completos. La evaluación puede ser parcial. Cuando `LOG_ONLY` la evaluación de una solicitud está incompleta, es posible que falten entradas en las `LOG_ONLY` señales de esa solicitud. La decisión ejecutada nunca se ve afectada.