Ejemplos de políticas temporales

Las políticas de esta sección deciden a partir de lo que ya ha sucedido anteriormente en la misma sesión. Te permiten solicitar una aprobación antes de realizar un pago, caducar un permiso que ha quedado obsoleto, limitar un total acumulado o bloquear una acción en caso de error. Ninguna solicitud contiene información suficiente para decidir ninguna de estas opciones.

Cada ejemplo autoriza la puerta de enlace de referencia descrita, por ejemplo, en la configuración de recursos. Para ver el esquema de eventos temporales, los operadores, los identificadores de sesión, las cuotas y la disponibilidad regional, consulte Políticas temporales y Creación de políticas temporales.

Antes de usar estos ejemplos

Hay cuatro factores que determinan si una política temporal se comporta de la manera esperada.

Se requiere un identificador de sesión

El historial temporal se limita a la sesión que usted nombre. Envía un identificador de sesión en el x-amzn-bedrock-agentcore-policy-session-id encabezado de cada solicitud, empezando por la primera. La puerta de enlace no genera ninguno para usted y, si el motor tiene una política temporal, una solicitud sin ID de sesión no pasa la validación.

Solo las acciones permitidas se convierten en response eventos

Una acción registra un response evento solo si una política lo permitió y se completó. En su lugar, una acción denegada registra un error evento. Por lo tanto, cada uno de los siguientes ejemplos también necesita una acción previa clarapermit; de lo contrario, se deniega el requisito previo, nunca se registra como a y la condición temporal nunca podrá coincidir. response En todos los ejemplos se indica con qué permisos se puede emparejar.

eventResource: resourcees obligatorio

Cada predicado debe incluireventResource: resource, lo que vincula el evento coincidente con el recurso del ámbito de la política. Si se omite, se rechaza con. temporal predicates do not constrain the matched event to the current request’s resource No es necesario escribirsessionId: el esquema de eventos ya aplica todos los predicados a la sesión actual.

Las comparaciones ordenadas necesitan números enteros; la igualdad no

Dentro de un temporal { } bloque, los dos tipos de comparación aceptan tipos diferentes.

• Ordenar — <⇐,>,, >= — requiere una integer en ambos lados. A decimal o a string se rechazan al crear la política, concomparison requires numeric operands on both sides.

• La igualdad (==y!=) funciona en cualquier tipo, siempre que ambas partes sean del mismo tipo. Esto es lo que utiliza la correlación: al input.claimId context.input.claimId comparar dos cadenas, lo cual es compatible.

Por lo tanto, modele cualquier valor que tenga una política temporal con respecto al total o al umbral como uninteger. Esta es la razón por la que la pasarela de referencia indica el dinero en unidades enteras menores en las herramientas que se agregan en estos ejemplos. La suma tiene el mismo requisito y su propio mensaje: sum necesita un integer sumando. Para obtener más información, consulte Tipos de parámetros en las condiciones.

Exija una aprobación previa para la misma reclamación

Intención: permitir que el pago se desembolse únicamente en el caso de una reclamación que se haya aprobado al principio de la sesión, de modo que el agente no pueda desembolsarlo con cargo a un identificador de reclamación que haya inventado.

El predicado coincide con un ::response predicado completado. approve_claim La correlación entre el desembolso y la solicitud actual context.input.claimId es lo que vincula el desembolso a esa aprobación específica. Sin esa correlación, cualquier aprobación en la sesión autorizaría el pago de cualquier reclamación. output.claimId

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{
        eventResource: resource,
        output.claimId: context.input.claimId
    }
};

importante

output.*los campos de un response evento solo existen cuando el destinatario declara un esquema de salida para la herramienta. Muchos objetivos no lo hacen: un objetivo Lambda, por ejemplo, suele declarar solo entradas y, a continuación, el evento solo incluyeeventPrincipal, eventResource input.*requestId, y. sessionId

Si asignas un nombre a un campo que el evento no declara, el servicio rechaza la política y el error muestra lo que está disponible:

predicate `AgentCore::Action::"MyTarget___verify_purchase"::response` mentions field
`output.orderId`, which is not declared on that event (declared fields: eventPrincipal,
eventResource, input.orderId, requestId, sessionId)

Usa esa lista para ver con qué elementos puedes correlacionar. Si no existe ningún campo de salida, correlaciona en un campo de entrada compartido: input.claimId: context.input.claimId vincula las dos llamadas a la misma afirmación sin necesidad de utilizar la herramienta anterior para obtener ningún resultado.

Las dos no son equivalentes, así que elige deliberadamente. Una correlación de entrada coincide con lo que solicitó la llamada anterior; una correlación de salida coincide con lo que devolvió. Si la regla depende de un valor generado por la herramienta anterior (un identificador de aprobación, una cantidad calculada), solo se aplica una correlación de salida, por lo que el objetivo debe declarar un esquema de salida.

Combínelo con un permiso simple para que las aprobaciones estén permitidas y registradas:

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___approve_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
);

Secuencia de solicitudes en una sesión	Decisión
disburse_paymentsin aprobación previa	DENY
approve_claimpara una reclamación, luego disburse_payment para la misma reclamación	PERMITIR
approve_claimpara una reclamación, luego disburse_payment para una reclamación diferente	DENY

Exigir una acción previa

Intención: permite que se apruebe una reclamación solo después de que alguien haya comprobado su estado en la sesión.

La coincidencia ::request significa que el requisito previo solo se debe haber intentado, no se ha realizado correctamente. Combínelo con un permiso paraget_claim_status.

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___approve_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 5m AgentCore::Action::"InsuranceAPI___get_claim_status"::request{
        eventResource: resource
    }
};

Requerir un exitosa requisito previo, recientemente

Intención: permitir la aprobación solo si se ha completado una búsqueda de estado en los últimos cinco minutos, de modo que una búsqueda obsoleta deje de conceder permisos.

El único cambio con respecto al ejemplo anterior es ::response la ::request diferencia entre «se intentó» y «se realizó correctamente». La longitud de la ventana indica qué tan reciente debe ser el éxito; una vez aprobado, el permiso caduca hasta que se vuelva a ejecutar el requisito previo.

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___approve_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 5m AgentCore::Action::"InsuranceAPI___get_claim_status"::response{
        eventResource: resource
    }
};

Secuencia de solicitudes en una sesión	Decisión
approve_claimantes de completar cualquier búsqueda	DENY
se completa la búsqueda y, a continuación, approve_claim dentro de la ventana	PERMITIR
approve_claimuna vez transcurrida la ventana	DENY

Limita el número de veces que se ejecuta una acción

Intención: permite como máximo tres desembolsos en cada período de cinco minutos de una sesión.

countcuenta los eventos coincidentes de la ventana, incluida la solicitud que se está autorizando, de modo que la cuarta llamada de una ventana es la primera que se deniega. La exists (n: Long) carpeta captura el recuento para que el n > 3 filtro pueda probarlo; el agregado necesita paréntesis a la izquierda de. == Combínalo con un permiso disburse_payment para que se permitan llamadas hasta el límite.

forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    exists (n: Long).
        (count for (t: Timepoint).
            where (formerly within 5m (AgentCore::Action::"InsuranceAPI___disburse_payment"::request{ eventResource: resource } && tp(t)))) == n
        && n > 3
};

importante

No se trata de un control de seguridad. La persona que llama proporciona el identificador de sesión para que pueda restablecer el recuento iniciando una nueva sesión. Úselo para moldear el comportamiento dentro de una sesión cooperativa (por ejemplo, para detener a un agente en bucle, por ejemplo), no para imponer un límite a una persona que llama y controle su propio identificador de sesión. Para obtener más información, consulte Consideraciones de seguridad.

Limite un total acumulado

Intención: Permita los desembolsos hasta que alcancen un total de 3000€ en cinco minutos y, a continuación, deténgalos.

sumagrega el campo de entrada indicado a todos los eventos coincidentes, incluida la solicitud actual, de modo que se deniegue una solicitud que supere el umbral. Con un límite de 30 000 céntimos y desembolsos de 100 000, se permiten las dos primeras y se deniega la tercera.

forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    exists (total: Long).
        (sum amt for (amt: Long), (t: Timepoint).
            where (formerly within 5m (AgentCore::Action::"InsuranceAPI___disburse_payment"::request{ eventResource: resource, input.amountCents: amt } && tp(t)))) == total
        && total >= 300000
};

El dominio de dos variables,for (amt: Long), (t: Timepoint), es obligatorio: amt es el valor que se suma y t distingue los momentos, por lo que dos desembolsos del mismo importe se cuentan dos veces en lugar de deduplicarse en uno solo.

nota

amountCentses un esquema integrado integer en la herramienta, y eso es lo que hace que esta política funcione. La sum agregación necesita un sumando de enteros y la comparación de órdenes total necesita un número entero en ambos lados, por lo que un campo que su esquema declare como tal number no puede tener un límite como este. Para conocer las reglas de tipo de las que dependen estos ejemplos, consulte Antes de usar estos ejemplos.

Haga que cada aprobación sea válida para un solo uso

Intención: permita un desembolso por aprobación. Tras un pago, se requiere una nueva aprobación.

El since operador mantiene la posición cuando el ancla de su derecha se encuentra dentro de la ventana y la de su izquierda se mantiene de forma continua desde entonces. Aquí dice: la aprobación se completó en la última hora y no se ha realizado ningún desembolso desde entonces. El primer pago después de una aprobación lo consume.

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    !AgentCore::Action::"InsuranceAPI___disburse_payment"::response{ eventResource: resource }
    since within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};

Hacer coincidir el ::response lado negativo es esencial. La solicitud que se está autorizando aún no ha generado respuesta, por lo que no se bloquea por sí sola: si se hace coincidir ::request allí, todos los desembolsos se denegarían por sí solos.

Secuencia de solicitudes en una sesión	Decisión
approve_claim, entonces disburse_payment	PERMITIR
un segundo disburse_payment sin nueva aprobación	DENY
una nuevaapprove_claim, entonces disburse_payment	PERMITIR

nota

Un response evento se graba poco después de que se complete la llamada. Espere a que se devuelva la aprobación antes de emitir el desembolso en lugar de enviarlos uno tras otro. Para obtener más información, consulte Secuenciar las acciones que dependen de una respuesta previa.

Imponga un enfriamiento

Intención: evitar que la misma acción se repita un minuto después de completarse.

Esta condición se refiere a la misma acción que autoriza. ::responsees lo que lo hace seguro: la solicitud actual aún no tiene respuesta, por lo que no coincide consigo misma. Si se escribe así::request, la solicitud actual coincidiría con su propio evento y la acción quedaría prohibida permanentemente. Para obtener más información, consulte Self-referential las condiciones para incluir la solicitud actual.

forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 1m AgentCore::Action::"InsuranceAPI___disburse_payment"::response{
        eventResource: resource
    }
};

Exija una condición previa que no se haya invalidado

Intención: permitir el desembolso mientras esté vigente la aprobación y retirar el permiso si la solicitud se vuelve a abrir para que se revise su estado posteriormente.

Esto tiene la misma forma que la aprobación de un solo uso, pero la acción denegada es diferente de la acción que se autoriza, que convierte «consumir la aprobación» en «invalidar la aprobación». Otorgue permisos tanto para como para. approve_claim get_claim_status

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    !AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource }
    since within 5m AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};

Secuencia de solicitudes en una sesión	Decisión
disburse_paymentantes de cualquier aprobación	DENY
approve_claim, entonces disburse_payment	PERMITIR
get_claim_statusocurre, entonces disburse_payment	DENY
una nuevaapprove_claim, entonces disburse_payment	PERMITIR

Requieren una cadena de acciones en orden

Intención: Exigir la búsqueda del estado de la secuencia, luego la aprobación y, finalmente, el desembolso.

Una política por eslabón y la cadena surge de su composición. Otorgue un permiso simple para la primera acción para que la cadena pueda comenzar. Se deniega un paso que se intenta fuera de orden hasta que se complete su requisito previo.

// Link 1: approve only after a completed status lookup
permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___approve_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 5m AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource }
};

// Link 2: disburse only after a completed approval
permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 5m AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};

Exija dos requisitos previos en cualquier orden

Intención: permitir el desembolso solo después de que se hayan completado la búsqueda de estado y la aprobación, en cualquier orden.

La combinación de dos formerly condiciones && requiere ambas condiciones y ninguna de ellas restringe el pedido. Esto utiliza dos de los tres operadores temporales que puede contener una sola política.

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 1h AgentCore::Action::"InsuranceAPI___get_claim_status"::response{ eventResource: resource }
    && formerly within 1h AgentCore::Action::"InsuranceAPI___approve_claim"::response{ eventResource: resource }
};

Haga que dos acciones se excluyan mutuamente

Intención: en un plazo de dos minutos, permite el desembolso o la eliminación de una reclamación, pero no ambas opciones.

La exclusión necesita dos políticas simétricas, una por dirección; una única política solo forbid bloquearía un pedido. Hacer coincidir ::request significa que el simple hecho de intentar una acción bloquea la otra, sin esperar a que se complete.

// Forbid deletion if a disbursement was requested within 2m
forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___delete_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 2m AgentCore::Action::"InsuranceAPI___disburse_payment"::request{ eventResource: resource }
};

// Forbid disbursement if a deletion was requested within 2m
forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 2m AgentCore::Action::"InsuranceAPI___delete_claim"::request{ eventResource: resource }
};

Requiere un número mínimo de eventos

Intención: permitir que una reclamación se elimine solo después de que se hayan realizado al menos dos desembolsos en su contra.

Al correlacionarlo input.claimId con la solicitud actual, el cómputo se incluye en el cómputo de esa reclamación, en lugar de contabilizar todos los desembolsos de la sesión.

permit (
    principal,
    action == AgentCore::Action::"InsuranceAPI___delete_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    exists (n: Long).
        (count for (t: Timepoint).
            where (formerly within 5m (AgentCore::Action::"InsuranceAPI___disburse_payment"::response{ eventResource: resource, input.claimId: context.input.claimId } && tp(t)))) == n
        && n >= 2
};

nota

countcuenta los eventos, no las distintas personas que llaman. No puede expresar «aprobado por dos personas diferentes», porque nada impide que un director produzca todos los eventos coincidentes. Para obtener la aprobación por parte de varias partes, establezca una correlación eventPrincipal o haga cumplir la distinción fuera de la política.

Bloquee una acción después de una denegación anterior

Intención: impedir el desembolso de una sesión después de que se haya denegado cualquier intento de aprobación.

Un error evento registra una solicitud denegada o fallida, así ::error como la forma en que una política reacciona ante un error anterior. Combínalo con un permiso simple disburse_payment para que esté permitido en condiciones normales.

forbid (
    principal,
    action == AgentCore::Action::"InsuranceAPI___disburse_payment",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    formerly within 3m AgentCore::Action::"InsuranceAPI___approve_claim"::error{
        eventResource: resource
    }
};

Se trata de un patrón de contención útil: un agente que busca permisos que no tiene se ve excluido de una acción delicada en lugar de poder seguir intentándolo.

Combine las condiciones temporales, de protección y de solicitud

Intención: permitir que la persona que llama presente reclamaciones, siempre que en la sesión se hayan presentado menos de tres solicitudes en las últimas 24 horas, la descripción de la reclamación no contenga datos bancarios y la persona que llama no desempeñe una función restringida.

Los tres tipos de condiciones se componen de una política y todas las cláusulas deben ser válidas para que se apliquen. permit El temporal bloqueo impone el límite, el when bloque filtra el contenido y el unless bloqueo excluye un rol. Cada uno se evalúa de forma independiente.

permit (
    principal is AgentCore::OAuthUser,
    action == AgentCore::Action::"InsuranceAPI___file_claim",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/insurance-gw-a1b2c3d4e5"
)
when temporal {
    exists (n: Long).
        (count for (t: Timepoint).
            where (formerly within 24h (AgentCore::Action::"InsuranceAPI___file_claim"::request{ eventResource: resource } && tp(t)))) == n
        && n <= 3
}
when {
    BedrockGuardrails::SensitiveInformation(["US_BANK_ACCOUNT_NUMBER"], [context.input.description]).count() == 0
}
unless {
    principal.hasTag("role") &&
    principal.getTag("role") == "restricted"
};

Las pantallas de barandilladescription, que son las únicas que utilizan los parámetros de texto libre. file_claim Apunte con una barandilla de información confidencial a un campo que pueda contener de forma plausible los datos que está buscando. Si apunta a un identificador o a un número, no detectará nada y la cláusula pasará desapercibida. descriptiones opcional, por lo que una solicitud que lo omita no proporciona texto a la barandilla y la cláusula es válida.

¿Qué cambia al editar una política temporal

Añadir o actualizar una política temporal en un motor invalida las sesiones temporales abiertas de ese motor, ya que el historial registrado ya no coincide con las reglas que se le aplican. La siguiente solicitud que reutiliza una sesión invalidada falla con HTTP 409. ConflictException Inicie una nueva sesión y vuelva a intentarlo; la nueva sesión comienza con el historial vacío y se evalúa en función de las políticas actualizadas.

importante

Planifique esto cuando implemente un cambio temporal en la política. Los clientes deben tratar una 409 como «iniciar una nueva sesión». Cualquier flujo de trabajo continuo de varios pasos se reinicia en lugar de reanudarse.