Exemples de politiques temporelles

Les politiques décrites dans cette section se basent sur ce qui s'est déjà passé plus tôt au cours de la même session. Ils vous permettent d'exiger une approbation avant un versement, d'expirer une autorisation périmée, de plafonner un total cumulé ou de bloquer une action après un échec. Aucune demande ne contient suffisamment d'informations pour décider de l'une ou l'autre de ces questions.

Chaque exemple autorise la passerelle de référence décrite dans Configuration des ressources pour les exemples. Pour le schéma des événements temporels, les opérateurs, les identifiants de session, les quotas et la disponibilité des régions, voir Politiques temporelles et Création de politiques temporelles.

Avant d'utiliser ces exemples

Quatre facteurs déterminent si une politique temporelle se comporte comme vous le souhaitez.

Un identifiant de session est requis

L'historique temporel est limité à une session que vous nommez. Envoyez un identifiant de session dans l'x-amzn-bedrock-agentcore-policy-session-iden-tête de chaque demande, en commençant par la première. La passerelle n'en génère pas pour vous, et si le moteur contient une politique temporelle, une demande sans ID de session échoue à la validation.

Seules les actions autorisées deviennent response des événements

Une action enregistre un response événement uniquement si une politique l'a autorisé et s'il est terminé. Une action refusée enregistre plutôt un error événement. Chacun des exemples suivants nécessite donc également un clair permit pour l'action préalable, sinon la condition préalable est refusée, jamais enregistrée en tant que aresponse, et la condition temporelle ne pourra jamais correspondre. Chaque exemple indique ce qui permet de le coupler avec.

eventResource: resourceest obligatoire

Chaque prédicat doit inclureeventResource: resource, ce qui lie l'événement correspondant à la ressource comprise dans le champ d'application de la politique. Son omission est rejetée avectemporal predicates do not constrain the matched event to the current request’s resource. Vous n'avez pas besoin d'écrire sessionId : le schéma d'événement étend déjà chaque prédicat à la session en cours.

Les comparaisons ordonnées ont besoin d'entiers ; l'égalité n'en a pas

À l'intérieur d'un temporal { } bloc, les deux types de comparaison acceptent des types différents.

• La commande —<,⇐,>, >= — nécessite un integer recto verso. A decimal ou a string est rejeté lorsque vous créez la politique, aveccomparison requires numeric operands on both sides.

• L'égalité — == et != — fonctionne sur tous les types, à condition que les deux parties soient du même type. C'est ce qu'utilise la corrélation : la mise en correspondance input.claimId context.input.claimId compare deux chaînes, ce qui est pris en charge.

Modélisez donc toute valeur d'une politique temporelle par rapport à un total ou à un seuil en tant queinteger. C'est pourquoi la passerelle de référence indique la monnaie en unités mineures entières sur les outils que ces exemples regroupent. La sommation a la même exigence et son propre message : sum nécessite une integer sommation. Pour plus d'informations, consultez la section Types de paramètres dans les conditions.

Exiger une approbation préalable pour la même réclamation

Intention : autoriser le versement d'un paiement uniquement pour une réclamation approuvée plus tôt au cours de la session, afin que l'agent ne puisse pas effectuer le versement contre un numéro de réclamation qu'il a inventé.

Le ::response prédicat correspond à un terminéapprove_claim. C'context.input.claimIdest en le corrélant output.claimId avec la demande actuelle que le versement est lié à cette approbation spécifique. En l'absence de corrélation, toute approbation au cours de la session autoriserait le paiement d'une réclamation.

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

Important

output.*les champs n'existent sur un response événement que lorsque la cible déclare un schéma de sortie pour l'outil. De nombreuses cibles ne le font pas. Une cible Lambda, par exemple, déclare généralement uniquement les entrées, puis l'événement ne contient queeventPrincipal, eventResource input.*requestId, et. sessionId

Si vous nommez un champ que l'événement ne déclare pas, le service rejette la politique et l'erreur indique ce qui 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)

Utilisez cette liste pour voir sur quoi vous pouvez établir une corrélation. Lorsqu'aucun champ de sortie n'existe, établissez une corrélation sur un champ de saisie partagé : input.claimId: context.input.claimId associez les deux appels à la même réclamation sans avoir besoin de l'outil précédent pour renvoyer quoi que ce soit.

Les deux ne sont pas équivalents, alors choisissez délibérément. Une corrélation d'entrée correspond à ce que l'appel précédent a demandé ; une corrélation de sortie correspond à ce qu'il a renvoyé. Si votre règle dépend d'une valeur produite par l'outil précédent (un ID d'approbation, un montant calculé), seule une corrélation de sortie l'applique, ce qui oblige la cible à déclarer un schéma de sortie.

Associez-le à un simple permis pour que les approbations soient autorisées et enregistrées :

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

Séquence de demandes dans une session	Décision
disburse_paymentsans approbation préalable	REJETER
approve_claimpour une réclamation, puis disburse_payment pour la même réclamation	AUTORISER
approve_claimpour une demande, puis disburse_payment pour une autre	REJETER

Exiger une action préalable

Intention : autoriser l'approbation d'une réclamation uniquement après que quelqu'un a consulté son statut au cours de la session.

L'appariement ::request signifie que la condition préalable doit seulement avoir été essayée, pas avoir réussi. À associer avec un permis pourget_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
    }
};

Exiger un réussi prérequis, récemment

Intention : autoriser l'approbation uniquement si une recherche de statut s'est terminée au cours des cinq dernières minutes, de sorte qu'une recherche périmée cesse de conférer une autorisation.

Le seul changement par rapport à l'exemple précédent est ::response à la place de::request, et il s'agit de la différence entre « tentative » et « réussite ». La longueur de la fenêtre indique à quel point ce succès doit être récent ; une fois qu'il est passé, l'autorisation expire jusqu'à ce que le prérequis soit à nouveau exécuté.

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

Séquence de demandes dans une session	Décision
approve_claimavant toute recherche terminée	REJETER
la recherche se termine, puis approve_claim dans la fenêtre	AUTORISER
approve_claimune fois la fenêtre écoulée	REJETER

Limitez le nombre de fois qu'une action est exécutée

Objectif : Permettre au maximum trois décaissements par session de cinq minutes.

countcompte les événements correspondants dans la fenêtre, y compris la demande autorisée, de sorte que le quatrième appel dans une fenêtre est le premier à être refusé. Le exists (n: Long) classeur capture le nombre afin que le n > 3 filtre puisse le tester ; l'agrégat a besoin de parenthèses à gauche de==. Couplez avec un permis pour disburse_payment que les appels soient autorisés jusqu'à la limite.

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

Important

Il ne s'agit pas d'un contrôle de sécurité. L'appelant fournit l'identifiant de session, afin de pouvoir réinitialiser le décompte en démarrant une nouvelle session. Utilisez-le pour façonner le comportement au sein d'une session coopérative (pour arrêter un agent en boucle, par exemple) et non pour imposer une limite à un appelant qui contrôle son propre identifiant de session. Pour plus d'informations, consultez la section Considérations relatives à la sécurité.

Plafonner un total cumulé

Intention : Autoriser les versements jusqu'à ce qu'ils atteignent un total de 3 000 dollars dans les cinq minutes, puis arrêter.

sumajoute le champ de saisie nommé à travers les événements correspondants, y compris la demande en cours, de sorte qu'une demande qui franchirait le seuil soit celle refusée. Avec un plafond de 300 000 cents et des décaissements de 100 000 dollars, les deux premiers sont autorisés et le troisième est refusé.

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

Le domaine à deux variables est obligatoire : for (amt: Long), (t: Timepoint) est-ce que la valeur amt est additionnée et t distingue les points temporels, de sorte que deux décaissements du même montant sont comptés deux fois plutôt que dédupliqués en un seul.

Note

amountCentsest un schéma integer intégré à l'outil, et c'est ce qui permet à cette politique de fonctionner. L'sumagrégation nécessite une somme d'entiers, et la comparaison d'ordre total nécessite un entier des deux côtés. Un champ déclaré par votre schéma number ne peut donc pas être plafonné comme celui-ci. Pour connaître les règles de type dont dépendent ces exemples, voir Avant d'utiliser ces exemples.

Faites en sorte que chaque approbation soit valable pour un usage unique

Intention : Permettre un versement par approbation. Après un paiement, demandez une nouvelle approbation.

L'sinceopérateur maintient la position lorsque l'ancre à sa droite est apparue dans la fenêtre et que la situation à sa gauche est restée inchangée depuis lors. Ici, cela se lit comme suit : une approbation a été effectuée au cours de la dernière heure, et aucun versement n'a été effectué depuis. Le premier versement après une approbation le consomme.

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

Il est essentiel de faire correspondre ::response le côté négatif. La demande autorisée n'a pas encore produit de réponse, elle ne se bloque donc pas d'elle-même. Si vous ::request y répondez, chaque versement serait refusé.

Séquence de demandes dans une session	Décision
approve_claim, puis disburse_payment	AUTORISER
une seconde disburse_payment sans nouvelle approbation	REJETER
un nouveauapprove_claim, puis disburse_payment	AUTORISER

Note

Un response événement est enregistré peu après la fin de l'appel. Attendez le retour de l'approbation avant d'effectuer le versement plutôt que de les renvoyer dos à dos. Pour plus d'informations, consultez la section Séquençage des actions qui dépendent d'une réponse antérieure.

Imposez un temps de refroidissement

Intention : Empêcher la même action de se répéter dans la minute qui suit son exécution.

Cette condition fait référence à la même action qu'elle autorise. ::responsec'est ce qui le rend sûr : la demande en cours n'a pas encore de réponse, elle ne correspond donc pas à elle-même. Rédigée avec::request, la demande en cours correspondrait à son propre événement et l'action serait définitivement interdite. Pour plus d'informations, voir Self-referential les conditions incluent la demande en cours.

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

Exiger une condition préalable qui n'a pas été invalidée

Intention : Autoriser le décaissement tant qu'une approbation est en cours et retirer l'autorisation si la demande est rouverte pour examen du statut par la suite.

Cela a la même forme que l'approbation à usage unique, mais l'action annulée est différente de l'action autorisée, qui transforme « consommer l'approbation » en « invalider l'approbation ». Accordez des permis pour les deux approve_claim etget_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 }
};

Séquence de demandes dans une session	Décision
disburse_paymentavant toute approbation	REJETER
approve_claim, puis disburse_payment	AUTORISER
get_claim_statusse produit, puis disburse_payment	REJETER
un nouveauapprove_claim, puis disburse_payment	AUTORISER

Exiger une chaîne d'actions dans l'ordre

Intention : Exiger la recherche de l'état de la séquence, puis l'approbation, puis le décaissement.

Une politique par maillon, et la chaîne émerge de leur composition. Accordez un simple permis pour la première action afin que la chaîne puisse démarrer. Une étape désordonnée est refusée tant que la condition préalable requise n'est pas terminée.

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

Exiger deux prérequis dans n'importe quel ordre

Intention : Autoriser le versement uniquement une fois la recherche du statut et l'approbation terminées, dans l'un ou l'autre ordre.

Deux formerly conditions associées && nécessitent les deux, et aucune ne limite la commande. Cela utilise deux des trois opérateurs temporels qu'une seule politique peut contenir.

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

Rendre deux actions incompatibles

Intention : Dans les deux minutes, autorisez le versement ou la suppression d'une réclamation, mais pas les deux.

L'exclusion nécessite deux politiques symétriques, une par direction ; une seule ne forbid bloquerait qu'une seule commande. Faire correspondre ::request signifie simplement tenter une action pour bloquer l'autre, sans attendre qu'elle soit terminée.

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

Exiger un nombre seuil d'événements

Intention : Permettre la suppression d'une réclamation uniquement après qu'au moins deux décaissements ont été effectués à son encontre.

La corrélation input.claimId avec la réclamation de la demande en cours permet d'évaluer le montant de cette réclamation plutôt que de compter tous les décaissements effectués au cours de la session.

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

Note

countcompte les événements, pas les appelants distincts. Il ne peut pas exprimer « approuvé par deux personnes différentes », car rien n'empêche un directeur de produire tous les événements correspondants. Pour une approbation multipartite, établissez une corrélation avec une politique extérieure de distinction eventPrincipal ou appliquez-la.

Bloquer une action après un refus antérieur

Intention : empêcher le déboursement d'une session après le refus de toute tentative d'approbation.

Un error événement enregistre une demande qui a été refusée ou qui a échoué, tout ::error comme la façon dont une politique réagit à un échec antérieur. Associez-le à un permis ordinaire pour disburse_payment qu'il soit autorisé dans des conditions 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
    }
};

Il s'agit d'un modèle de confinement utile : un agent qui recherche des autorisations dont il ne dispose pas est privé de l'action sensible au lieu d'être autorisé à continuer d'essayer.

Combinez les conditions temporelles, de garde-corps et de demande

Intention : Permettre à un appelant de déposer des réclamations, à condition que la session ait reçu moins de trois demandes au cours des dernières 24 heures, que la description de la réclamation ne comporte aucune information bancaire et que le rôle de l'appelant ne soit pas restreint.

Les trois types de conditions sont regroupés dans une seule politique, et chaque clause doit être valide pour permit qu'elle s'applique. Le temporal bloc applique le plafond, le when bloc filtre le contenu et le unless bloc exclut un rôle. Chacun est évalué de manière indépendante.

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

Les écrans de garde-corpsdescription, qui sont le seul paramètre de texte libre pris en compte. file_claim Pointez un garde-fou contenant des informations sensibles sur un champ qui pourrait vraisemblablement contenir les données que vous recherchez. Si vous la pointez sur un identifiant ou un numéro, elle n'a rien à détecter et la clause passe silencieusement. descriptionest facultatif, donc une demande qui l'omet ne donne aucun texte au garde-corps et la clause est maintenue.

Qu'est-ce qui change lorsque vous modifiez une politique temporelle

L'ajout ou la mise à jour d'une politique temporelle sur un moteur invalide les sessions temporelles ouvertes de ce moteur, car l'historique enregistré ne correspond plus aux règles qui lui sont appliquées. La demande suivante qui réutilise une session invalidée échoue avec le protocole HTTP 409ConflictException. Démarrez une nouvelle session et réessayez ; la nouvelle session commence avec un historique vide et est évaluée par rapport aux politiques mises à jour.

Important

Prévoyez cela lorsque vous déployez un changement de politique temporel. Les clients doivent traiter a 409 comme « démarrer une nouvelle session ». Tout flux de travail en plusieurs étapes redémarre plutôt que de reprendre.