AIエージェントのツール権限を入り口で一括管理　追加の作業は約90分

この記事は、社内でAIエージェントを動かす開発者とセキュリティ担当者に関係する内容です。

エージェントがツールを使うときの権限を扱います。ツールごとのコードではなく、入り口（Gateway）で一括管理する方法です。AIアプリを普通に使うだけの人には、変わることはありません。

AIエージェントは、AIが自分で手順を決めて、メールや予定、社内のシステムなどのツールを呼び出す仕組みです。Amazon Bedrock AgentCoreは、そのエージェントを作って動かすためのAWSのサービスです。

AWSの公式ブログによると、今回の記事は前回作ったエージェントが土台です。そのエージェントには、Okta（ID管理サービス）の認可の仕組みが備わっています。

Gatewayを入り口にして、料金と初期設定を押さえる

前回の構成では、エージェントが各ツールの場所を直接呼び出していました。エージェントの数とツールの数を掛けた分だけ、つなぎ方を用意する必要があります。

ツールが増えるたびに、そのツールを使うすべてのエージェントを直すことにもなります。今回は、エージェントは1つのGatewayにだけ話しかけ、Gatewayが宛先を決めます。

Gatewayは、Okta側が発行した認可の許可証（ID-JAG：ログインユーザーの代わりに動くことを示す許可証）を受け取ります。許可証は、Oktaに登録された決まったエージェントからのものだけを通します。そのうえで、Gatewayが各ツール用の権限を取りに行きます。

ツールを使えるかどうかは、Cedar（許可のルールを書くための言語）で書いたポリシーで決まります。判定はツールを呼び出す前に行われ、初期設定は「全部拒否」です。ルールに書いていない操作は、そもそも通りません。

資料では、読み取り用のツールに「xaa:read」、書き込み用のツールに「xaa:write」の権限を求めています。ルールの書き方にも注意点があります。権限は空白で区切られた1語として完全一致で判定されます。

そのため「xaa:write-admin」は「xaa:write」には一致しません。資料では、ポリシーを作ったら有効（ACTIVE）になったかを確かめるよう勧めています。失敗したままだと、Gatewayがすべての呼び出しを拒否します。

エージェントの処理の流れは、資料によると次のとおりです。

• ユーザーがログインし、認可の許可証が発行される
• エージェントがその許可証をAgentCore runtimeで受け取る
• エージェントが許可証をGatewayに渡す
• Cedarのポリシーで、ツールの一覧と呼び出しの両方を判定する
• 許可された呼び出しだけ、Gatewayが各ツールの権限を取得する
• ツール側で、ユーザーのグループと権限を確かめ、判断を記録する

もう1つのエージェントは、Amazon EKS（Kubernetesという実行環境）の上で動かします。Gatewayの仕組みは、エージェントがどこで動いていても同じように使えることを示すためのものです。このエージェントには読み取り権限（xaa:read）だけを与えています。

判断の記録は、AgentCore Observability（動作の記録を集める仕組み）とCloudWatch（AWSのログ監視サービス）に集められます。ツール側のauthz.checkは、ユーザーのグループ、エージェント、判定、理由を記録します。

Cedarのポリシーは、ツールごとの判定を出します。Oktaの監査ログ（System Log）は、AWSでは出力できません。そのため、Okta Log StreamingでCloudWatchへ流す設定を別に行います。

料金は2つに分けて見てください。Amazon EKSは、クラスターを管理する部分（コントロールプレーン）が1時間あたり0.10ドルです。ノードや管理手数料は別です（AWS公式の料金ページ、11/7確認）。

AgentCoreの機能は、使った分だけ払う従量課金です（AWS公式の料金ページ、11/7確認）。追加の作業は約90分の見込みと書かれています。

前回の構成で作った設定は、Okta、認証情報のプロバイダー、MCPサーバーともにそのまま使えます。エージェントの実行ロールからは、トークン交換と秘密情報の権限を外します。

権限を持つのはGatewayの側になるため、エージェント側に残る権限は減ります。