「エージェントに社内データを見せてよいか」を判断する方へ

事業部門から「AIから基幹システムのデータを見せてほしい」と言われている情報システム・セキュリティ担当の方に向けて書いています。

7月にAIエージェントに業務を任せる前に権限をコードで絞るという記事を書きました。利用規程では守れないので実装で最小権限にする、という内容です。今回は続きで、その実装をどこまでやれば十分なのかという基準が出てきた話をします。

何が公開されたのか

Cloudflareが2026年8月5日、社内で運用しているエージェント基盤「Cloudflare OS」をオープンソースで公開しました（Cloudflare Blog「Cloudflare OS: an open platform for agents, apps, and work」）。2026年5月から社内の全員に提供していて、エンジニア以外を含む数千人が毎日使っていると書かれています。

自社の業務で回した実装をそのまま出しているので、設計に机上の無理がありません。

エージェントは何も見えない状態から始まります

まず前提が違います。エージェントもアプリも、何ひとつアクセスできない状態から始まる。

必要になったらリソースへのアクセスを申請し、承認されたものだけが型付きの参照としてコードへ渡ります。認証情報そのものはエージェントにも生成されたコードにも渡りません。サーバ側のコードは外向きの通信を切った実行環境で動き、明示的に与えた経路以外ではインターネットへ出られません。

「APIキーを渡す」という発想を捨てている、と言い換えてもいい。実際、記事にも「人やエージェントにAPIキーを渡すのは危険でスケールしない。キーは広範囲かつ長期の権限を与えがちで、制約も共有も監査も難しい」という趣旨の説明があります。

MCPでツールを絞るだけでは足りません

ここが今回いちばん効く指摘です。

MCPサーバが認証情報を預かり、エージェントには決められたツールだけを見せる。これは確かに前進です。ですがCloudflareはこう書いています。MCPはエージェントがどのツールを呼べるかは教えてくれるが、エージェントがどの根本リソースを観測したかは分からない、と。

エージェントは複数のシステムから集めた情報を組み合わせられます。制限の緩い場所へ送ることも、元のデータを見る権限のない人へアプリや出力を通じて渡すこともできる。だから認可は、そのデータがこの先どこへ行けるかまで考慮しなければならない、という結論になります。

例が分かりやすい。エージェントが機密テーブルを読んでダッシュボードを作ったとき、そのダッシュボードを共有することが、テーブルを共有することになってはいけない。

見たものが記録され、共有のたびに検証されます

Cloudflare OSはエージェントが観測したリソースをすべて記録します。記録はエージェントとその成果物に紐づいたまま残り、別の人がそのワークスペースを開くとき、エージェントと対話するとき、生成物を見るときに、その人が観測済みリソースへの権限を持っているかを検証する。

同じ記録は外向きの通信の判断にも使われます。機密データを読んだ後は、特定の宛先への書き込み、新しい共同編集者の招待、他のエージェントへの引き渡し、外部へのリクエストを止められる。

使う人がこれを意識しなくていい、というのが設計の狙いです。

Gatekeeperが「広すぎる権限」を刻みます

外部サービスとの間には、サービスごとの中継役（Gatekeeper）が入ります。そのサービスのAPIと、扱えるリソース、実行できる操作を理解している中継です。

Cloudflareが挙げている例がそのまま実務の話になっています。GitHubアカウント全体へのアクセスは広すぎる。だから単一のリポジトリに限定し、issueは読めるがソースコードは読めないようにし、特定のフィールドをマスクし、レート制限をかけ、プルリクエストのマージ前に承認を要求する。

これが「コードで絞る」の実物です。7月の記事で書いた考え方を、誰かが実装まで持っていった形になります。

提案を受けたときに聞くこと

エージェント基盤の提案や見積もりを受け取ったら、次の5つを質問にしてください。

データアクセス統制の5項目

  • 観測の記録: エージェントが何を読んだかがログに残るか。残らないなら共有時の検証はできない
  • 共有時の検証: 生成物を第三者が見るとき、元データへの権限を確認する仕組みがあるか
  • 認証情報の隔離: APIキーがエージェントや生成コードに渡っていないか。預かる側が別にいるか
  • 外向き通信: 明示した経路以外でインターネットへ出られない構成か
  • 権限の粒度: 「アカウント全体」ではなく「このリポジトリのissueだけ」まで刻めるか

5つのうち上2つが答えられない提案は、ツールを絞る段階で止まっています。稟議に載せる前に確認してください

社内データを外へ出せるかという手前の判断は「社内データを外に出せない」と言う前にで整理しました。今回の話は、出さないと決めた後に社内で何が起きるかという段の話です。

現場メモ

私たちが権限設計を引き受けるとき、ツールを絞るところまでは早く終わります。読める範囲と実行できる操作を決めて実装する作業は、見積もりも立てやすい。

時間がかかるのはその先です。「このエージェントが読んだデータを、権限のない人が結果物として見てしまわないか」を担保しようとすると、業務側の権限モデルをそのまま持ち込む必要が出てきます。誰がどの部署のどのデータを見てよいのか。その定義が社内で揃っていないと、実装のしようがありません。

だから権限の相談を受けたときは、先に業務側の権限表を見せてもらいます。そこが曖昧なまま実装に入ると、結局「全部読める」に戻ります。

そのまま入れれば終わり、ではありません

オープンソースで出てきたのは良いことです。使える手段が増えました。

ただし公開されているのは基盤と、Cloudflare自身の運用にもとづく設定例です。記事にも「自分たちの配置はCloudflareのシステム・用語・方針・仕事のやり方を反映している。あなたのものはあなたの組織を反映すべきだ」と書かれています。自社に入れるには、自社の業務と用語と権限モデルを持ち込む作業が要ります。そこは誰かがやらなければ埋まりません。

その担い手を誰が持つかという話はAIエージェント17人の部署ができましたでも書きました。基盤が公開されても、整備する人の仕事は減りません。

権限表の整理から手を付けたい段階でしたら、お問い合わせからご相談ください。業務側の定義を固めるところからご一緒します。