LLM の安全性と制御

AIモデルは予期しない挙動を示すことがあります。このドキュメントでは、エージェントが実行できる操作の制御、セーフティガードレールの設定、LLM の挙動を望ましい結果へ導く方法を説明します。

モデルの挙動を理解する

LLMは、データベースから事実を取り出したり決定論的なロジックを実行したりするのではなく、確率分布に基づいてテキストを生成します。同じ入力に対して異なる出力を生成したり、もっともらしいものの誤った事実やコードを生成 (ハルシネーション) したり、巧妙に作られたプロンプト (プロンプトインジェクション) の影響を受けたりすることがあります。

LLMが常に安全な判断を下すとは限りません。そのため、2つのアプローチを組み合わせます。エージェントが実行できる操作に厳格な制限を設けるセキュリティコントロールと、LLMの挙動をより良い結果へ導くステアリングメカニズムです。

LLMの仕組みをより深く理解するには、AIモデルの仕組みを参照してください。

セーフティの2つのアプローチ

Cherri Codeでは、AIエージェントの挙動を管理するために、相互に補完し合う2つのアプローチを提供しています。

セキュリティコントロール (決定論的な強制) : LLMが何を提案しても、危険な操作をブロックする厳格な境界です。これには、ターミナルコマンドの制限、操作を拒否する強制フック、承認ワークフロー、サンドボックス化が含まれます。セキュリティコントロールは、有害なエージェントアクションに対する主要な防御手段です。

LLMステアリング (非決定論的なガイダンス) : コンテキストや利用可能なアクションを調整し、LLMをより適切な挙動へ導く仕組みです。これには、プロンプトに指示を追加するルール、再利用可能なワークフローを提供するコマンド、エージェントの知識を拡充する連携が含まれます。ステアリングはエージェントの品質を向上させますが、有害なアクションを防止できるとは限りません。

両方のアプローチを併用してください。セキュリティコントロールは安全網となります。ステアリングにより、エージェントが問題のあるアクションをそもそも試みる頻度を減らせます。

セキュリティコントロール

これらの決定論的制御は、エージェントが実行できる操作に明確な制限を設けます。LLM の提案内容にかかわらず機能します。

ターミナルコマンドの制限

デフォルトでは、Cherri Code はターミナルコマンドを実行する前に承認を求めます。これにより、破壊的なコマンド (ファイルの削除、データベースの削除) 、機密データを公開するコマンド、意図しない副作用を引き起こすコマンドから保護されます。

エージェントがコマンドを実行しようとすると、コマンド全体を表示するプロンプトが表示されます。承認して実行する、拒否する、または実行前に変更できます。

自動承認のリスク

ターミナルコマンドの自動承認を有効にできますが、リスクを十分に理解してください。エージェントが知らないうちに破壊的なコマンドを実行したり、確認する前にコマンドが実行されたりする可能性があります。また、バグやプロンプトインジェクションにより、意図しない操作が行われるおそれもあります。

Enterprise チームは、チームダッシュボードで実行モードのポリシーを設定できます。Cherri Code 3.6 以降では、エンドユーザーは Auto-review (デフォルト) 、Allowlist、Run Everything から選択できます。Auto-review では、許可リストに登録された呼び出しを実行し、可能な場合はシェルコマンドをサンドボックス内で実行します。それ以外は、セーフティと呼び出しがユーザーの意図にどの程度一致するかに基づいて許可またはブロックを返す LLM 分類器に送られます。npm install、pip install、cargo build、make test など、承認を必要としないコマンドの許可リストを作成できます。

許可リストはベストエフォートであり、セキュリティ境界ではありません。悪意のあるエージェントやプロンプトインジェクションによって回避される可能性があります。許可リストは、必ずフックなどの他のセキュリティコントロールと組み合わせて使用してください。

詳細については、実行モードおよびエージェントのセキュリティを参照してください。

Enforcement フック

フックを使用すると、エージェントループの重要なポイントでカスタムロジックを実行できます。

プロンプト送信前: LLMに送信する前にプロンプトをスキャンし、機密データを検出します。APIキーや認証情報、個人識別情報 (PII) 、独自情報を含む送信をブロックします。
ファイル読み取り前: エージェントがファイルを読み取る前にスキャンします。シークレットを含む設定ファイル、データベースやログ内のPII、独自のアルゴリズムへのアクセスをマスキングまたはブロックします。
コード生成後: 生成されたコードがディスクに書き込まれる前にスキャンします。セキュリティ脆弱性 (SQLインジェクション、XSS) 、IP上の問題を引き起こす可能性があるライセンス付きコード、コード内のAPIキーや認証情報を確認します。
ターミナル実行前: 危険なコマンドをブロックするか、承認ワークフローを通すようにします。たとえば、すべてのgit pushコマンドをブロックしたり、任意のsudoコマンドに承認を必須にしたり、データベースのDROP文をブロックしたりできます。

例: git コマンドのブロック

このフックはシェルコマンドをインターセプトし、git を直接使用する操作をブロックして、代わりに GitHub CLI を使用するようユーザーに促します:

#!/bin/bashinput=$(cat)command=$(echo "$input" | jq -r '.command')if [[ "$command" =~ git[[:space:]] ]]; then    cat << EOF{  "permission": "deny",  "userMessage": "Git command blocked. Please use gh tool instead.",  "agentMessage": "Use 'gh' commands instead of raw git."}EOFfi

例: シークレットのマスキング

このフックはファイルの内容から GitHub API キーをスキャンし、見つかった場合はアクセスをブロックします:

#!/bin/bashinput=$(cat)content=$(echo "$input" | jq -r '.content')if echo "$content" | grep -qE 'gh[ps]_[A-Za-z0-9]{36}'; then    cat << EOF{  "permission": "deny"}EOF    exit 3fi

完全なドキュメントとさらに多くの例については、フックを参照してください。

機密ファイルの保護

リポジトリ内のすべてのファイルをAIが利用できるようにすべきではありません。設定ファイル、シークレット、機密データは保護する必要があります。

.cursorignore

.cursorignore ファイルは .gitignore と同様に機能しますが、Cherri Code がアクセスできる内容を制御します。.cursorignore のパターンに一致するファイルは、次の対象から除外されます。

エージェントによるファイルの読み取り
コンテキストの選択

.cursorignore はセキュリティ境界ではありません。AI による処理からファイルを除外するための利便機能ですが、次の点に注意してください。

ユーザーは無視されたファイルを手動で読み取れます
エージェントが無視されたコンテンツにアクセスする方法を見つける可能性があります
ターミナルコマンドと MCP ツールは、無視されたファイルを引き続き読み取れます

確実に保護するには、ファイルシステムの権限を設定するか、機密データを暗号化してください。

詳しい構文については、無視ファイルを参照してください。

.cursor ディレクトリの保護

リポジトリ内の .cursor ディレクトリには、プロジェクト固有の設定、ルール、キャッシュファイルが含まれます。Enterprise チームは、エージェントによるこのディレクトリの変更を防止できます。

有効にすると、エージェントは次の操作を行えません。

.cursor/ 内のファイルを変更する
.cursor/ ディレクトリを削除する
Cherri Code のルールまたは設定ファイルを変更する

ユーザーは引き続きこれらのファイルを手動で編集できますが、エージェントが編集するには承認が必要です。

チームダッシュボードの「.cursor ディレクトリの保護」 (Enterprise のみ) で設定します。

ブラウザのオリジン制御

Enterprise チームでは、ブラウザツール使用時に、エージェントがアクセスできるウェブサイトを制限できます。承認済みドメインの許可リストを定義すると、エージェントが他のオリジンにアクセスしようとした場合はブロックされます。

チームダッシュボードの「ブラウザ制御」 (Enterprise のみ) で設定します。

DLPツールとの連携

多くのエンタープライズでは、機密データを検出するデータ損失防止 (DLP) ツールがすでに導入されています。Cherri Codeは、3つの方法でDLPツールと連携できます。

エンドポイントDLPエージェント

ほとんどのエンドポイントDLPソフトウェアでは、Cherri Codeのネットワークトラフィックを検査できます。DLPを設定して、*.cursor.shドメインへのトラフィックを監視し、アウトバウンドリクエスト内の機密情報パターンをスキャンし、ポリシー違反をブロックまたは警告します。

ネットワークDLPはパフォーマンスに影響を与える場合があります。プロキシに関する考慮事項については、ネットワーク設定を参照してください。

フックベースのDLP

Cherri Codeのフック機能を使用して、カスタムDLPロジックを実装します。

プロンプト送信前： LLMに送信する前に、プロンプトに機密情報に該当するパターンがないかスキャンします。

#!/bin/bashinput=$(cat)prompt=$(echo "$input" | jq -r '.prompt')# API キーをチェックif echo "$prompt" | grep -qE 'api[_-]?key.*[A-Za-z0-9]{32}'; then    cat << EOF{  "continue": false,  "userMessage": "Prompt contains what looks like an API key. Remove it and try again."}EOF    exit 1fi# 機密データが見つからなければ許可cat << EOF{  "continue": true}EOF

コード生成後: 生成されたコードをディスクに書き込む前にスキャンします。

#!/bin/bashinput=$(cat)file_path=$(echo "$input" | jq -r '.file_path')edits=$(echo "$input" | jq -r '.edits[].new_string')# ハードコードされた認証情報をチェックif echo "$edits" | grep -qE 'password.*=.*["\047][^"\047]+["\047]'; then    # 分析のためDLP APIに送信    curl -X POST "https://dlp.yourcompany.com/scan" \      -H "Content-Type: application/json" \      -d "{\"content\":\"$edits\",\"file\":\"$file_path\"}"        # APIレスポンスを確認して適切に対応fi

サードパーティ製DLPとの連携

フックから既存のDLPベンダーのAPIを呼び出します：

#!/bin/bashinput=$(cat)content=$(echo "$input" | jq -r '.content')# DLP APIに送信response=$(curl -s -X POST "https://dlp-api.company.com/analyze" \  -H "Authorization: Bearer $DLP_API_TOKEN" \  -H "Content-Type: application/json" \  -d "{\"text\":\"$content\"}")# レスポンスを解析is_allowed=$(echo "$response" | jq -r '.allowed')if [ "$is_allowed" = "true" ]; then    cat << EOF{  "permission": "allow"}EOFelse    violation=$(echo "$response" | jq -r '.violation_type')    cat << EOF{  "permission": "deny",  "userMessage": "Content blocked by DLP policy: $violation"}EOFfi

このアプローチにより、すべての開発ツールのDLPポリシーを一元管理できます。

承認ワークフロー

Cherri Codeでは、すべてのエージェントアクションで承認を求めるよう設定できます。ユーザーは、ファイルの読み取りや編集、ターミナルコマンドの実行、ネットワークリクエストの送信前に常に確認を求めるよう、エージェントを設定できます。

ただし、この方法では開発作業が大幅に遅くなります。エージェントはタスクを完了するために複数のアクションを必要とするため、各アクションで承認を求めるとワークフローが煩雑になります。代わりに、多くのチームはフックを使用して危険な操作を自動的にブロックしています。

モデルプロバイダーのセーフティ

すべてのモデルプロバイダー (OpenAI、Anthropic、Google、SpaceXAI) は、有害なコンテンツをフィルタリングするセーフティシステムを導入しています。これらのシステムは、有害な情報を求めるプロンプトを拒否し、危険なコードの生成を拒否し、出力の安全性をフィルタリングします。

Cherri Codeはプロバイダーと連携し、ユーザーへのデプロイ前にモデルがセーフティ基準を満たしていることを確認しています。プロバイダーはモデルのセーフティ上の問題を継続的に評価しています。ただし、これらはセキュリティ境界ではありません。セーフティシステムは回避されたり、欺かれたりする可能性があります。必ずフックとアクセスポリシーを通じて、独自の制御を実装してください。

サンドボックス化に関する注意点

Cherri Code エージェントはデフォルトでローカルマシン上で実行されます。エージェントは、ユーザーが読み取れるファイルの読み取り、書き込めるファイルへの書き込み、実行できるコマンドの実行、アクセスできるネットワークリソースへのアクセスが可能です。

エージェントとユーザーアカウントの間にセキュリティ境界はありません。アカウントでファイルを削除できる場合、エージェントもファイルを削除できます (デフォルトでは承認が必要です) 。

サンドボックス化のオプション

より強力な隔離が必要な場合は、Cloud Agents を使用して Cherri Code を別の VM で実行する、ファイルシステムの権限で Cherri Code プロセスがアクセスできる範囲を制限する、または本番システムへのアクセスを制限した専用の開発マシンで Cherri Code を実行してください。

ほとんどのエンタープライズでは、組み込みの承認要件とフックで十分に制御できます。

ファイルシステムの権限

防御をさらに強化するため、ファイルシステムの権限を使用して機密ファイルを保護します。

シークレットファイルへのアクセスを制限する:

# 特定のユーザーだけがシークレットを読み取れるようにするchmod 600 .envchown app-user:app-user .env# または、アクセスを制限した別のディレクトリを使用するchmod 700 /etc/app/secrets

機密性の高いリポジトリを分離する: 特に機密性の高いコードは、アクセスを制限した別のリポジトリに保管します。Cherri Code を実行するマシンには、これらのリポジトリをクローンしないでください。

暗号化ファイルシステム: 特に機密性の高いデータには、明示的にマウントする必要がある暗号化ファイルシステムを使用します。Cherri Code がアクセスできるディレクトリには、これらのファイルシステムをマウントしないでください。

LLMステアリング

セキュリティコントロールは、LLMが有害なアクションを提案した後にブロックします。ステアリングメカニズムは、LLMが最初からより良い提案を行えるように導きます。これらは非決定論的です。結果の改善には役立ちますが、防止を保証するものではありません。

ルール

ルールは、リクエストのたびに LLM のコンテキストウィンドウへ指示を追加します。コーディング標準の策定、アーキテクチャパターンの適用、セキュリティ要件の設定、プロジェクト固有の規約の定義に使用できます。

ルールには 3 つの適用範囲があります。

ユーザールール: 特定のユーザーのすべてのプロジェクトに適用されます。コードスタイルや優先するライブラリなど、個人の設定に使用します。

プロジェクトルール: プロジェクトに携わる全員に適用されます。命名規則やフレームワークの使用方法など、プロジェクト固有の標準に使用します。

チームルール: 組織内のすべてのプロジェクトに適用されます。セキュリティ要件やコンプライアンスルールなど、会社全体の標準に使用します。

LLM はレスポンスを生成する際、適用可能なすべてのルールを参照します。ルールに従おうとしますが、ルールは提案であり、保証ではありません。必ず満たす必要がある要件には、ルールとフックを組み合わせてください。

設定と例については、ルールを参照してください。

コマンドとワークフロー

コマンドでは、エージェントが/testや/deployなどのスラッシュコマンドで呼び出せる再利用可能なプロンプトをまとめられます。コマンドを使うと、チーム全体で一般的なワークフローを標準化できます。

ワークフロー: エージェントを複雑なタスクへと導く、複数のステップからなるプロセスを作成します。たとえば、/security-reviewコマンドでは、SQLインジェクションの検出、公開されているシークレットの確認、入力サニタイズの検証、セキュリティレポートの生成をエージェントに指示できます。

プロンプトライブラリ: 一般的なタスク向けに、テスト済みプロンプトのコレクションを作成します。これにより、エージェントの挙動のばらつきを抑え、組織内の知識を蓄積できます。

コマンドの適用範囲は、チーム、プロジェクト、またはユーザー単位です。チーム管理者は、すべての開発者に表示される組織全体向けのコマンドを作成できます。

設定と例については、コマンドを参照してください。

MCP によるコンテキストの拡張

Model Context Protocol (MCP) サーバーを使用すると、エージェントは外部データソースにアクセスできます。MCP を使用して、社内ドキュメントを取得したり、内部 API をクエリしたり、ナレッジベースにアクセスしたり、開発ツールと連携したりできます。

MCP は、エージェントが通常は得られない情報をコンテキストに追加します。たとえば、MCP から API 仕様にアクセスできるようにすることで、エージェントは内部サービスを正しく呼び出すコードを生成できます。

MCP はチームまたはユーザー単位で設定されます。フックとは異なり、MCP はポリシーを強制するものではなく、エージェントがより適切な判断を行うための情報を提供します。

設定と例については、MCP 連携を参照してください。

Enterprise 向けの高度なセーフティコントロール

組織全体への強制適用とセキュリティポリシーについては、チームまでお問い合わせください。

Contact Sales

プロンプト送信前: LLMに送信する前にプロンプトをスキャンし、機密データを検出します。APIキーや認証情報、個人識別情報 (PII) 、独自情報を含む送信をブロックします。
ファイル読み取り前: エージェントがファイルを読み取る前にスキャンします。シークレットを含む設定ファイル、データベースやログ内のPII、独自のアルゴリズムへのアクセスをマスキングまたはブロックします。
コード生成後: 生成されたコードがディスクに書き込まれる前にスキャンします。セキュリティ脆弱性 (SQLインジェクション、XSS) 、IP上の問題を引き起こす可能性があるライセンス付きコード、コード内のAPIキーや認証情報を確認します。
ターミナル実行前: 危険なコマンドをブロックするか、承認ワークフローを通すようにします。たとえば、すべてのgit pushコマンドをブロックしたり、任意のsudoコマンドに承認を必須にしたり、データベースのDROP文をブロックしたりできます。

例: git コマンドのブロック

このフックはシェルコマンドをインターセプトし、git を直接使用する操作をブロックして、代わりに GitHub CLI を使用するようユーザーに促します:

#!/bin/bashinput=$(cat)command=$(echo "$input" | jq -r '.command')if [[ "$command" =~ git[[:space:]] ]]; then    cat << EOF{  "permission": "deny",  "userMessage": "Git command blocked. Please use gh tool instead.",  "agentMessage": "Use 'gh' commands instead of raw git."}EOFfi

例: シークレットのマスキング

このフックはファイルの内容から GitHub API キーをスキャンし、見つかった場合はアクセスをブロックします:

#!/bin/bashinput=$(cat)content=$(echo "$input" | jq -r '.content')if echo "$content" | grep -qE 'gh[ps]_[A-Za-z0-9]{36}'; then    cat << EOF{  "permission": "deny"}EOF    exit 3fi

完全なドキュメントとさらに多くの例については、フックを参照してください。

機密ファイルの保護

.cursorignore

エージェントによるファイルの読み取り
コンテキストの選択

.cursorignore はセキュリティ境界ではありません。AI による処理からファイルを除外するための利便機能ですが、次の点に注意してください。

ユーザーは無視されたファイルを手動で読み取れます
エージェントが無視されたコンテンツにアクセスする方法を見つける可能性があります
ターミナルコマンドと MCP ツールは、無視されたファイルを引き続き読み取れます

確実に保護するには、ファイルシステムの権限を設定するか、機密データを暗号化してください。

詳しい構文については、無視ファイルを参照してください。

.cursor ディレクトリの保護

有効にすると、エージェントは次の操作を行えません。

.cursor/ 内のファイルを変更する
.cursor/ ディレクトリを削除する
Cherri Code のルールまたは設定ファイルを変更する

ユーザーは引き続きこれらのファイルを手動で編集できますが、エージェントが編集するには承認が必要です。

チームダッシュボードの「.cursor ディレクトリの保護」 (Enterprise のみ) で設定します。

#!/bin/bashinput=$(cat)prompt=$(echo "$input" | jq -r '.prompt')# API キーをチェックif echo "$prompt" | grep -qE 'api[_-]?key.*[A-Za-z0-9]{32}'; then    cat << EOF{  "continue": false,  "userMessage": "Prompt contains what looks like an API key. Remove it and try again."}EOF    exit 1fi# 機密データが見つからなければ許可cat << EOF{  "continue": true}EOF

コード生成後: 生成されたコードをディスクに書き込む前にスキャンします。

#!/bin/bashinput=$(cat)file_path=$(echo "$input" | jq -r '.file_path')edits=$(echo "$input" | jq -r '.edits[].new_string')# ハードコードされた認証情報をチェックif echo "$edits" | grep -qE 'password.*=.*["\047][^"\047]+["\047]'; then    # 分析のためDLP APIに送信    curl -X POST "https://dlp.yourcompany.com/scan" \      -H "Content-Type: application/json" \      -d "{\"content\":\"$edits\",\"file\":\"$file_path\"}"        # APIレスポンスを確認して適切に対応fi

サードパーティ製DLPとの連携

フックから既存のDLPベンダーのAPIを呼び出します：

#!/bin/bashinput=$(cat)content=$(echo "$input" | jq -r '.content')# DLP APIに送信response=$(curl -s -X POST "https://dlp-api.company.com/analyze" \  -H "Authorization: Bearer $DLP_API_TOKEN" \  -H "Content-Type: application/json" \  -d "{\"text\":\"$content\"}")# レスポンスを解析is_allowed=$(echo "$response" | jq -r '.allowed')if [ "$is_allowed" = "true" ]; then    cat << EOF{  "permission": "allow"}EOFelse    violation=$(echo "$response" | jq -r '.violation_type')    cat << EOF{  "permission": "deny",  "userMessage": "Content blocked by DLP policy: $violation"}EOFfi

このアプローチにより、すべての開発ツールのDLPポリシーを一元管理できます。

# 特定のユーザーだけがシークレットを読み取れるようにするchmod 600 .envchown app-user:app-user .env# または、アクセスを制限した別のディレクトリを使用するchmod 700 /etc/app/secrets

組織全体への強制適用とセキュリティポリシーについては、チームまでお問い合わせください。

Contact Sales

プロンプト送信前: LLMに送信する前にプロンプトをスキャンし、機密データを検出します。APIキーや認証情報、個人識別情報 (PII) 、独自情報を含む送信をブロックします。
ファイル読み取り前: エージェントがファイルを読み取る前にスキャンします。シークレットを含む設定ファイル、データベースやログ内のPII、独自のアルゴリズムへのアクセスをマスキングまたはブロックします。
コード生成後: 生成されたコードがディスクに書き込まれる前にスキャンします。セキュリティ脆弱性 (SQLインジェクション、XSS) 、IP上の問題を引き起こす可能性があるライセンス付きコード、コード内のAPIキーや認証情報を確認します。
ターミナル実行前: 危険なコマンドをブロックするか、承認ワークフローを通すようにします。たとえば、すべてのgit pushコマンドをブロックしたり、任意のsudoコマンドに承認を必須にしたり、データベースのDROP文をブロックしたりできます。

例: git コマンドのブロック

このフックはシェルコマンドをインターセプトし、git を直接使用する操作をブロックして、代わりに GitHub CLI を使用するようユーザーに促します:

#!/bin/bashinput=$(cat)command=$(echo "$input" | jq -r '.command')if [[ "$command" =~ git[[:space:]] ]]; then    cat << EOF{  "permission": "deny",  "userMessage": "Git command blocked. Please use gh tool instead.",  "agentMessage": "Use 'gh' commands instead of raw git."}EOFfi

例: シークレットのマスキング

このフックはファイルの内容から GitHub API キーをスキャンし、見つかった場合はアクセスをブロックします:

#!/bin/bashinput=$(cat)content=$(echo "$input" | jq -r '.content')if echo "$content" | grep -qE 'gh[ps]_[A-Za-z0-9]{36}'; then    cat << EOF{  "permission": "deny"}EOF    exit 3fi

完全なドキュメントとさらに多くの例については、フックを参照してください。

機密ファイルの保護

.cursorignore

エージェントによるファイルの読み取り
コンテキストの選択

.cursorignore はセキュリティ境界ではありません。AI による処理からファイルを除外するための利便機能ですが、次の点に注意してください。

ユーザーは無視されたファイルを手動で読み取れます
エージェントが無視されたコンテンツにアクセスする方法を見つける可能性があります
ターミナルコマンドと MCP ツールは、無視されたファイルを引き続き読み取れます

確実に保護するには、ファイルシステムの権限を設定するか、機密データを暗号化してください。

詳しい構文については、無視ファイルを参照してください。

.cursor ディレクトリの保護

有効にすると、エージェントは次の操作を行えません。

.cursor/ 内のファイルを変更する
.cursor/ ディレクトリを削除する
Cherri Code のルールまたは設定ファイルを変更する

ユーザーは引き続きこれらのファイルを手動で編集できますが、エージェントが編集するには承認が必要です。

チームダッシュボードの「.cursor ディレクトリの保護」 (Enterprise のみ) で設定します。

#!/bin/bashinput=$(cat)prompt=$(echo "$input" | jq -r '.prompt')# API キーをチェックif echo "$prompt" | grep -qE 'api[_-]?key.*[A-Za-z0-9]{32}'; then    cat << EOF{  "continue": false,  "userMessage": "Prompt contains what looks like an API key. Remove it and try again."}EOF    exit 1fi# 機密データが見つからなければ許可cat << EOF{  "continue": true}EOF

コード生成後: 生成されたコードをディスクに書き込む前にスキャンします。

#!/bin/bashinput=$(cat)file_path=$(echo "$input" | jq -r '.file_path')edits=$(echo "$input" | jq -r '.edits[].new_string')# ハードコードされた認証情報をチェックif echo "$edits" | grep -qE 'password.*=.*["\047][^"\047]+["\047]'; then    # 分析のためDLP APIに送信    curl -X POST "https://dlp.yourcompany.com/scan" \      -H "Content-Type: application/json" \      -d "{\"content\":\"$edits\",\"file\":\"$file_path\"}"        # APIレスポンスを確認して適切に対応fi

サードパーティ製DLPとの連携

フックから既存のDLPベンダーのAPIを呼び出します：

#!/bin/bashinput=$(cat)content=$(echo "$input" | jq -r '.content')# DLP APIに送信response=$(curl -s -X POST "https://dlp-api.company.com/analyze" \  -H "Authorization: Bearer $DLP_API_TOKEN" \  -H "Content-Type: application/json" \  -d "{\"text\":\"$content\"}")# レスポンスを解析is_allowed=$(echo "$response" | jq -r '.allowed')if [ "$is_allowed" = "true" ]; then    cat << EOF{  "permission": "allow"}EOFelse    violation=$(echo "$response" | jq -r '.violation_type')    cat << EOF{  "permission": "deny",  "userMessage": "Content blocked by DLP policy: $violation"}EOFfi

このアプローチにより、すべての開発ツールのDLPポリシーを一元管理できます。

# 特定のユーザーだけがシークレットを読み取れるようにするchmod 600 .envchown app-user:app-user .env# または、アクセスを制限した別のディレクトリを使用するchmod 700 /etc/app/secrets

組織全体への強制適用とセキュリティポリシーについては、チームまでお問い合わせください。

Contact Sales

Command Palette

はじめに

Agent

Grok Bot

カスタマイズ

Cloud Agents

オリジン

連携機能

SDK

CLI

チームとEnterprise

LLM の安全性と制御

Command Palette

はじめに

Agent

Grok Bot

カスタマイズ

Cloud Agents

オリジン

連携機能

SDK

CLI

チームとEnterprise

LLM の安全性と制御

Command Palette

はじめに

Agent

Grok Bot

カスタマイズ

Cloud Agents

オリジン

連携機能

SDK

CLI

チームとEnterprise

LLM の安全性と制御