先週の火曜日、ステージング環境で「無害」なコーディングエージェントがPRを開き、誤った環境からシークレットを取得し、触れてはいけないはずのデプロイを開始してしまいました。
私たちは何も「ハック」されませんでした。エージェントは、システムが許可しているとおりに動いただけです。
ここが、マルチエージェント構成で多くのチームが見落としがちな点だと思います。問題は通常、モデルの品質ではありません。問題はアイデンティティです。
エージェントが複数になると――プランナー、コーダー、レビュアー、デプロイヤー、サポートボット、など何であれ――非常に退屈な質問への答えが必要になります：
- このエージェントは、正確には誰（何）ですか？
- 何が許可されていますか？
- 他の誰かの代わりに行動できますか？
- 後で何が起きたかをどう証明しますか？
それに答えなければ、あなたの「AIフリート」は共有されたルートアカウントのような、雰囲気になってしまいます。
最初に壊れるパターン：共有クレデンシャル
多くのエージェントシステムは、今でもだいたいこんな見た目です：
Agent A ----\
Agent B -----+----> same API key / same GitHub token / same MCP access
Agent C ----/
これは次のいずれかが起きるまではうまく動きます：
- どれか1つのエージェントがプロンプトインジェクションされる
- どれか1つのワークフローで、より狭い権限が必要になる
- 監査証跡（オーディットトレイル）が必要になる
- リスクのある操作に対する承認が欲しくなる
- どれか1つのエージェントだけを無効化したいが、すべてを壊したくない
共有クレデンシャルは便利ですが、アトリビューション（誰のせいか）と最小権限を破壊します。
実際に機能するアイデンティティのパターン
私たちが見てきた中で最も信頼できるパターンはこれです：
- 各エージェントに独自の暗号学的アイデンティティを付与する
- 短命の委任アクセス（デリゲートされた権限）を発行する
- ツールの境界でポリシーを強制する
- エージェントのアイデンティティ＋委任チェーンとともに、すべての操作を記録する
実際には、だいたいこんな形になります：
[Human/User]
|
| delegates task
v
[Planner Agent] -- short-lived token --> [Coder Agent]
| |
| policy check | calls tool / MCP server
v v
[Approval / Policy Engine] -------------> [GitHub, CI, Cloud, DB]
Audit log = who delegated what to whom, for which action, when
これは「エージェントが何かをした」というのと、「リリースワークフローの代わりに行動するレビューエージェントは、10分間だけこのリポジトリを更新することだけが許可されていた」というのとの違いです。
まず実装するべきこと
これを改善するのに、巨大なプラットフォーム導入のロールアウトは不要です。
1) エージェントごとのアイデンティティ
すべてのエージェントプロセス、またはロールに対して、固有のアイデンティティを使ってください。理想的には、そのアイデンティティは設定中の単なる文字列ではなく、暗号学的なものです。
Ed25519キーは、速くて小さく、検証も簡単なので、この用途に適しています。
重要な理由：
- 無効化（リボーク）が的を絞ってできる
- 監査ログが役に立つようになる
- ツールがネットワーク上の場所を信用するのではなく、呼び出し元を検証できる
2) クレデンシャル共有ではなく委任
エージェントAがエージェントBに作業をしてもらう必要がある場合、長寿命の秘密鍵を渡さないでください。委任された権利を表す、スコープ付きで短命のトークンを発行します。
ここでは OAuth のトークン交換／委任チェーンのパターンが堅実です。RFC 8693 のような標準をすでに使っているなら、それは素晴らしいです。そうでない場合でも、「デプロイトークンを単に使い回す」よりは、シンプルな社内の委任モデルのほうが良いです。
3) 境界（エッジ）でポリシーを適用
あなたのツールは、すべての「社内」呼び出し元を同じようには信用すべきではありません。
MCP サーバ、ゲートウェイ、またはエッジプロキシでポリシーチェックを置きます：
- このエージェントは課題（イシュー）を読み取れる
- あのエージェントは PR を開ける
- 承認されたエージェントだけがデプロイをトリガーできる
- 本番操作は人間の承認が必要
OPA がスタックに合うなら、OPA を使ってください。真面目な話、これのためにポリシーエンジンを作り直す必要はありません。
4) 破壊的操作のための承認ワークフロー
delete、deploy、rotate、publish、およびchargeを特別扱いにしてください。
エージェントはスピードを出すのが得意です。だからこそ、リスクのある操作には明示的な承認ゲートが必要です。
小さく動かせる例：エージェントのアイデンティティを生成する
ここでは Ed25519 を使った最小の Node 例を示します：
npm install tweetnacl tweetnacl-util
node agent-id.js
// agent-id.js
const nacl = require("tweetnacl");
const util = require("tweetnacl-util");
const keypair = nacl.sign.keyPair();
const publicKey = util.encodeBase64(keypair.publicKey);
const secretKey = util.encodeBase64(keypair.secretKey);
console.log("Agent public key:", publicKey);
console.log("Store secret key securely:", secretKey.slice(0, 24) + "...");
これは完全なアイデンティティシステムではありませんが、正しい方向性です。すべてのエージェントが独自のキーペアを持ち、下流のシステムが呼び出し元が誰かを検証できるようにします。
よくある間違い：モデルを守ることに集中して、ワークフローを守らない
チームはモデルのガードレールに多くの時間を費やしすぎ、実行境界（execution boundaries）への対策が十分ではないことがよくあります。
しかしマルチエージェントシステムでは、被害範囲（ブラスト半径）は通常、エージェントが何を言えるかではなく、何をできるかから生まれます。
セキュアなフリートは、ほとんどが退屈なインフラでできています：
- アイデンティティ
- スコープ付きトークン
- ポリシーチェック
- 承認
- 監査ログ
- 信頼できない実行のための分離（アイソレーション）
これは、コーディングエージェントをオーケストレーションしていようが、サポートエージェントであろうが、バックグラウンドタスクランナーであろうが、同じです。
自分で試してみる
まず何かを購入することなく、エージェントのセキュリティを強化したいなら：
- MCPサーバーを確認したいですか？ https://tools.authora.dev を試してみてください。
- コードベースをスキャンするには
npx @authora/agent-auditを実行します - エージェントに検証済みバッジを追加： https://passport.authora.dev
- 追加のリソースについては https://github.com/authora-dev/awesome-agent-security をチェックしてください
最終的に残りを自分で構築することになったとしても、これらは役立つ出発点です。
大きな転換はシンプルです。エージェントを「機能」として考えるのをやめ、アイデンティティを持つワークロードとして扱い始めましょう。
そのとき、マルチエージェントシステムは謎ではなく統制可能になります。
あなたのスタックでは、現在どのようにエージェントのアイデンティティを扱っていますか？ 下にあなたのアプローチを投稿してください。
-- Authora team
この記事はAIの支援を受けて作成されました。
