ポリシーのガードレール

このセクションでは、 ポリシーで Bedrock ガードレールを定義する方法について説明します。Bedrock ガードレールは、AI アプリケーションを安全に保つために、リクエストとレスポンスの両方で実行できる設定可能な保護を提供します。現在、ポリシーでプロンプト攻撃、コンテンツフィルター、機密情報ガードレールを定義できます。各ガードレールは、カテゴリと 0～1 のしきい値で設定する必要があります。

ガードレールがコンテキストを評価すると、0～1 の信頼スコアが返され、評価されたコンテンツが定義されたプロパティ (例: PROMPT_INJECTION) を示す信頼度を示します。

ガードレールのリージョンの可用性

次の表は、ポリシーでガードレールをサポートしている AWS リージョンを示しています。

[開始する前に]

開始する前に、IAM ロールを適切に設定する必要があります。

アクセス許可

ポリシーエンジンに関連付けられたゲートウェイで設定された AgentCore Gateway 実行ロールには、Bedrock AgentCore オペレーションと Bedrock ガードレールの両方に対するアクセス許可が必要です。ポリシーデータプレーンは、ゲートウェイの実行ロールから派生した FAS (フォワードアクセスセッション) 認証情報を使用して、ユーザーに代わって Bedrock ガードレール API を呼び出すため、 アクセスbedrock:InvokeGuardrailChecks許可が必要です。

{
  "Version": "2012-10-17", 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "bedrock-agentcore:*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "bedrock:InvokeGuardrailChecks",
      "Resource": "*"
    }
  ]
}

サポートされているガードレール

ポリシーでのガードレールの定義

ポリシーでガードレールを定義するには、ポリシーをコードとして記述するか、自然言語で記述します。作成済みの既存のポリシーと同様に、条件 () で効果 (例: permit) を指定する必要がありますwhen guardrails。条件では、有効にする特定のガードレール保護、使用する保護のカテゴリ、ガードレール保護で評価するコンテキスト、および信頼スコアのしきい値を指定する必要があります。

ガードレール定義の例

suppressOutput (principal, action == AgentCore::Action::"<TARGET_NAME>_<METHOD>:<URI>", resource == AgentCore::Gateway::"<GATEWAY_ARN>")
when guardrails {
    BedrockGuardrails::ContentFilter(["HATE"],[context.output.message])["HATE"]
    .confidenceScore
    .greaterThan(decimal("0.2"))
};

ガードレール保護の指定

特定の保護エンティティタイプを選択するには、BedrockGuardrails 名前空間を使用します。

保護カテゴリの選択

指定された保護のカテゴリを選択します (「」を参照サポートされているガードレール)。

例: BedrockGuardrails::ContentFilter(["HATE"],[context.output.message])

ガードレールの効果

認可リクエストで使用するガードレールを作成するには、 permit および forbid効果を使用します。これらは引き続きリクエスト認可を管理します。

forbid (principal, action == AgentCore::Action::"<TargetName>___POST:/invocations", resource) when guardrails {
  BedrockGuardrails::PromptAttack(["PROMPT_INJECTION"], [context.input.prompt])["PROMPT_INJECTION"].confidenceScore.greaterThan(decimal("0.6"))
};

ツール、エージェント、またはモデルからの出力の抑制に使用するガードレールを作成するには、 suppressOutput効果を使用します。 suppressOutputは、アクションが返すデータで動作する新しい効果です。承認されたアクションが完了すると、ガードレールに対して出力を評価し、ガードレールの違反時に出力を抑制します。

suppressOutput (principal, action == AgentCore::Action::"<TargetName>___POST:/invocations", resource) when guardrails {
  BedrockGuardrails::SensitiveInformation(["US_SOCIAL_SECURITY_NUMBER"], [context.output.text])["US_SOCIAL_SECURITY_NUMBER"]
    .confidenceScore
    .greaterThan(decimal("0.5"))
};

ガードレールにコンテキストを渡す

ポリシーでガードレールを定義するときは、アクションのペイロードから抽出する値を識別するデータパス ( などcontext.input.message) を指定する必要があります。ガードレールは抽出された値を評価します。リクエストまたはレスポンススキーマに基づいて、データへの 1 つ以上のパスを指定できます。

例: [context.input.message, context.input.systemPrompt]

ガードレールのしきい値

コンテンツフィルターとプロンプト攻撃検出では、ガードレールは信頼スコアを返します。これは [0, 1] の範囲の数値で、0 は低い信頼度、1 は高い信頼度です。スコアは、ガードレールが違反を検出した信頼度を表します。現在の可能なスコアは、離散値 {0、0.2、0.4、0.6、0.8、1.0} です。

しきい値を設定するには、比較演算子に 10 進値を指定する必要があります (例: greaterThan(decimal("0.4")))。

スコア比較演算子

以下の比較演算子は、confidenceScore、、maxConfidenceScore()または のいずれかに適用できますminConfidenceScore()。

ポリシーの集計を使用して、ガードレールによって返されるスコアを抽出および比較できます。

集計

しきい値を選択する方法

オーサリングサービスをプロンプトするときにしきい値を指定しない場合、AgentCore はデフォルト値を設定します。オーサリングサービスの助けを借りずにポリシーを記述する場合は、しきい値を指定する必要があります。

以下のデフォルトは、ほとんどのワークロードに許容可能な精度で広範なカバレッジを提供するようにキャリブレーションされています。

カスタムしきい値の選択

デフォルトのしきい値が要件を満たしていない場合は、次のいずれかのアプローチを使用してワークロードの最適なしきい値を決定できます。

オプション 1: ゴールデンテストセットに対して評価する

このアプローチは、期待される結果が明確で、厳選された一連のテスト入力がある場合に使用します。

オプション 2: 本番トラフィックと照らし合わせて評価する

このアプローチは、事前に構築されたテストセットがなく、実際のトラフィックパターンを使用してキャリブレーションする場合に使用します。

ポリシーでガードレールをテストする

AgentCore は、本番トラフィックにガードレールポリシーを適用する前に、ガードレールポリシーをテストするための複数のメカニズムを提供します。ポリシーエンジンレベル、個々のポリシーレベル、またはその両方で強制を制御できるため、ガードレールの動作を段階的に検証できます。詳細については、「ポリシーのテスト」を参照してください。

ガードレールとポリシーの連携方法

ガードレールポリシーは、任意のゲートウェイターゲットに適用できます。ガードレールの実行先: * MCP ターゲット — POST /mcp (JSON-RPC tools/call) * HTTP ランタイムターゲット — POST /<target>/invocations * HTTP 推論ターゲット — POST /inference

通話がゲートウェイに到着すると、ポリシーエバリュエーターは以下を実行します。

注: ガードレールは非決定的です。同じ入力では、異なる出力が発生する可能性があります。ただし、ポリシーは決定論的であり、同じ入力は常に同じ出力になります。

ポリシーのガードレールの制限