Cloudflareは、自社の従業員が5月から使い続けているエージェントプラットフォームの最初のバージョン「Cloudflare OS」をオープンソース化しました。
エージェントが読み取ったリソースはすべて記録され、その記録はエージェントが生成した成果物に付随します。そして別の人物がその成果物を開くと、プラットフォームはまず元となるデータに照らしてその人物をチェックします。たとえばエージェントが機密性の高いウェアハウステーブルからライブダッシュボードを構築した場合、同僚がそのダッシュボードを開いても、自分自身がそのテーブルを読み取る権限を持っていない限り何も表示されません。
エージェントが外部サービスのツールを呼び出せるようにする標準規格「Model Context Protocol」は、エージェントがどのツールを呼び出せるかは教えてくれますが、実際にどの行、ファイル、リポジトリを読み取ったかまでは教えてくれません。エージェントは2つのシステムにまたがるデータを結合し、その結果を権限の少ない人物に渡すことができてしまい、しかも何に触れたのかという痕跡は残りません。Cloudflareは、社内でワークスペースや成果物を互いに共有し始めた際に、この問題に直面しました。
「認可の仕組みは、データがその後どこに流れていくのかまで考慮しなければなりません」と、Phillip Jones氏とDan Carter氏は述べています。GitHub上には2つのリポジトリが公開されました。コア部分と、Cloudflareが社内で実際に運用している方法をモデルにしたスターター用デプロイメントです。
認証情報はエージェントに渡らない
Cloudflare OS内のすべてのエージェントとアプリは、何のアクセス権も持たない状態からスタートします。エージェントが1つのリソースへのアクセスを要求すると、人間がそれを許可または拒否し、生成されたコードには、1つのポリシーの下でそのリソースを使用する権限を表す型付きバインディングが渡されます。サーバー側のコードは、アウトバウンド通信を無効にしたDynamic Worker上で実行されます。クライアント側のコードは、サンドボックス化されたブラウザフレーム内で実行されます。いずれも、渡された権限(capability)を通じてでなければインターネットにアクセスできません。
Gatekeeperと呼ばれるサービス固有のWorkerが、この保持役を担います。プラットフォームと外部APIの間に位置し、OAuthのハンドシェイクを完了させ、認証情報を保持し、ポリシーを適用し、読み取り内容をログに記録します。GatekeeperをGitHubに向ければ、エージェントを単一のリポジトリに限定し、ソースコードは読ませずにissueだけ読ませる、特定のフィールドをマスクする、レート制限をかける、プルリクエストのマージ前に人間の承認を必須にするといった設定が可能です。エージェント側には小さなTypeScript APIしか見えず、キー自体に触れることはありません。
ダッシュボードの問題に答えるのが、この観測ログという仕組みです。エージェントが読み取ったリソースはすべて記録され、その記録はエージェント自身と、それが生成した成果物の両方に付随し続けます。別の人物がワークスペースや成果物を開くと、Gatekeeperは何かを表示する前に、その人物を観測済みのリソースと照合してチェックします。同じログはアウトバウンドのルールにも使われるため、機密データを読み取ったエージェントは、特定の宛先への書き込み、新たな協力者の招待、別のエージェントへのタスクの引き渡し、外部へのリクエスト送信をブロックされることがあります。
あらゆるファイルがアプリになりうる
ワークスペースはソフトウェアを構築できます。アプリの作成を依頼すると、エージェントがインターフェース用のクライアントコードと、状態や動作を管理するサーバーコードを書き上げ、必要に応じてDynamic Workerとして読み込まれ、このプロジェクトのためにCloudflareが構築した「Durable Object Facet」という組み合わせのインスタンスとして実行されます。このFacetにより、各アプリは専用のSQLiteデータベースを持ちます。Dynamic Workerが軽量なV8アイソレートを使用しているため、コンテナやアイドル状態のサーバーを背後に置くことなく、各アプリは独立したランタイムを得られます。
ブラウザは、Cloudflareのオープンソースなオブジェクト権限RPCシステムであるCap’n Webを介してサーバーと通信します。これにより、クライアントはサーバーのメソッドをまるでローカルの関数であるかのように呼び出せます。エージェントも同じメソッドを呼び出すことができます。「つまり、自分自身で仕事をこなすツールを作れるなら、あなたが不在のときにエージェントがそのツールを使って仕事をこなせるということです」と、Jones氏とCarter氏は述べています。
アプリはデフォルトで非公開に設定されており、2通りの方法で共有できます。アプリそのものを共有すれば、同僚と同じライブ状態を共同で扱えます。ブループリントを共有すれば、SQLiteのデータ、会話履歴、認証情報、接続済みリソースを一切含まないコードのコピーだけが相手に渡ります。変更を加えたい人は、あなたに依頼を出す代わりに、エージェントを使って自分でそれを行えます。
それでも自分で構築しなければならないもの
モデルの選択はCloudflare AI Gatewayを経由します。管理者はここで利用可能なモデルを選び、すべての推論呼び出しを個人・チーム・ワークスペース単位で紐付け、予算やレート制限を設定します。その理由として挙げられているのはコストです。毎朝未読メールを要約するだけの作業に、最先端モデルは必要ないというわけです。
Cloudflare OSは、まだダッシュボードから有効化できる製品にはなっていません。マネージド版の提供、開発ワークフロー向けのコンテナ、Slack内でのワークスペース利用といった機能はいずれも今後の予定です。戦略的パートナーとして名前が挙がっているPresidioとHappy Cogは、コンテキストやスキル、社内システムとの連携を組織ごとに構築したいという企業向けに、導入支援を行う予定です。
Cloudflare OSはGitHubで公開されています。
翻訳元: https://www.helpnetsecurity.com/2026/08/06/cloudflare-os-open-source/
