はじめに
LLMやAIエージェントを触っていますが、最近はPoCの段階をこえて実務でも実際に利用され始めていると感じます。そんな中、認証・認可を意識した構築が必要になってきている段階だと感じています。恥ずかしながら私は認証・認可についての理解が曖昧なので、知識の整理もかねてアウトプットしていきたいと思います。
結論
- 認証：本人確認のプロセス
- 認可：権限確認のプロセス
身近な例
オンラインバンキングを例にすると以下のように説明できます。
- 認証：ログインID・パスワード + ワンタイムパスワードで「あなたが口座の持ち主本人である」ことを確認
- 認可：ログイン後、「残高照会はできるが、振込限度額は1日100万円まで」という権限を付与
簡潔に書くと以上！
...なのですが、より詳細に見ていきたいと思います。
認証とは
前述の通り、認証（Authentication）とは、「あなたは誰ですか？」という本人確認のプロセスです。
認証の方式
認証の方式には以下のような方式があります。
- 知識認証：パスワード、PINコード
- 所有物認証：スマートフォン、ハードウェアトークン
- 生体認証：指紋、顔認証
- 多要素認証（MFA）：上記の複数を組み合わせ
認可とは
こちらも前述の通り、認可（Authorization）は「あなたは何ができますか？」という権限確認のプロセスです。
AWSにおける認可の仕組み
AWSではIAMポリシーによる認可が行われています。以下に例を示します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::my-bucket/*"
]
}
]
}
こちらの例では、「my-bucket というS3バケットに置かれているすべてのオブジェクトに対して、読み取りのみを許可」という認可を定義しています。
ポリシーについては（まずは単一アカウントのケースから）近いうちに整理して記事化したいと思います。
セッション管理について
認証が成功した後、毎回認証情報を送信するのは非効率的でセキュリティリスクもあります。そこでセッション管理が重要になります。
セッショントークンの仕組み
- 認証成功時：サーバーが一意のセッショントークンを発行
- 以降のリクエスト：クライアントはトークンを送信するだけでOK
- 有効期限：セキュリティのため、一定時間で無効化
JWTトークンの例
以下はJWTトークンの例です。JWTトークン（JSON Web Token）は、認証情報を安全に送受信するための業界標準規格（RFC 7519）です。Base64エンコードされた3つの部分（ヘッダー・ペイロード・署名）をピリオドで連結した形式で、改ざん検知が可能です。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwiZXhwIjoxMjM0NTY3ODkwfQ.signature_here
{
"header": {
"alg": "HS256",
"typ": "JWT"
},
"payload": {
"sub": "user123",
"exp": 1234567890, // 有効期限
"roles": ["read", "write"] // 権限情報も含められる
},
"signature": "..."
}
リフレッシュトークンの活用
セキュリティと利便性のバランスを取るためにリフレッシュトークンが利用されます。リフレッシュトークンとは、アクセストークンの有効期限が切れた際に、再認証なしで新しいアクセストークンを取得するための長期間有効なトークンです。
- アクセストークン：短期間（15分〜1時間）有効、API呼び出しに使用
- リフレッシュトークン：長期間（数日〜数週間）有効、新しいアクセストークンの取得に使用
リフレッシュトークンにより、頻繁な再ログインを避けつつ、アクセストークンが漏洩した場合の被害を最小限に抑えることができます。
（参考）AWSにおける認証・認可のベストプラクティス
以下ドキュメントで IAM でのセキュリティのベストプラクティスについて解説されているので興味のある方はご覧ください。
AIエージェントにおける認証・認可の課題についての考察
エージェントの自律性による権限管理の複雑化
従来のシステムと異なり、エージェントが自律的に行動を決定するため権限のスコープ設定が複雑化すると考えます。
対応策
このような課題に対しては、まず最小権限の原則を徹底することが重要です。エージェントには最初から全ての権限を与えるのではなく、必要最小限の権限から始めて、段階的に権限を拡張していく仕組みを構築します。
また、動的な権限要求システムの実装も効果的です。エージェントが追加の権限を必要とする場面では、自動的に処理を進めるのではなく、人間の承認を経て一時的な権限を付与する仕組みを導入することで、予期しない操作を防ぐことができます。
プロンプトインジェクション
悪意のあるプロンプトにより、開発者が設定した権限を超えた権限による操作が発生する可能性があります。
対応策
プロンプトインジェクションへの対策は、防御・検知・対応の3段階で構築することが有効だと考えます。
防御段階
防御段階では、入力プロンプトの検証を実施します。単純なキーワードマッチングだけでなく、文脈を理解した上での検出が必要です。例えば「以前の指示を無視して」といった典型的な攻撃パターンの検出に加え、Amazon Bedrock Guardrailsなどの専門サービスを活用することで、より巧妙な攻撃も防げます。また、システムプロンプトとユーザー入力を明確に分離するなど、構造的な対策も重要だと考えます。
検知段階
検知段階では、エージェントの振る舞いを継続的に監視します。通常とは異なる操作パターン（例：急激なAPI呼び出し増加、アクセス権限の昇格要求、想定外のリソースへのアクセス）を検知した場合、即座にアラートを発生させることで、攻撃の早期発見と被害の最小化が可能になると考えます。
対応段階
対応段階では、トレーシングが重要です。エージェントの判断プロセスを詳細に記録することで、インシデント発生時の原因究明を迅速に行えます。入力プロンプトやそれに対する実行内容を追跡可能にし、問題の再発防止に活用します。また、トレーシングにより説明可能なAI（Explainable AI）の実現にも寄与し、なぜそのような判断に至ったのかを後から検証できるようになります。
ちなみに、プロンプトインジェクションは原理的にはSQLインジェクションと似ており、「ユーザー入力を不適切に処理することで、意図しない命令を実行させる」という点で共通しています。SQLインジェクション対策で培われた知見は、プロンプトインジェクション対策にも応用できる部分が多いと思います。私はその知識が浅いので併せて理解を深めていきたいと思います。
おわりに
以上、簡単ではありますが認証・認可について整理し、AIエージェントにおける注意点について検討してみました。LLMの性能向上に伴って、AIエージェントができることがどんどん広がっており、便利になる反面、人の手を離れていろいろなことができていくようになり、何か問題が発生したときの影響も大きくなってしまう状況になりつつあると感じています。実際の業務でAIエージェントを利用していくのであればこの問題からは目を背けられないので、今後も勉強しながら知識を深めていきたいと思います。
ありがとうございました。