Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Creación de políticas temporales

Crea una política temporal en el lenguaje de políticas de Dogwood y la agrega a un motor de políticas, de la misma manera que crea cualquier otra política para Policy en. AgentCore Una política temporal es una forbid regla permit o cuyas condiciones compatibles con la sesión se colocan en un temporal bloque; el principal, la acción y el recurso al que se aplica la regla se escriben utilizando el (principal, action, resource) ámbito estándar, al igual que cualquier otra política. En las siguientes secciones se muestra cómo crear una política temporal y se describen los patrones comunes que se pueden expresar.

Cree una política temporal

Crea una política temporal con la create-policy operación, la misma operación que usa para otras políticas, y la adjunta a un motor de políticas. La declaración de una política temporal se incluye policy en la definición, y no en el caso cedar de una política Cedar sin estado.

El siguiente ejemplo de AWS CLI crea una política temporal en un motor de políticas:

aws bedrock-agentcore-control create-policy \
  --policy-engine-id my-policy-engine-id \
  --name TransferToLookedUpAccount \
  --validation-mode FAIL_ON_ANY_FINDINGS \
  --definition '{
    "policy": {
      "statement": "permit (principal, action == AgentCore::Action::\"FundsTarget___transfer_funds\", resource == AgentCore::Gateway::\"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway\") when temporal { formerly within 1h AgentCore::Action::\"FundsTarget___get_account_balance\"::response{ eventResource: resource, output.accountId: context.input.toAccount } };"
    }
  }'

También puede crear una política temporal describiéndola en lenguaje natural en lugar de escribir la sentencia Dogwood usted mismo.

Esquema de eventos: campos a los que puede hacer referencia

Las condiciones de un temporal { } bloque utilizan predicados de eventos temporales para hacer coincidir los eventos específicos que se han registrado en la sesión hasta el momento (incluida la acción que se está autorizando actualmente). Un predicado indica una ventana temporal, un tipo de acción y evento y un conjunto de restricciones de campo del evento coincidente. En el create-policy ejemplo de la sección anterior se utilizó un predicadoformerly within 1h AgentCore::Action::"FundsTarget___get_account_balance"::response{ eventResource: resource, output.accountId: context.input.toAccount }, que coincide con un predicado get_account_balance response registrado en la última hora y que output.accountId es igual al de la solicitud actual. toAccount

Para escribir un predicado, necesitas saber qué eventos produce una acción y qué campos contiene cada evento, porque esos son los campos con los que un predicado puede restringir y correlacionar. En esta sección se describe ese esquema de eventos.

Cada acción produce hasta tres tipos de eventos, con el nombre del tipo de evento en el predicado (::request,::response,::error):

El esquema de eventos temporales define estos eventos para cada acción. A …​inputs(A)y …​outputs(A) amplíelo a los campos de entrada y salida declarados de la acción:

// Recorded for each authorized request.
decision event <A>::request {
    ...inputs(A),
    eventPrincipal: principalType(A),
    eventResource:  resourceType(A),
    requestId:      String,
    pin sessionId:  String = context.sessionId,
}

// Recorded when the tool returns successfully; carries inputs and outputs.
event <A>::response {
    ...inputs(A),
    ...outputs(A),
    eventPrincipal: principalType(A),
    eventResource:  resourceType(A),
    requestId:      String,
    pin sessionId:  String = context.sessionId,
}

// Recorded when the request is denied or the tool returns an error; history-only.
event <A>::error {
    ...inputs(A),
    eventPrincipal: principalType(A),
    eventResource:  resourceType(A),
    requestId:      String,
    pin sessionId:  String = context.sessionId,
}

Dentro de un cuerpo de predicado, puedes hacer referencia a los siguientes campos del evento coincidente:

Para correlacionar un evento registrado con la solicitud actual, compare uno de estos campos con un valor de la solicitud actual, como. context.input.<name>

Casos de uso

Los siguientes son algunos ejemplos de políticas temporales.

Herramientas disponibles

Los ejemplos de esta sección utilizan un objetivo de puerta de enlace denominado FundsTarget que expone tres herramientas. En una política, se hace referencia a cada herramienta por su nombre de acción y por los campos de entrada y salida que se enumeran aquí. FundsTarget___<tool-name>

Ejemplo: integridad entre la salida y la entrada

Este ejemplo permite a un agente transferir fondos solo a una cuenta que haya buscado anteriormente en la misma sesión, lo que evita que se transfiera a una cuenta que él mismo ha fabricado. La política transfer_funds solo lo permite cuando una get_account_balance respuesta obtenida al principio de la sesión arroja la misma cuenta:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 1h AgentCore::Action::"FundsTarget___get_account_balance"::response{
        eventResource: resource,
        output.accountId: context.input.toAccount
    }
};

El ::response predicado coincide con la respuesta registrada de una respuesta anteriorget_account_balance. output.accountIdes un campo que devuelve la herramienta y context.input.toAccount es la cuenta de destino de la transfer_funds solicitud actual; si se exige que sean iguales, la transferencia se vincula a una búsqueda anterior.

Como un motor de políticas lo deniega de forma predeterminada, y dado que una acción se registra como response solo si estaba permitida, también se asigna un valor simple permit para get_account_balance que la búsqueda se permita y se registre como respuesta en la sesión:

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

Con ambas políticas en vigor, las solicitudes de una sesión se deciden de la siguiente manera:

Ejemplo: secuenciación de herramientas

Este ejemplo permite realizar una acción solo después de que una acción previa se haya ejecutado anteriormente en la misma sesión. La siguiente política get_account_balance solo lo permite si la transfer_funds solicitud se ha realizado en los últimos cinco minutos:

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

El ::request predicado coincide con una transfer_funds solicitud anterior de la sesión. Combínelo con un permit para para transfer_funds que la acción esté permitida y grabada. Con ambas políticas en vigor, get_account_balance se deniega hasta que transfer_funds se ejecute una en la sesión:

Ejemplo: actualización de los datos

En este ejemplo, solo se permite realizar una acción si un requisito previo se ha completado correctamente en un plazo reducido, de modo que los resultados obsoletos hacen caducar el permiso. get_account_balanceSolo se permite si transfer_funds se ha completado en los últimos cinco minutos:

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

La coincidencia, ::response más que la secuenciación de herramientas, ::request es la diferencia: un response evento solo se registra cuando la acción se completa correctamente, por lo que esta política exige que se complete correctamente recientemente, no solo una solicitud previa. La longitud de la ventana establece qué tan reciente debe estar completada; una vez transcurrido el período, el permiso caduca hasta que se vuelva a ejecutar el requisito previo.

Ejemplo: limitación de frecuencia basada en la sesión

En este ejemplo, se limita una herramienta a un número fijo de llamadas dentro de una sesión. La siguiente política prohíbe transfer_funds que se llame más de tres veces durante los cinco minutos de la sesión:

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

La count expresión cuenta las transfer_funds solicitudes registradas en la sesión en los últimos cinco minutos, incluida la solicitud actual; cuando ese recuento supera las tres, se aplica la prohibición. Combínala con un permit para transfer_funds para que se permitan las llamadas hasta el límite. Con ambas políticas vigentes, se permiten las tres primeras transfer_funds llamadas dentro de un período de cinco minutos y se deniega la cuarta llamada (o posterior) en ese período.

Ejemplo: aprobación de un solo uso

Este ejemplo hace que cada aprobación sea válida para un solo uso. A solo transfer_funds se permite si no se transfer_funds ha completado ninguna desde la última get_account_balance (la aprobación) de la sesión. Una vez que se completa una transferencia, se agota la aprobación y se deniega la siguiente transferencia hasta que se produzca una nueva aprobación:

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

Esta since condición se mantiene cuando se ha completado get_account_balance (la aprobación) en la última hora y no se transfer_funds ha completado nada desde esa aprobación. La coincidencia ::response es esencial: una transferencia se considera completada solo cuando se realiza correctamente, por lo que la solicitud que se está autorizando no se bloquea por sí sola. Combínalo con un permit para para get_account_balance que se registren las aprobaciones.

Las solicitudes de una sesión se deciden de la siguiente manera:

Ejemplo: presupuesto acumulado

Este ejemplo limita el valor total de una acción dentro de una ventana. La siguiente política prohíbe que, transfer_funds una vez que la suma de las amount entradas de la sesión en los últimos cinco minutos alcance los 3000, se transfiera:

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

La sum expresión suma el campo amount de entrada de todas las transfer_funds solicitudes coincidentes de la ventana, incluida la solicitud actual; cuando el total alcanza el umbral, se aplica la prohibición. El campo sumado es un campo de entrada de la acción. Empareje la política con un permit paratransfer_funds. Por ejemplo, con un umbral de 3000 y transferencias de 1000, se permiten las dos primeras y se deniega la tercera, que alcanzaría los 3000.

Al igual que ocurre con la limitación de velocidad, la suma se aplica a la sesión actual y no se suma entre las distintas sesiones.

Ejemplo: enfriamiento

Este ejemplo impone un tiempo de espera: una acción no se puede repetir durante un período fijo desde su última finalización. Está prohibido transfer_funds si se transfer_funds completa en el último minuto:

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

Esta condición es autorreferencial: coincide con la misma acción que se está autorizando. La coincidencia ::response es lo que hace que funcione, ya que la solicitud que se está autorizando aún no ha generado una respuesta, por lo que no coincide por sí misma. ::requestEsta coincidencia haría que la solicitud actual coincidiera con su propio evento y la acción quedaría permanentemente prohibida. Cuando la ventana transcurra sin que se complete de nuevo, la acción volverá a permitirse.

Ejemplo: condición previa continua

Este ejemplo solo permite una acción mientras se cumpla una condición previa: se ha producido una confirmación positiva recientemente y nada la ha invalidado desde entonces. transfer_fundsSolo se permite si una get_account_balance (la confirmación) se ha completado en los últimos cinco minutos y no se ha completado ninguna get_transaction_history (la invalidación) desde entonces:

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    !AgentCore::Action::"FundsTarget___get_transaction_history"::response{ eventResource: resource }
    since within 5m AgentCore::Action::"FundsTarget___get_account_balance"::response{ eventResource: resource }
};

Esta since condición se mantiene cuando se get_account_balance ha completado en los últimos cinco minutos y no se get_transaction_history ha completado desde entonces. La finalización get_account_balance confirma la condición previa, y exigir que no se get_transaction_history haya producido nada desde entonces garantiza que nada la invalide después. Otorga permisos para ambas get_account_balance y get_transaction_history así quedan registradas.

Ejemplo: cadena de saltos múltiples

Puede crear varias políticas de secuenciación para exigir una cadena de acciones, cada una de las cuales solo está permitida una vez finalizada la anterior. Este ejemplo requiere la cadena get_account_balance → get_transaction_history →transfer_funds, utilizando dos políticas (una por enlace):

// Link 1: permit get_transaction_history only after get_account_balance completed
permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_transaction_history",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 5m AgentCore::Action::"FundsTarget___get_account_balance"::response{ eventResource: resource }
};

// Link 2: permit transfer_funds only after get_transaction_history completed
permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 5m AgentCore::Action::"FundsTarget___get_transaction_history"::response{ eventResource: resource }
};

Cada política impone un eslabón, y la cadena surge de su composición: lo que transfer_funds exigeget_transaction_history, lo que exigeget_account_balance. Otorga una permit a la primera acción de la cadena para que pueda empezar. Se denegará un paso que se intente de forma desordenada hasta que se complete su requisito previo.

Ejemplo: exclusión mutua

En este ejemplo, dos acciones se excluyen mutuamente dentro de una ventana: la que se ejecute primero bloquea la otra. Utiliza dos políticas de prohibición simétricas, por lo que la exclusión se mantiene en ambas direcciones. Aquí, transfer_funds y get_transaction_history no pueden ocurrir ambas cosas en dos minutos:

// Forbid get_transaction_history if a transfer_funds was requested within 2m
forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___get_transaction_history",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 2m AgentCore::Action::"FundsTarget___transfer_funds"::request{ eventResource: resource }
};

// Forbid transfer_funds if a get_transaction_history was requested within 2m
forbid (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 2m AgentCore::Action::"FundsTarget___get_transaction_history"::request{ eventResource: resource }
};

Como cada política coincide::request, incluso si se solicita una acción, se bloquea la otra: el bloqueo no espera a que se complete la primera acción. Necesitas dos forbid políticas simétricas, una por dirección: una prohíbe get_transaction_history después de una transfer_funds solicitud y la otra prohíbe transfer_funds después de una solicitud. get_transaction_history Una sola prohibición bloquearía solo un pedido. Combina ambas con los permisos para las dos acciones.

Ejemplo: combinar condiciones temporales, guardarrail y Cedar

Una sola póliza puede combinar una condición temporal con condiciones de protección y condiciones estándar de Cedar; todas ellas deben cumplirse para que la póliza se aplique. En este ejemplo, transfer_funds solo se permite cuando el importe acumulado de la transferencia se mantiene por debajo de un límite (temporal), la solicitud no contiene información confidencial (protección) y la persona que llama no forma parte de un grupo bloqueado (Cedar):

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___transfer_funds",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    exists (total: Long).
        (sum amt for (amt: Long), (t: Timepoint).
            where (formerly within 24h (AgentCore::Action::"FundsTarget___transfer_funds"::request{ eventResource: resource, input.amount: amt } && tp(t)))) == total
        && total < 60000
}
when {
    BedrockGuardrails::SensitiveInformation(["ACCOUNT_NUMBER"], [context.input.body]).count() == 0
}
unless {
    principal in Group::"blocked_users"
};

El bloqueo temporal aplica el límite acumulativo, el bloqueo de protección bloquea las solicitudes que contienen la información confidencial de la lista y el bloque Cedar excluye a los principales bloqueados. unless Cada tipo de condición se evalúa de forma independiente y el permiso solo se aplica cuando todas ellas se cumplen. Para ver la sintaxis de las condiciones de protección, consulte Las barreras de protección en las políticas; el bloque temporal se comporta como se describe en los ejemplos anteriores.

Ejemplo: requisitos previos paralelos

Este ejemplo requiere que se hayan completado dos requisitos previos, en cualquier orden, antes de que se permita una acción. get_account_balanceSolo se permite si ambas get_transaction_history se han completado en la última hora, transfer_funds y se combinan dos formerly condiciones: &&

permit (
    principal,
    action == AgentCore::Action::"FundsTarget___get_account_balance",
    resource == AgentCore::Gateway::"arn:aws:bedrock-agentcore:us-west-2:123456789012:gateway/my-gateway"
)
when temporal {
    formerly within 1h AgentCore::Action::"FundsTarget___transfer_funds"::response{ eventResource: resource }
    && formerly within 1h AgentCore::Action::"FundsTarget___get_transaction_history"::response{ eventResource: resource }
};

Ambos requisitos previos deben haberse completado (::response) dentro del plazo y el orden no importa. Conceda permisos para ambas acciones previas a fin de que queden registradas. Al completar solo una, la acción queda denegada hasta que la otra también se complete.

Ejemplo: umbral de aprobación

En este ejemplo, solo se permite realizar una acción después de un número mínimo de eventos que cumplan los requisitos. Solo se permite get_account_balance a un cliente si transfer_funds se han completado al menos dos en la cuenta de ese cliente, correlacionando la transferencia toAccount con la solicitud de customerId saldo:

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

La count expresión cuenta los eventos finalizados coincidentes en la ventana, y la acción se permite una vez que el recuento alcanza el umbral.

Ejemplo: bloquear una acción después de una denegación anterior

Este ejemplo bloquea una acción confidencial cuando se denegó una llamada a una herramienta anterior en la misma sesión. Una solicitud denegada se registra como un error evento y el ::error predicado coincide con dicho evento. La siguiente política prohíbe transfer_funds la denegación de una sesión get_account_balance en los últimos tres minutos:

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

Una forbid regla anula cualquier reglapermit, así que combínala con una permit que la permita transfer_funds en condiciones normales:

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

Con ambas políticas en vigor, las solicitudes de una sesión se deciden de la siguiente manera: