# Des barrières dans les politiques
Cette section explique comment définir les garde-corps Bedrock dans une politique. Bedrock Guardrails fournit des protections configurables qui peuvent s'exécuter à la fois sur les demandes et sur les réponses pour assurer la sécurité des applications d'IA. Vous pouvez actuellement définir une attaque rapide, un filtre de contenu et des barrières contre les informations sensibles dans les politiques. Chaque garde-corps doit être configuré avec une catégorie et un seuil compris entre 0 et 1.
Lorsqu'un garde-corps évalue le contexte, il renvoie un score de confiance compris entre 0 et 1, indiquant le degré de confiance dans lequel le contenu évalué présente la propriété définie (par exemple). `PROMPT_INJECTION`
## Disponibilité régionale des rambardes
Le tableau suivant indique quelles AWS régions sont favorables à la mise en place de garde-fous dans le cadre de leurs politiques :
| | USA Est (Virginie du Nord) | USA Est (Ohio) | USA Ouest (Oregon) | Europe (Francfort) | Europe (Irlande) | Europe (Londres) | Europe (Paris) | Europe (Stockholm) | Asie-Pacifique (Mumbai) | Asie-Pacifique (Singapour) | Asie-Pacifique (Sydney) | Asia Pacific (Tokyo) | Asie-Pacifique (Séoul) | Canada (Centre) | Amérique du Sud (São Paulo) | AWS GovCloud (US-West) |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Support pour rambardes | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | ✅ | ❌ | ❌ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
## Avant de commencer
Avant de commencer, vous devez configurer correctement votre rôle IAM.
### Permissions
Le rôle d'exécution de AgentCore passerelle configuré sur la passerelle associée à votre moteur de politiques doit disposer d'autorisations pour les AgentCore opérations Bedrock et Bedrock Guardrails. L'`bedrock:InvokeGuardrailChecks`autorisation est requise car le plan de données Policy utilise les informations d'identification FAS (Forward Access Session) dérivées du rôle d'exécution de la passerelle pour appeler l'API Bedrock Guardrails en votre nom.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "bedrock-agentcore:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "bedrock:InvokeGuardrailChecks",
"Resource": "*"
}
]
}
```
### Rambardes soutenues
| Nom de la sauvegarde | Type d'entité | Catégories de sauvegarde |
| --- | --- | --- |
| Filtre de contenu | `ContentFilter` | `VIOLENCE`, `HATE`, `SEXUAL`, `MISCONDUCT`, `INSULTS` |
| Détection rapide des attaques | `PromptAttack` | `JAILBREAK`, `PROMPT_INJECTION`, `PROMPT_LEAKAGE` |
| Informations sensibles | `SensitiveInformation` | `CREDIT_DEBIT_CARD_NUMBER`,`US_SOCIAL_SECURITY_NUMBER`,`EMAIL`,`PHONE`,`ADDRESS`,`AWS_ACCESS_KEY`,`AWS_SECRET_KEY`,,`PASSWORD`, `IP_ADDRESS` `NAME``USERNAME`, et plus de [20 autres](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-sensitive-filters.html) |
## Définition des barrières de sécurité dans les politiques
Pour définir des garde-fous dans une politique, vous pouvez soit écrire une politique sous forme de code, soit la décrire en langage naturel. Comme pour toutes les politiques existantes que vous avez peut-être déjà créées, vous devez spécifier un effet (par exemple`permit`) avec une condition (`when guardrails`). Dans cette condition, vous devez fournir le garde-corps spécifique que vous souhaitez activer, la catégorie de protection à utiliser, le contexte que vous souhaitez que le garde-corps évalue et le seuil de confiance.
**Exemple de définition de garde-corps**
```
suppressOutput (principal, action == AgentCore::Action::"_:", resource == AgentCore::Gateway::"")
when guardrails {
BedrockGuardrails::ContentFilter(["HATE"],[context.output.message])["HATE"]
.confidenceScore
.greaterThan(decimal("0.2"))
};
```
### Spécification d'un dispositif de protection pour garde-corps
Pour choisir un type d'entité de sauvegarde spécifique, utilisez l'espace de BedrockGuardrails noms :
| Sauvegarder | Nom de la fonction de garde-corps |
| --- | --- |
| Filtre de contenu | `BedrockGuardrails::ContentFilter` |
| Attaque rapide | `BedrockGuardrails::PromptAttack` |
| Informations sensibles | `BedrockGuardrails::SensitiveInformation` |
### Sélection d'une catégorie de sauvegarde
Sélectionnez une catégorie pour la protection donnée (voir[Rambardes soutenues](#supported-guardrails)).
par ex. `BedrockGuardrails::ContentFilter(["HATE"],[context.output.message])`
### Effets pour les rambardes
Pour créer des garde-corps à utiliser dans les demandes d'autorisation, utilisez les effets `permit` et`forbid`. Elles continuent de régir l'autorisation des demandes.
```
forbid (principal, action == AgentCore::Action::"___POST:/invocations", resource) when guardrails {
BedrockGuardrails::PromptAttack(["PROMPT_INJECTION"], [context.input.prompt])["PROMPT_INJECTION"].confidenceScore.greaterThan(decimal("0.6"))
};
```
Pour créer des garde-corps destinés à supprimer les sorties des outils, des agents ou des modèles, utilisez l'effet. `suppressOutput` `suppressOutput`est un nouvel effet qui agit sur les données renvoyées par une action. Une fois qu'une action autorisée est terminée, il évalue les sorties par rapport au garde-corps et supprime la sortie lorsque le garde-corps est violé.
```
suppressOutput (principal, action == AgentCore::Action::"___POST:/invocations", resource) when guardrails {
BedrockGuardrails::SensitiveInformation(["US_SOCIAL_SECURITY_NUMBER"], [context.output.text])["US_SOCIAL_SECURITY_NUMBER"]
.confidenceScore
.greaterThan(decimal("0.5"))
};
```
### Transmettre le contexte à votre garde-corps
Lorsque vous définissez des barrières de sécurité dans la politique, vous devez spécifier des chemins de données (par exemple`context.input.message`) qui identifient les valeurs à extraire de la charge utile de l'action. Le garde-corps évalue les valeurs extraites. Vous pouvez spécifier un ou plusieurs chemins d'accès aux données en fonction de votre schéma de demande ou de réponse.
par ex. `[context.input.message, context.input.systemPrompt]`
### Seuils pour les rambardes
Grâce aux filtres de contenu et à la détection rapide des attaques, le garde-corps renvoie un score de confiance, qui est une valeur numérique comprise dans la plage [0, 1], où 0 correspond à un niveau de confiance faible et 1 à un niveau de confiance élevé. Le score représente le degré de confiance avec lequel le garde-corps a détecté une violation. Les scores possibles actuels sont des valeurs discrètes {0, 0,2, 0,4, 0,6, 0,8 et 1,0}.
Pour définir un seuil, vous devez fournir la valeur décimale à l'opérateur de comparaison (par exemple`greaterThan(decimal("0.4"))`).
**Opérateurs de comparaison de scores**
Vous pouvez appliquer les opérateurs de comparaison ci-dessous à n'importe lequel des `confidenceScore``maxConfidenceScore()`, ou `minConfidenceScore()` :
| Opérateur | Usage |
| --- | --- |
| `.greaterThan(decimal("X.X"))` | Score > seuil |
| `.greaterThanOrEqual(decimal("X.X"))` | Score ≥ seuil |
| `.lessThan(decimal("X.X"))` | Score inférieur au seuil |
| `.lessThanOrEqual(decimal("X.X"))` | Score ≤ seuil |
Vous pouvez utiliser une agrégation dans votre politique pour extraire et comparer les scores renvoyés par les garde-fous :
**Agrégations**
| Agrégation | Description | Exemple |
| --- | --- | --- |
| `[].confidenceScore` | Accédez au score de confiance pour une catégorie spécifique ([décimal](https://docs.cedarpolicy.com/policies/syntax-datatypes.html#datatype-decimal)) | `["HATE"].confidenceScore` |
| `maxConfidenceScore()` | Confiance maximale dans toutes les catégories numérisées ([décimal](https://docs.cedarpolicy.com/policies/syntax-datatypes.html#datatype-decimal)) | `.maxConfidenceScore()` |
| `minConfidenceScore()` | Confiance minimale pour toutes les catégories numérisées ([décimal](https://docs.cedarpolicy.com/policies/syntax-datatypes.html#datatype-decimal)) | `.minConfidenceScore()` |
| `count()` | Nombre de résultats détectés ([long](https://docs.cedarpolicy.com/policies/syntax-datatypes.html#datatype-long)) | `.count()` |
#### Comment choisir un seuil
Si vous ne spécifiez pas de seuil lorsque vous demandez au service de création, AgentCore définit une valeur par défaut. Si vous rédigez vos politiques sans l'aide du service de création, vous devez fournir la valeur de seuil.
Les valeurs par défaut ci-dessous sont calibrées pour fournir une couverture étendue avec une précision acceptable pour la plupart des charges de travail :
| Sauvegarder | Seuil par défaut |
| --- | --- |
| Filtre de contenu | 0.2 |
| Détection rapide des attaques | 0.4 |
| Informations sensibles | 0.2 |
##### Choix d'un seuil personnalisé
Si les seuils par défaut ne répondent pas à vos exigences, vous pouvez déterminer le seuil optimal pour votre charge de travail en utilisant l'une des approches suivantes.
**Option 1 : évaluer par rapport à un ensemble de tests de référence**
Utilisez cette approche lorsque vous disposez d'un ensemble de tests sélectionnés avec des résultats attendus clairs.
1. Créez vos politiques et définissez le mode de votre moteur de politiques sur LOG\_ONLY.
1. Exécutez votre ensemble de tests via la passerelle à laquelle votre moteur de politiques est connecté.
1. Consultez les journaux de chaque évaluation. Chaque entrée du journal inclut le contenu évalué et le score de confiance renvoyé par le garde-corps.
1. Pour chaque résultat, indiquez si le garde-corps aurait dû signaler le contenu ou ne rien faire (vrai et faux respectivement).
1. À l'aide de ces étiquettes, combinées aux scores de confiance disponibles dans vos journaux, créez une matrice de confusion à plusieurs valeurs de seuil. Comparez la précision et le rappel à chaque seuil pour sélectionner la valeur correspondant à votre tolérance aux faux positifs par rapport aux détections manquées.
**Option 2 : évaluation par rapport au trafic de production**
Utilisez cette approche lorsque vous ne disposez pas d'un ensemble de tests prédéfini et que vous souhaitez effectuer un étalonnage en utilisant des modèles de trafic réels.
1. Créez vos politiques et définissez le mode de votre moteur de politiques sur LOG\_ONLY.
1. Permettez au moteur de politiques d'évaluer le trafic de production. Chaque entrée du journal inclut le contenu évalué et le score de confiance renvoyé par le garde-corps.
1. Utilisez an LLM-as-a-judge pour étiqueter chaque résultat enregistré comme vrai (le garde-corps aurait dû signaler le contenu) ou faux (le garde-corps n'aurait pas dû signaler le contenu).
1. À l'aide de ces étiquettes, créez une matrice de confusion à plusieurs valeurs de seuil. Comparez la précision et le rappel à chaque seuil pour sélectionner la valeur correspondant à votre tolérance aux faux positifs par rapport aux détections manquées.
### Mettre à l'essai les garde-fous dans les politiques
AgentCore fournit plusieurs mécanismes pour tester les politiques de garde-corps avant de les appliquer au trafic de production. Vous pouvez contrôler l'application au niveau du moteur de politiques, au niveau des politiques individuelles, ou les deux, ce qui vous permet de valider le comportement des garde-corps de manière incrémentielle. Voir [tester une politique](policy-test-a-policy.md) pour plus d'informations.
## Comment les garde-corps fonctionnent avec les politiques
Les politiques de garde-corps peuvent être appliquées à n'importe quelle cible de passerelle. Les barrières de sécurité s'exécutent sur :\* **cibles MCP** — `POST /mcp` (JSON-RPC `tools/call`) \* cibles **d'exécution HTTP — \* cibles d'**`POST //invocations`inférence **HTTP** — `POST /inference`
Lorsqu'un appel arrive à votre passerelle, l'évaluateur de politiques effectue les opérations suivantes :
1. **Correspond au champ d'application** — Identifie les politiques de garde-corps applicables à cette demande
1. **Extrait le contenu** — Extrait le champ spécifié par `dataPath` (par exemple`context.input.message`) du corps de la demande
1. **Appelle InvokeGuardrailChecks l'API Bedrock** — Évalue le contenu et injecte les scores de confiance renvoyés dans le contexte de l'évaluation des politiques
1. **Évalue la politique à l'aide des scores de protection : compare les scores** de confiance renvoyés par rapport au seuil défini dans la politique
1. **Renvoie une décision**, `ALLOW` ou `DENY` avec des annotations de politique, à la passerelle
Remarque : Les rambardes ne sont pas déterministes. La même entrée peut donner lieu à des sorties différentes. Les politiques, cependant, sont déterministes, les mêmes entrées produiront toujours les mêmes résultats.
## Limites des glissières de sécurité dans la politique
+ **Aucune prise en charge des regex ou de la correspondance de modèles** : les garde-fous utilisent le score ML, et non les expressions régulières
+ **Vous ne pouvez pas mélanger les politiques standard de Cedar avec des garde-corps** : remplace `when guardrails {…}` `when {…}`
+ **Un garde-corps est requis dans un `when guardrails {…}` bloc** ; les blocs de garde-corps doivent comporter au moins un garde-corps défini à l'intérieur