Cursor Cloud Agentsから外へのOIDC連携

この記事の要点

• AIエージェントにクラウドを直接触ってもらいたい場面は、ログ調査から開発環境での実験まであります。
• 長期キーを渡すと管理が増え、人間のCLI認証に相乗りさせると必要以上の権限まで渡りがちです。
• Cursor Cloud Agentsでは、OIDC連携で長期キーの配布を避けられます。任せる操作の範囲は、クラウド側のIAMで決めます。

クラウドを直接調べてもらいたい。でも、権限はどう渡すか

Cursorのエージェントにコードを触ってもらっていると、クラウドサービスも直接調べてほしくなります。

たとえば、エラーが出ているときにログを読んでもらう。保存されたデータを参照して、想定どおりの値になっているかを確かめてもらう。こうした読み取りだけの作業でも、必要な範囲へアクセスできれば、人間がログやクエリ結果を取り出して貼り付ける手間が減ります。

開発環境や実験用の環境なら、もう少し踏み込んで、設定を変えたり、リソースを作って動作を確かめたりするところまで任せたい。コードの提案にとどまらず、実際に試して結果を見ながら進められることは、エージェントを使う価値の一つだと思います。

そこで悩むのが、認証情報と権限の渡し方です。

専用のAPIキーやサービスアカウントキーを発行して渡すことはできます。ただし、その分だけ保管、更新、失効の管理が増えます。任せる環境や用途が増えるほど、どのキーをどこに渡したかを把握する手間も増えていきます。

ローカルなら、人間が認証済みのCLIに相乗りさせる方法もあります。手軽ですが、人間のアカウントが広い権限を持っていれば、ログを読むだけのつもりが、設定変更や削除までできる状態になりかねません。また、そのローカルの認証状態を、クラウド上で動くエージェントへそのまま持ち込むこともできません。

エージェントを動かす仕組み、いわゆるハーネス側でツールを制限したり、操作に承認を挟んだりすることも役立ちます。しかし、そもそも不要な操作はクラウド側の権限として与えないようにできれば安全ですね。ログ調査なら対象のログだけを読めるようにし、実験なら変更できる環境を限定する、というように。

OIDCで実行元を確かめ、用途に合う権限を渡す

このようなニーズを満たしつつ認証情報の受け渡しを整理する手段が、OIDC（OpenID Connect）を使ったID連携です。

エージェントの実行基盤が署名付きのトークンを発行し、クラウド側が発行元やトークンの内容を検証します。あらかじめ許可した条件に合えば、一時的な認証情報を取得できます。長期キーをエージェント用に保管・配布する代わりに、信頼する実行元と、渡してよい権限をクラウド側へ設定しておく仕組みです。

AWSでは、この仕組みをOIDC federationと呼んでいます。OIDCプロバイダーを登録し、IAMロールの信頼ポリシーで誰がそのロールを引き受けられるかを決めます。エージェントはトークンをAWS STSのAssumeRoleWithWebIdentityへ渡し、そのロールの一時認証情報を取得します。何を操作できるかは、ロールに設定する権限ポリシーで制限します。

Google CloudではWorkload Identity Federationがこれに当たります。外部のIDに直接IAM権限を付与する方法と、サービスアカウントの権限を借用する方法があり、長期のサービスアカウントキーを配らずにアクセスできます。後者ではサービスアカウント自体は引き続き使います。

OIDCを使えば、権限が自動で適切になるわけではありません。減らせるのは長期キーの受け渡しや管理であり、誰を信頼し、どの操作を許すかという設定は残ります。読み取り用と実験用で役割を分けるなど、任せたい仕事に合わせて権限を設計する必要があります。

Cursor Cloud Agentsでも使える

Cursor Cloud AgentsはOIDCトークンの発行に対応しています。GitHub ActionsでOIDCを使っているなら、流れはおなじみです。実行基盤が発行するトークンをクラウドへ渡し、一時認証情報を取得します。その発行元が、GitHubからCursorに変わります。

対象はCursorが管理するCloud Agentsです。手元のCursorエディタ全般で、そのまま使える機能というわけではありません。

AWSの場合は、IAMのOIDCプロバイダーにhttps://api.cursor.comを登録します。ロールの信頼ポリシーで想定するaudと許可するsubを指定し、ログの読み取りなど必要な権限をそのロールに設定します。エージェントはVM内のソケットからトークンを取得して、AWS STSへ渡します。具体的な設定はCursorのAWS向け手順にまとまっています。

運用上は、二つの点を押さえておきたいです。

一つは、認証情報の寿命です。CursorのJWTは5分ですが、交換後のクラウド認証情報には別の有効期間があります。たとえばAWS STSの既定は1時間です。元のJWTが失効した時点で、交換後の認証情報まで使えなくなるわけではありません。

もう一つは、権限を渡す単位です。Cursor VM内のソケットへアクセスできるプロセスは、トークンを取得できます。エージェントが実行するスクリプトなども含め、その実行環境全体へ渡してよい権限として考える必要があります。

まずは対象を絞ったログ調査から、実験用の環境では変更を伴う検証まで。任せる仕事に合わせた権限を用意できれば、人間の認証に相乗りさせたり、長期キーを配ったりせずに、エージェントがクラウドを直接使う範囲を広げられます。