Cursorのセキュリティ：リスク、データフロー、ベストプラクティスの完全ガイド

カーソルについてあまり意識することはないかもしれませんが、それがデジタルセキュリティに与える影響は、あなたが思っている以上に大きいかもしれません。リンクをクリックしたり情報を入力したりするたびに、カーソルはウェブサイトやアプリとやり取りしており、注意を怠るとこれがリスクを生む可能性があります。このガイドは、DevSecOpsチーム、セキュリティエンジニア、開発者向けに作成されており、彼らのコードに何が起こるのかを明確に理解してもらうことを目的としています。具体的には、カーソルセキュリティとは何か、Cursorがどのように機能するか、処理するデータの種類、過去の脆弱性、主要なリスク、そして安全に利用するためのベストプラクティスについて解説します。

カーソルセキュリティとは何か、そしてなぜそれが重要なのか？

AI搭載IDEは、「あれば便利」なツールから開発の中核インフラへと急速に進化しており、その速度はセキュリティチームの適応を上回ることが少なくありません。Anysphere社のCursorはその代表例です。これは、VS Codeをベースとしたエディタで、AIが深く統合されており、コードの生成、リファクタリング、さらにはコードや外部アクションの実行まで可能です。

Cursorはもはやニッチな存在ではありません。2025年半ばまでに、その急速な成長が報告書で強調され、年間経常収益（ARR）は約5億ドルに達するとされています[出典]。Cursor自身も「数万の企業」で利用されていると述べており、エンタープライズ版の発表記事では顧客名が公表されています[出典]。NVIDIAのCEOも、NVIDIA社内でCursorを含むAIコーディングツールが広く利用されていることを公に認めています。[出典] この成長は、主にオーガニックなものであり、口コミによる普及、開発者コミュニティ、そして寛大なフリーミアムモデルによって推進されてきました。

Cursorをユニークにしているのはそのアプローチです。もはや手動でコードを書くだけではなく、コードを読み書きし、実行するAIエージェントを指示するのです。これは「バイブコーディング」と呼ばれることも多いトレンドです。

しかし、エージェントAIをIDEに組み込むことは、新たなセキュリティ課題をもたらします。従来のIDEとは異なり、Cursorはクラウドに接続された半自律的な環境で動作し、コードが外部システムと継続的にやり取りします。

企業にとって、これらのリスクは非常に重要です。大規模な導入が進み、CVE-2025のような新たな脆弱性が浮上している中で、Cursorがセキュリティをどのように扱っているかを理解することは不可欠です。

Cursorの構造：攻撃対象領域の理解

カーソルセキュリティのインフラストラクチャに深く踏み込む前に、Cursorエンジンの理解が重要です。Cursorは単なる静的なIDEではなく、高度な自律性を持つエージェント群が連携して動作するものです。セキュリティの観点から見ると、Cursorのすべての機能はセキュリティ上の「要求」であり、同時に潜在的な露出ポイントでもあります。Cursorの主要な機能がどのように攻撃対象領域となるかを見ていきましょう。

1. コード補完

Cursorは、入力中にコードをインラインで予測します。アクティブなファイルの小さなスニペットは暗号化され、Cursorのサーバーに送信され、そこでカスタムLLMが1秒以内に補完を生成します。

セキュリティリスク： 組織にとって、これは絶対的なデータ保持ゼロ（ZDR）を要求します。毎秒数百万件のクエリがメモリ内でのみ処理され、永続的なログに書き込まれないことを保証するものです。いかなる不備も機密性の高いコードを露呈させる可能性があります。

2. チャットアシスタント

Cursorは、機能の構築やバグ修正に協力できます。インデックス化されたコードベースをエージェント的推論で検索し、スニペットを組み合わせてAIモデル向けの豊富なプロンプトを作成します。

セキュリティリスク： スニペットベースのAIからの改善にもかかわらず、間接的なプロンプトインジェクションは可能です。サードパーティライブラリ、READMEファイル、またはコメントに隠された悪意のある指示は、エージェントを「汚染」し、許可されていないタスクを実行させたり、内部ロジックを外部URLに漏洩させたりする可能性があります。

3. インライン編集モード (Cmd+K)

Cursorは、対象となるコードブロックを正確かつ外科的な方法でリファクタリングします。選択されたコードと指示はモデルに送信され、モデルは差分を返し、それがファイルに直接適用されます。

セキュリティリスク： AIによる迅速なリファクタリングは、特にレビュー担当者の疲労下において、微妙なセキュリティ上の欠陥を導入する可能性があります。例えば、未検証の入力、ハードコードされたシークレット、AIが生成した論理エラーなどが挙げられます。開発者は、変更を受け入れる前に、それらを注意深く検査する必要があります。

4. BugBotによる自動コードレビュー

BugBotはプルリクエストをレビューし、修正を提案します。これには、プライベートなGitHubリポジトリへの読み書きアクセスが必要です。

セキュリティリスク： あなたのCI/CDパイプラインは、Cursorのクラウドインフラストラクチャに部分的に依存するようになります。BugBotは特権エンティティとして扱われるべきであり、その権限はリスクを最小限に抑えるために厳密にスコープされる必要があります。

5. バックグラウンドエージェント

Cursorは、時間のかかるタスクをバックグラウンドエージェントにオフロードします。例えば、CursorのAWSクラウド内の隔離されたUbuntuベースのVMで完全なテストスイートを実行する、といった形です。

セキュリティリスク： これにより、脅威モデルにリモートコード実行が導入されます。独自のコードがローカルマシンからCursorが管理するクラウド環境に移動するため、クラウドテナントの分離とVMのセキュリティは極めて重要です。

6. 永続的な動作

Cursorは、プロジェクト固有のスタイルガイドや過去のアーキテクチャ上の決定を記憶しています。.cursorrulesファイルや「記憶」からの指示を、すべてのプロンプトのコンテキストに組み込みます。

セキュリティリスク： 共有リポジトリ内の侵害された.cursorrulesファイルは、永続的で目に見えない偏りをAIに注入する可能性があります。例えば、攻撃者はAIに、チームのIDE全体で暗号化のために悪意のあるライブラリを一貫して使用させるよう強制することができます。

7. コードベースのインテリジェンス

Cursorは、キーワードだけでなく意味に基づいてプロジェクト全体を「理解」し、検索できます。マークルツリー同期を使用して、コードをリモートのベクトルデータベース（Turbopuffer）に保存された埋め込みにマッピングします。

セキュリティリスク： 機密性の高いロジックや秘密情報（.envファイルなど）は、.cursorignoreで除外されていない場合、意図せずベクトル化される可能性があります。これにより、重要な情報がリモートストレージに公開されてしまいます。

Cursorの機能と攻撃対象領域を理解したところで、次に、データがどこに送られ、どのように処理され、そしてCursorがコードを安全に保つためにどのような多層的なインフラストラクチャを使用しているのかを検証します。

Cursorはあなたのコードをどのように扱いますか？

CursorはIDEと密接に統合し、AI駆動の自動化を開発ワークフローにもたらします。これによりスピードと柔軟性が向上しますが、多くの開発者はIDEをブラックボックスとして扱っています。

CISO、セキュリティエンジニア、または上級AI開発者であれば、一つの重要な疑問が浮かび上がります。

「私のコードは一体どこへ行くのか？」

Cursorは、ローカルマシンからCursorのクラウドオーケストレーション、AI推論、そしてその逆へと、明確な管理の連鎖を生み出す3層アーキテクチャを通じてこれに対処します。

• 第1層 – クライアント（ローカルマシン）
• 第2層 – Cursorバックエンド（ゲートウェイ）
• 第3層 – サードパーティLLMサブプロセッサー

第1層 – クライアント（あなたのローカルマシン）

VS CodeのフォークであるCursorクライアントは、最も機密性の高いデータをローカルに保持し、データが環境を離れる前にすべての重要な前処理を実行します。コードをインデックス化し、ローカルの埋め込みを作成し、ファイルハッシュのマークルツリーを維持し、意味検索を実行して、クラウドに送信する関連スニペットのみを選択します。また、Cursorは.cursorignoreおよび.gitignoreルールを尊重し、機密ファイル、秘密情報、またはPIIを除外します。

セキュリティの観点から見ると、これによりデータ最小化（コードのごく一部のみがマシンを離れること）と送信前フィルタリングが保証され、クライアントがソースコードを保護するための最も強力な境界となります。

第2層 – Cursorバックエンド（ゲートウェイ）

Cursorのバックエンドは、ソースコードを保存することなくAIプロンプトを組み立てる、安全なオーケストレーション層として機能します。主にAWSでホストされているこの「Cursor Gateway」は、ユーザーのクエリとクライアントで選択されたスニペット、および永続的なプロジェクト指示（.cursorrulesなど）を組み合わせます。これが適用するのは プロンプトエンジニアリング、ルーティングロジック、安全制御であり、ガバナンスのためにユーザーが提供するAPIキーも通過します。

プライバシーモードでは、すべてのコードはメモリ内で処理され、ログは保持されず、長期的な保存は行われません。ゲートウェイは、データがサードパーティのLLMプロバイダーに到達する前の、Cursorが制御する最後の境界となります。

ティア3 – サードパーティLLMサブプロセッサー

推論は、OpenAI、Anthropic、GoogleなどのサードパーティLLMプロバイダーを通じて行われます。これらのモデルは、最終的に組み立てられたプロンプトを受け取り、処理し、その出力をバックエンド経由でクライアントにストリーミングします。

エンタープライズのお客様向けには、ゼロデータ保持（ZDR）契約により、コードが推論ウィンドウを超えて保存されないこと、プロンプトがトレーニングに使用されないこと、および二次的な保持が行われないことが保証されます。準拠したプロバイダーを選択し、契約上の保証を徹底することは、企業のセキュリティとコンプライアンスを維持するために不可欠です。

Cursorは異なる種類のデータをどのように扱いますか？

Cursorは複数の種類のデータと連携し、それぞれが異なる階層を流れ、独自のセキュリティ上の考慮事項を伴います。以下の表は、主要なデータタイプ、その主な階層、例、およびセキュリティに関する注意事項をまとめたものです。

Cursorにおけるセキュリティリスクは何ですか？

CursorのAI機能は強力な自動化をもたらしますが、同時に新たなセキュリティ課題も提起します。ここでは、Cursorにおける7つの主要なセキュリティリスクを見ていきましょう。

1. 悪意のあるプロンプトの実行

攻撃者は、CursorのAIを騙して意図しないコマンドを実行させたり、重要なプロジェクトファイルを変更させたりするプロンプトを作成できます。これらのアクションはターミナルやファイルシステムで直接実行される可能性があるため、悪用されるとコードの破損や環境全体の侵害につながる可能性があります。

2. プロジェクト間のコンテキスト汚染

Cursorは、AIの提案を強化するためにプロジェクトおよび会話のコンテキストを使用します。このコンテキストが、例えば誤解を招くスニペットや指示によって汚染された場合、他のプロジェクトに波及する可能性があります。これにより、論理エラー、セキュリティ脆弱性、または機密情報の偶発的な漏洩が発生する可能性があります。

3. 侵害されたルールファイル

ルールファイルは、トリガーや実行パラメーターを含め、Cursorエージェントの動作を管理します。改ざんされたルールファイルは悪意のある指示を隠し、攻撃者に永続的なアクセス権や、ファイルがロードされるたびに任意のコードを実行する能力を与える可能性があります。

4. 監視されていないエージェントの自動実行

自動実行モードでは、エージェントが人間の承認なしにコマンドを実行できます。これは便利である一方で、重要なレビュー手順を省くため、安全でないスクリプトが気づかれずに実行され、マルウェアが導入されたり、開発環境が侵害されたりするリスクを高めます。

5. 認証情報の漏洩

AIが生成した出力には、誤ってAPIキー、認証トークン、またはログイン認証情報が含まれる可能性があります。これらの機密情報がログ、バージョン管理、または共有環境で漏洩した場合、攻撃者は機密システムやデータに直接アクセスできるようになる可能性があります。

6. 悪意のある依存関係の実行

CursorはAIワークフローの一部としてパッケージを自動的にインストールできます。公開レジストリからの悪意のある、または侵害されたパッケージには、データ流出、マルウェア展開、またはインストール時に不正なコマンドを実行する難読化されたスクリプトが含まれている可能性があります。

7. 名前空間の衝突とエージェントのなりすまし

複数のエージェントが同じ名前空間を共有している場合、悪意のあるアクターは信頼されたエージェントになりすますなりすましエージェントを作成できます。これにより、Cursorのエージェントシステムが乗っ取られ、攻撃者が不正なコマンドを実行したり、機密情報を流出させたりすることが可能になります。

現実世界の悪用事例：CurXecuteとMCPoison

2025年、研究者たちはCursorがMCPサーバーを処理する方法における2つの注目すべき脆弱性を特定し、IDEにおけるエージェントAIの現実世界のリスクを浮き彫りにしました。 

CurXecute

1つ目のCurXecute（CVE-2025-54135）は、間接的なプロンプトインジェクションの危険性を示しました。研究者たちは、Cursorがユーザーの承認を必要とせずに、特定のファイルをワークスペース内に作成することを許可していることを発見しました。 

これは、攻撃者がAIエージェントが監視しているSlack通知などの悪意のあるメッセージを作成し、AIを騙して悪意のある.cursor/mcp.jsonファイルを書き込ませることを意味しました。Cursorの古いバージョンでは、新しいファイルを作成する際に確認を求めなかったため、この欠陥はテキストメッセージを送信するだけでリモートコード実行（RCE）を達成するために悪用される可能性がありました。

MCPoison

2つ目の脆弱性であるMCPoison（CVE-2025-54136）は、信頼検証の欠陥を悪用しました。 CursorのMCPサーバーの処理における 承認の。以前のバージョンでは、一度サーバーが承認されると、Cursorはそのサーバーを無期限に信頼しました。攻撃者は最初に無害な設定を共有リポジトリにコミットし、それが承認されるのを待つことができました。 

その後、彼らは密かにコマンドをリバースシェルなどの悪意のあるペイロードに置き換えることができました。サーバー名が変更されなかったため、Cursorはユーザーに再度承認を求めず、悪意のあるコマンドのステルス実行を可能にしました。 

これらの脆弱性は合わせて、厳格な承認ワークフロー、設定ファイルの監視、およびAI対応IDEの最新バージョンの維持の重要性を強調しています。

Cursorのベストプラクティス

Cursorをセキュアにするとは、誤り、誤解を招く提案、または予期せぬ動作がインシデントに発展するのを防ぐために、制御を多層化することを意味します。各層は人間の監視を追加し、自律的な行動を制限し、可視性を向上させます。こちらをご覧ください。 

レベル1：IDEの即時強化（個人開発者向け）

これらは、すべての開発者が初日から実施すべき不可欠なステップです。

• ターミナルの自動実行を無効にする。 自動実行は便利かもしれませんが、エラーを発見できる一時停止の機会をスキップしてしまいます。意図しない破壊的な操作を防ぐため、AIが提案するコマンドはすべて、実行前に明示的なレビューが必須です。
• プライバシーモードを有効にする。 これにより、コードがローカルセッション外に保持されることがなくなります。プライバシーモードは、ユーザーエクスペリエンスを維持しつつ、機密性の高いコードが外部に漏洩するリスクを大幅に低減します。
• ドットファイルと認証情報を保護する。 多くの実際の情報漏洩は、.envファイル、SSHキー、その他ローカルマシンに保存されている設定ファイルから発生しています。ドットファイル保護を有効にすることで、これらのファイルがAIエージェントによってアクセスされることはなくなります。

チームがこれら3つの基本的なステップを実行すれば、ほとんどの明白な個人レベルのリスクを軽減できます。

レベル2：プロジェクトレベルのガードレール（チームのデフォルト設定）

チーム内で複数の開発者がCursorを使用するようになると、一貫性と強制力のあるプラクティスが不可欠になります。

• 常に.cursorignoreファイルを使用する。 すべてのリポジトリは、機密ファイル、PII（個人識別情報）、または環境データをAIのインデックス作成、埋め込み、プロンプトから明示的に除外すべきです。これにより、機密情報がローカルマシンから外部に出るのを防ぎます。
• .cursorrulesを本番コードのように扱う。 ルールファイルは、永続的なAIの動作を定義し、プロジェクト全体の意思決定に影響を与えます。変更をマージする前に、必ず複数人での確認を必須としましょう。そして、それらを個人的な好みではなく、ポリシーとして捉えましょう。
• 一貫したプロジェクト設定を徹底する。 標準化により、偶発的な情報漏洩を防ぎ、再現性のあるAIの動作を保証し、プロジェクト間でのロジックやコンテキストの汚染リスクを低減します。
• バージョン管理を徹底する。 Gitまたは類似のシステムですべての変更を追跡し、必要に応じてAIが提案した編集をロールバックできるようにします。

レベル3：エンタープライズコントロール（AIゲートウェイによる集中管理）

ある程度の規模になると、「正しく設定してください」という依頼に頼るだけでは不十分です。集中管理、例えば AIゲートウェイ 可視性、ルーティング、強制力のあるガードレールが必要です。

間に何かを置く

Cursorがチーム全体で使われるようになると、エージェントが何をしているかを把握し、制御するための一元的な場所が必要になります。最もシンプルなパターンは、すべてのラップトップがプロバイダーと直接通信するのではなく、モデルとツールのトラフィックをゲートウェイ層経由でルーティングすることです。 MCPサーバー.

例えば、 TrueFoundry AI Gateway はアプリケーションとLLMプロバイダー間のプロキシとして設計されており、アプリケーションとMCPサーバーの間にも配置できるため、チームはルーティングを標準化し、ガバナンスを一元的に追加できます。実際には、これによりセキュリティチームは、リクエストの可視化、ポリシーの適用、リクエストとレスポンスを検証または変換するガードレールなどに対して、明確な制御ポイントを持つことができます。

これは重要です。なぜなら、ほとんどのAppSecツール（SAST/DAST/SCA）は、コードが書かれた後にしかそれを認識しないからです。ゲートウェイは、AIの使用状況がリアルタイムで可視化されるようにし、これはプロンプトインジェクション、安全でないツール使用、ポリシー違反が通常発生する場所でもあります。

重要な留意事項： この制御ポイントはモデル/ツールのトラフィックを管理しますが、環境や設定がそれらの制約を別途強制しない限り、ローカルでの操作（ターミナルコマンドの実行など）を自動的に防ぐものではありません。

IDとデータポリシーを標準化する： Cursorが広く使われる場合、他の開発ツールと同様のルールが適用されるべきです。シングルサインオン、一貫した設定、データ保持ゼロポリシーは、推測を減らし、監査を容易にします。

この段階では、Cursorは「単なるエディター」ではなくなり、開発インフラの一部となります。

まとめ

Cursorは摩擦をなくすため、強力だと感じられます。それがその目的です。しかし、摩擦には理由があり、特にコマンドの実行や依存関係の管理においてはそれが顕著です。Cursorを安全に利用するチームは、この摩擦と戦うことも、AIを盲目的に信頼することもありません。彼らはAIに思考と下書きを任せ、承認と説明責任は人間が負います。

このメンタルモデルはシンプルかつ効果的です。AIは提案できますが、最終的な決定は人間が行います。

開発ツールがよりエージェント的になるにつれて、どんな犠牲を払ってでも最速で動くチームが成功するわけではありません。意図を持って迅速に動き、スピードと慎重な監視、セキュリティのバランスを取るチームが成功するでしょう。

TrueFoundry AI GatewayでAIワークフローを保護し、管理しましょう。 デモを予約する.

よくある質問

Cursorはセキュリティリスクですか？ 

Cursorは、プロンプトインジェクション、エージェントの自動実行、サードパーティ連携による情報漏洩など、セキュリティリスクをもたらします。これらのリスクは現実のものですが、適切な制御、プライバシー設定、人的監視を適用することで管理可能です。企業チームは、Cursorをセキュリティインフラの一部として扱うべきです。

Cursorはプライバシー保護に安全ですか？ 

プライバシーモードが有効になっていれば、Cursorはプライバシー保護に安全です。しかし、ある程度の規模になると、「正しく設定してください」というだけでは不十分です。 AIゲートウェイ のような一元的な制御が、可視性、ルーティング、強制力のあるガードレールに必要です。機密ファイルが保護され、.cursorignoreのようなルールが使用されている必要があります。これらの対策がなければ、コードスニペットがローカル環境から流出し、機密情報や専有情報が漏洩する可能性があります。

CursorはIPを追跡しますか？

Cursorは、診断や分析のためにIPアドレスなどのネットワーク識別子を含む最小限のテレメトリーをログに記録する場合があります。企業のプライバシーポリシーとプライバシーモードは情報漏洩を制限するのに役立ちますが、ユーザーは一部のネットワークレベルのメタデータがサービスプロバイダーに表示される可能性があると想定すべきです。

Cursorのプライバシーモードは安全ですか？

プライバシーモードは、ローカルセッション外でのコード保持を減らし、AIサーバーへの露出を最小限に抑えるのに効果的です。プライバシーを強化する一方で、ドットファイル保護、.cursorignore、および制御された連携と組み合わせることで、機密性の高いプロジェクトに対する包括的なセキュリティを確保できます。