AI エージェントのための Zero Trust：アーキテクチャ境界の強制／エージェント集団と目的からの逸脱への対応

Zero trust AI agents demand a different kind of security

2026/09/07 HelpNetSecurity — HelpNetSecurity — このインタビューでは、Teleport の VP of Product Marketing である Chris Webber が、AI エージェントに対応するために Zero Trust の原則を拡張する必要がある理由について、エージェントの特性であるソフトウェアのような高速性／人間のような予測不能性／継続的な動作に触れながら説明している。さらに、最小権限 (Least Privilege)／時点ごとの検証 (Point-in-Time Verification) などの従来の考え方だけでは不十分である理由を解説している。

Chris Webber は、初期権限をゼロに設定する Trusted Runtime や、エージェントの動作をリアルタイムで監視する Identity Security といった Teleport のアプローチについても説明している。その上で、セキュリティ・チームに必要なのは、事後的な異常検出から脱却し、エージェントが実行する各ステップでルールを強制する体制へ移行することだと、同氏は主張している。

Zero Trust だけではエージェントにとって不十分？

Zero Trust の原則は、10 年以上にわたって適切な Identity Hygiene／Cybersecurity Practice の中核となっており、人間であるユーザーと Machine Identity を対象として設計されたこれらの原則は、現在も同様に重要である。一方、エージェントは従来の Zero Trust の原則では想定外だった方法で動作し、ソフトウェアのような高速性／人間のような予測不能性／目標を達成するための継続的な動作という特性を持つ。この継続性は、人によっては執拗と評価されるかもしれない。

Zero Trust は、明示的な検証 “Verify Explicitly” という重要な概念から始まり、一般的に、この検証は個々の認証ポイントで実施されてきた。しかし、エージェントが匿名で動作する場合や、人間になりすます可能性がある場合には、このようなポイントだけでは不十分である。そのため、この概念は Point-in-Time Authentication／Static Permission を超えて、固有の Identity に基づいてエージェントのアクセス／実行／通信の境界をアーキテクチャ・レベルで強制する Runtime へ拡張する必要がある。

同様に、”Least Privileged Access” の原則は、人間／Service Account にとって引き続き有効かつ重要だが、エージェントが集団を形成することを明示的に考慮し、集団としての振る舞いを統制できるよう進化させる必要がある。単一のエージェント・レベルでは個別に認可されたアクションであっても、集団として実行される場合には破壊的な結果をもたらす可能性がある。したがって、個々のエージェントだけではなく、エージェントのグループが何を実行できるのかについて、Decision Boundary を設定する必要がある。

Zero Trust の 3 番目の原則である、侵害を前提とする “Assume Breach” の考え方も、明示された目的からエージェントが逸脱する可能性を考慮するよう拡張しなければならない。この不整合は、Goal Hijacking／Reward Hacking などの攻撃手法によって生じる場合もあるが、悪意のない Misgeneralization／時間の経過に伴う Context Shift によって発生する場合もあり、その原因が攻撃／エラー／意図しない逸脱などであっても、結果は同じである。

こうした Agentic な特性に合わせて Zero Trust の原則を拡張することで、この新しい種類の Actor を統制するために必要な運用上の仕組みを定義できる。

Agentic Control を実現するイノベーションとは？

この定義は、エージェントを隔離／制御するために必要なアーキテクチャである Teleport Trusted Runtimes と、必要な対応を行うための監視／レスポンスという 2 つの側面から考えることができる。どちらも Teleport Identity Security の一部として提供されているが、すべてのエージェントは、人間とプラットフォームとの関係を明示的に確認できる固有の Identity を持ち、Trusted Runtime 内でのみ動作しなければならない。

Trusted Runtime は、運用上のアクセス／実行／外部通信に関する境界をアーキテクチャ・レベルで強制する環境である。インスタンス化した時点では、Initial Privilege がゼロに設定され、あらゆる接続が明示的に提供され、すべてのアクションが明示的に認可されるようにすべきだ。

また、必要以上に長く存続させるべきではなく、エージェントの作業が完了した場合やリスクが特定された場合に Runtime を完全に無効化することで、暴走するエージェントの動作防止／Standing Privilege の排除／保存されたデータの破棄が可能になる。

このアーキテクチャを導入した上で、Teleport は継続的な監視を提供し、エージェントの集団としてのリスク／個別のリスクを発生時に特定する。そのために、エージェントが実行する全 Interactive Action を記録／評価し、各アクションを単独で評価するのではなく、宣言された目的と照合することで、実際のリスクにつながるセッションを直ちに特定する。さらに、Trusted Runtime 内で動作する、エージェントの終了および破棄を含むかたちで適切な対応を実行する。

エージェントへの継続的な強制へセキュリティ戦略を移行する必要性は？

Identity Threat Detection and Response (ITDR) は、もともと Agentic 環境への対応を想定したものではなかった。Identity が人間／Service Account を判別し、Permission によって Least Privilege を十分に実現できると考えられている環境では、ITDR ツールは異常を監視するだけでよかった。

しかし、Agentic 環境では、従来の前提とは異なる状況が生じる。たとえば、人間の認証情報を使ってエージェントが動作する場合はどうなるだろうか？また、そのエージェントが、タスクを完了するために 25 個の Clone を生成した場合はどうなるだろうか？

この新しい時代では、Continuous Enforcement を前提としてシステムを設計し、エージェントを一意に識別して明示的に制御しなければならない。つまり Governance と Execution を切り離せない形で連携させる必要があり、そのためには、目的の取得やアクションが目的に合致しているかの判断を人間によるレビューに委ねるのではなく、Machine Speed で介入できるようにすることが求められる。

Teleport の最新動向を取り上げた記事の紹介です。自律的に動く AI エージェントの普及に伴い、人間やサービスアカウントを前提とした従来の認証や静的な権限管理では防御が困難になる問題が背景に存在します。野放しにされたエージェントは過剰アクセス／暴走によるデータ漏洩／システム破壊といった影響をもたらすため、適切な対応策が求められます。具体的には、初期権限をゼロにする Teleport Trusted Runtimes の適用／リアルタイムで挙動を監視する Teleport Identity Security の活用／不審なセッションの即時停止／実行環境の破棄といった仕組みの組み込みが有効です。ログの事後確認からリアルタイムな強制へ切り替え、安全な運用環境を整えることが推奨されます。