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.

Création de politiques temporelles

Vous créez une politique temporelle dans le langage de stratégie Dogwood et vous l'ajoutez à un moteur de stratégie, de la même manière que vous créez toute autre politique pour Policy dans AgentCore. Une politique temporelle est une forbid règle permit ou dont les conditions liées à la session sont placées dans un temporal bloc ; le principal, l'action et la ressource auxquels la règle s'applique sont écrits en utilisant la (principal, action, resource) portée standard, comme toute autre politique. Les sections suivantes montrent comment créer une politique temporelle et décrivent les modèles courants que vous pouvez exprimer.

Création d'une politique temporelle

Vous créez une politique temporelle avec l'create-policyopération, la même opération que vous utilisez pour les autres stratégies, et vous l'attachez à un moteur de politiques. L'énoncé d'une politique temporelle entre policy dans la définition, plutôt que dans le cas d'une politique apatride en cèdre. cedar

L'exemple de AWS CLI suivant crée une politique temporelle sur un moteur de politiques :

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 } };"
    }
  }'

Vous pouvez également créer une politique temporelle en la décrivant en langage naturel au lieu d'écrire vous-même la déclaration Dogwood.

Schéma de l'événement : champs auxquels vous pouvez faire référence

Les conditions à l'intérieur d'un temporal { } bloc utilisent des prédicats d'événements temporels pour correspondre à des événements spécifiques qui ont été enregistrés dans la session jusqu'à présent (jusqu'à l'action en cours d'autorisation incluse). Un prédicat nomme une fenêtre temporelle, un type d'action et d'événement, ainsi qu'un ensemble de contraintes de champ relatives à l'événement correspondant. L'create-policyexemple de la section précédente utilisait un prédicatformerly within 1h AgentCore::Action::"FundsTarget___get_account_balance"::response{ eventResource: resource, output.accountId: context.input.toAccount }, qui correspond à un get_account_balance response enregistrement enregistré au cours de la dernière heure qui output.accountId est égal à celui de toAccount la demande en cours.

Pour écrire un prédicat, vous devez savoir quels événements une action produit et quels champs chaque événement contient, car ce sont les champs qu'un prédicat peut contraindre et corréler avec ces champs. Cette section décrit ce schéma d'événement.

Chaque action produit jusqu'à trois types d'événements, nommés d'après le type d'événement dans le prédicat (::request,::response,::error) :

Le schéma temporel des événements définit ces événements pour chaque actionA. …​inputs(A)et …​outputs(A) étendez-vous aux champs d'entrée et de sortie déclarés de l'action :

// 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,
}

Dans le corps d'un prédicat, vous pouvez référencer les champs suivants de l'événement correspondant :

Pour corréler un événement enregistré à la demande en cours, comparez l'un de ces champs à une valeur de la demande en cours, telle quecontext.input.<name>.

Cas d’utilisation

Voici quelques exemples de politiques temporelles.

Outils disponibles

Les exemples de cette section utilisent une cible de passerelle nommée FundsTarget qui expose trois outils. Dans une politique, chaque outil est référencé par son nom d'action et par les champs d'entrée et de sortie répertoriés ici. FundsTarget___<tool-name>

Exemple : intégrité de la sortie vers l'entrée

Cet exemple permet à un agent de transférer des fonds uniquement vers un compte qu'il a consulté plus tôt au cours de la même session, l'empêchant ainsi de transférer des fonds vers un compte qu'il a créé. La politique transfer_funds n'autorise que lorsqu'une get_account_balance réponse plus tôt dans la session a renvoyé le même compte :

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
    }
};

Le ::response prédicat correspond à la réponse enregistrée d'une réponse antérieureget_account_balance. output.accountIdest un champ renvoyé par l'outil et context.input.toAccount correspond au compte de destination de la transfer_funds demande en cours ; le fait d'exiger qu'ils soient égaux lie le transfert à une recherche précédente.

Comme un moteur de règles refuse par défaut et qu'une action response n'est enregistrée que si elle était autorisée, vous accordez également un simple permit for get_account_balance afin que la recherche soit autorisée et enregistrée en tant que réponse dans la session :

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

Lorsque les deux politiques sont en place, les demandes présentées au cours d'une session sont décidées comme suit :

Exemple : séquençage des outils

Cet exemple n'autorise une action qu'après l'exécution d'une action préalable au cours de la même session. La politique suivante get_account_balance n'autorise que si une transfer_funds demande est survenue au cours des cinq dernières minutes :

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
    }
};

Le ::request prédicat correspond à une transfer_funds demande précédente de la session. Associez-le à un permit for pour pour transfer_funds que l'action soit autorisée et enregistrée. Lorsque les deux politiques sont en place, get_account_balance est refusé jusqu'à ce que transfer_funds a soit exécuté dans la session :

Exemple : actualisation des données

Cet exemple n'autorise une action que si une condition préalable a été remplie avec succès dans un laps de temps restreint, de sorte que les résultats périmés font expirer l'autorisation. Il get_account_balance ne permet que si j'transfer_fundsai terminé au cours des cinq dernières minutes :

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 différence par rapport au séquençage des outils ::request est de correspondre à « ::response plutôt que » : un response événement n'est enregistré que lorsque l'action s'est terminée avec succès. Cette politique exige donc une réussite récente, et pas simplement une demande préalable. La longueur de la fenêtre définit à quel point cette complétion doit être récente ; une fois la fenêtre passée, l'autorisation expire jusqu'à ce que la condition préalable soit réexécutée.

Exemple : limitation du débit en fonction des sessions

Cet exemple limite un outil à un nombre fixe d'appels au cours d'une session. La politique suivante interdit transfer_funds une fois qu'il a été appelé plus de trois fois dans les cinq minutes de la session :

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
};

L'countexpression compte les transfer_funds demandes enregistrées dans la session au cours des cinq dernières minutes, y compris la demande en cours ; lorsque ce nombre dépasse trois, l'interdiction s'applique. Associez-le à un permit for pour transfer_funds que les appels soient autorisés jusqu'à la limite. Avec les deux politiques en place, les trois premiers transfer_funds appels sont autorisés pendant une période de cinq minutes et le quatrième appel (ou un appel ultérieur) pendant cette période est refusé.

Exemple : autorisation d'utilisation unique

Dans cet exemple, chaque approbation est valable pour un usage unique. A n'transfer_fundsest autorisé que si aucun n'est terminé transfer_funds depuis la plus récente get_account_balance (l'approbation) de la session. Une fois qu'un transfert est terminé, il consomme l'approbation, et le transfert suivant est refusé jusqu'à ce qu'une nouvelle approbation soit effectuée :

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 }
};

Cette since condition est valable lorsqu'une opération terminée get_account_balance (l'approbation) a eu lieu au cours de la dernière heure et qu'aucune approbation n'transfer_fundsa été terminée depuis cette approbation. La correspondance ::response est essentielle : un transfert n'est considéré comme terminé qu'une fois qu'il a réussi, de sorte que la demande en cours d'autorisation ne se bloque pas d'elle-même. Associez-le à un permit pour get_account_balance que les approbations soient enregistrées.

Les demandes présentées au cours d'une session sont décidées comme suit :

Exemple : budget cumulé

Cet exemple plafonne la valeur totale d'une action dans une fenêtre. La politique suivante interdit transfer_funds une fois que la somme des amount données saisies lors des transferts de la session au cours des cinq dernières minutes atteint 3 000 :

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
};

L'sumexpression additionne le champ de amount saisie des transfer_funds demandes correspondantes dans la fenêtre, y compris la demande en cours ; lorsque le total atteint le seuil, l'interdiction s'applique. Le champ additionné est un champ de saisie de l'action. Associez la police à un permit pourtransfer_funds. Par exemple, avec un seuil de 3 000 et des transferts de 1 000, les deux premiers sont autorisés et le troisième, qui atteindrait 3 000, est refusé.

Comme pour la limitation du débit, la somme est limitée à la session en cours et n'est pas agrégée entre les sessions.

Exemple : refroidissement

Cet exemple applique un temps de recharge : une action ne peut pas être répétée dans un délai déterminé après sa dernière exécution. Il interdit, transfer_funds si vous avez transfer_funds terminé à la dernière minute :

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
    }
};

Cette condition est autoréférentielle : elle correspond à la même action autorisée. La correspondance ::response est ce qui fait que cela fonctionne, car la demande en cours d'autorisation n'a pas encore produit de réponse, elle ne correspond donc pas à elle-même. Une correspondance ::request ici ferait correspondre la demande en cours à son propre événement, et l'action serait définitivement interdite. Une fois la fenêtre écoulée sans qu'aucune nouvelle opération ne soit terminée, l'action est de nouveau autorisée.

Exemple : précondition continue

Cet exemple n'autorise une action que si une condition préalable est remplie : une confirmation positive s'est produite récemment et rien ne l'a invalidée depuis. Cela transfer_funds n'est autorisé que si get_account_balance (la confirmation) a été effectuée au cours des cinq dernières minutes et si aucune get_transaction_history (l'invalidation) n'a été effectuée depuis :

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 }
};

Cette since condition est valable lorsqu'une opération terminée get_account_balance s'est produite au cours des cinq dernières minutes et qu'aucune opération terminée ne get_transaction_history s'est produite depuis. Le résultat terminé get_account_balance confirme la condition préalable, et le fait d'exiger que rien ne se soit produit get_transaction_history depuis garantit que rien ne l'invalidera par la suite. Accordez des permis pour les deux get_account_balance et ils sont get_transaction_history donc enregistrés.

Exemple : chaîne à sauts multiples

Vous pouvez rédiger plusieurs politiques de séquençage pour exiger une chaîne d'actions, chacune étant autorisée uniquement une fois la précédente terminée. Cet exemple nécessite la chaîne get_account_balance → get_transaction_history →transfer_funds, en utilisant deux politiques (une par lien) :

// 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 }
};

Chaque politique impose un maillon, et la chaîne émerge de sa composition : transfer_funds exigeget_transaction_history, ce qui nécessiteget_account_balance. Accordez un permit à la première action de la chaîne afin qu'elle puisse démarrer. Une étape tentée dans le désordre est refusée tant que sa condition préalable n'est pas terminée.

Exemple : exclusion mutuelle

Cet exemple fait en sorte que deux actions s'excluent mutuellement au sein d'une fenêtre : celle qui s'exécute en premier bloque l'autre. Il utilise deux politiques d'interdiction symétriques, de sorte que l'exclusion est valable dans les deux sens. Ici, transfer_funds et les deux get_transaction_history ne peuvent pas se produire en deux minutes :

// 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 }
};

Comme chaque politique est identique::request, le simple fait de demander une action bloque l'autre : le blocage n'attend pas la fin de la première action. Vous avez besoin de deux forbid politiques symétriques, l'une par direction : l'une interdit get_transaction_history après une transfer_funds demande et l'autre interdit transfer_funds après une demande. get_transaction_history Une seule interdiction bloquerait une seule commande. Associez les deux à des autorisations pour les deux actions.

Exemple : combinaison de conditions temporelles, de garde-corps et de Cedar

Une seule police peut combiner une condition temporelle avec des conditions de garde-corps et des conditions standard en cèdre ; toutes ces conditions doivent être satisfaites pour que la politique s'applique. Cet exemple transfer_funds n'est autorisé que lorsque le montant cumulé du transfert reste inférieur à un plafond (temporel), que la demande ne contient aucune information sensible (garde-fou) et que l'appelant ne fait pas partie d'un groupe bloqué (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"
};

Le bloc temporel applique le plafond cumulatif, le bloc de protection bloque les demandes contenant les informations sensibles répertoriées et le unless bloc Cedar exclut les principaux bloqués. Chaque type de condition est évalué indépendamment et le permis ne s'applique que lorsque toutes les conditions sont remplies. Pour la syntaxe des conditions de garde-corps, voir Guardrails in policies  ; le bloc temporel se comporte comme décrit dans les exemples précédents.

Exemple : prérequis parallèles

Cet exemple nécessite que deux conditions préalables soient remplies, dans n'importe quel ordre, avant qu'une action ne soit autorisée. Il get_account_balance n'est autorisé que si transfer_funds les deux sont get_transaction_history terminés au cours de la dernière heure, en combinant deux formerly conditions avec && :

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 }
};

Les deux conditions préalables doivent être remplies (::response) dans la fenêtre, et l'ordre n'a pas d'importance. Accordez des autorisations pour les deux actions préalables afin qu'elles soient enregistrées. Si vous n'effectuez qu'une seule action, l'action est refusée jusqu'à ce que l'autre soit également terminée.

Exemple : seuil d'approbation

Cet exemple n'autorise une action qu'après un certain nombre d'épreuves qualificatives. Cela n'est get_account_balance autorisé pour un client que si au moins deux transfer_funds transactions ont été effectuées sur le compte de ce client, en corrélant le transfert toAccount avec le solde demandé : customerId

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
};

L'countexpression compte les événements terminés correspondants dans la fenêtre, et l'action est autorisée une fois que le nombre atteint le seuil.

Exemple : bloquer une action après un refus antérieur

Cet exemple bloque une action sensible lorsqu'un appel d'outil antérieur au cours de la même session a été refusé. Une demande refusée est enregistrée en tant qu'errorévénement, et le ::error prédicat correspond à un tel événement. La politique suivante interdit transfer_funds chaque fois qu'un participant get_account_balance à une session a été refusé au cours des trois dernières minutes :

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
    }
};

Une forbid règle l'emporte sur toutes les permit autres, alors associez-la à une règle permit qui permet, dans des transfer_funds conditions normales :

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

Lorsque les deux politiques sont en place, les demandes présentées au cours d'une session sont décidées comme suit :