Redthread ドキュメント

Redthread は AI ネイティブ・アプリケーション保護プラットフォーム（ANAPP）であり、基盤となるのは Redthreadです。エージェント不要を第一とし——中核となる価値の提供にあたって何もインストールしません——すべての機能は、 ワークスペースごとに有効化するモジュール として、1つのコンソールから利用できます。

Redthread はまずマップを構築します ——エージェント、コード、クラウド、インフラがどうつながっているかを把握するまでは、検出結果の一覧はただの一覧にすぎないからです。Redthread は、環境全体を 1つのグラフ にまとめます——エージェント、アプリケーション、コード、クラウドアカウント、アイデンティティ、すでに運用しているセキュリティコントロール、そしてそれらが到達できるデータまで。すべてのモジュールが同じグラフを読み書きするため、最初に目に入るリスクは、一覧上の孤立した検出結果ではなく、レイヤーをまたぐリスクです。

このマップの上で、プラットフォームはワークスペースごとに有効化するモジュールとして動作します：

• AIリスク評価 （評価 & 統合）——無料・エージェント不要の入口です。運用中のすべての AI を把握し、危険な組み合わせを優先順位付けして OWASP Top 10 for LLM および Agentic アプリケーションにマッピングします。さらにエージェント不要で接続するだけで、ポスチャスコア、どの監視も及んでいない AI サーフェス、そして Redthread のモジュールで置き換えられる既存ツールの 置き換えマップ が得られ、入力値に基づく 統合による ROI も算出されます。
• エクスプロイト検証 （AI アプリケーションテスト）——評価で上位にランク付けされた最もリスクの高い経路を実証します。自律エージェントがチャットボット、エージェント、RAG エンドポイントを OWASP LLM Top 10（MITRE ATLAS にマッピング）に沿って検査し、すべての検出結果に再現可能な概念実証（PoC）が付属します。
• シャドーAIの発見 ——環境全体にある AI 搭載機能を、誰も登録していないものも含めてすべて棚卸しします。
• クラウド & インフラのポスチャ ——エージェント不要（何もインストールしない）でクラウドを接続し、アセット、アイデンティティ、データをマッピングし、機密データストアを分類（DSPM）して、クラウドをまたぐ攻撃経路を明らかにします。
• エンドポイントテレメトリ（検知のみ） ——任意で導入できるコア内蔵の軽量エージェントが、OS が安全とするサーフェス上でホストのインベントリとポスチャを報告します。ブロックは一切行いません。リアルタイムの防御は、ロードマップ上のパートナー提供アドオンです。
• Agentic Trust & Protection Platform ——すべてのエージェント／アイデンティティに SPIFFE ID を付与し、実証済みのエクスプロイトに基づいて、署名付き・TTL 付きの信頼状態イベント（safe/unsafe/revoked）を配信します。これにより、オーケストレーター、ゲートウェイ、SIEM が数秒で対応できます。詳しくは次を参照してください： Agentic Trust & Protection Platform。
• CI/CD ゲート ——すべてのプルリクエストでスキャンし、実証済みの攻撃経路を生み出すマージをブロックします。
• 継続的プラットフォーム ——ドリフトとトレンドを伴う定期的な再評価により、今週本番環境にあるものをカバレッジに反映します。
• 修正 & レポート ——わかりやすい修正策とドラフトのプルリクエスト。証明書（Letter of Attestation）、完全な技術レポート、機械可読版を、監査人が求めるフレームワークにマッピングして提供します。
• アイデンティティ & アクセス ——ワークスペース向けの SSO、SCIM プロビジョニング、ロール、監査ログ。

推測ではなく、実証。 検出結果とは、エンジンが実際に到達した、またはエクスプロイトしたものであり、再現のための正確な手順が付きます。カバレッジを主張するのは、グラフが裏付けている範囲に限られます。プラットフォームはエージェント不要で、検知を優先します。防御やブロックの動作はすべて、署名付きでオプトイン方式の、顧客が所有する例外であり、デフォルトになることはありません。また、当社がセンサーに配信するすべての更新は、 AI Rollout Safety ゲートを通じて段階的に展開されます（カナリアリング、自動停止）。

このドキュメントでは、 はじめに、 プラットフォームアーキテクチャ、 コアコンセプト （プラットフォームの仕組み）、タスク別の ガイド、そして完全な API リファレンス を網羅しており、CI や独自のスクリプトからすべてのモジュールを操作できます。

最新情報

2026年10月31日

• ホワイトラベルレポート。 有料プランでは、オーナーが設定 → 一般 → レポートのブランディングで社名、連絡先、ロゴを設定します。コンプライアンスレポートと証明書（Letter of Attestation）には貴社が発行者として表示され、Redthread を非表示にするチェックを入れない限り、Redthread はプラットフォームとして明記されます。
• センサー更新の段階的配信が稼働。 新しいエンドポイントエージェントのビルドは検証後、カナリアリング（ホストの1% → 10% → 50% → 100%）で提示され、リングが正常に戻らなければ自動で停止します。
• アセットは一度だけ入力。 ペンテストスキャンは、環境にすでにあるサイトから選ぶようになり、新しいURLは一度だけ保存されます。登録済みサイトの手動スキャンは、そのサイトのナレッジと履歴を使います。今すぐスキャン、スケジュール、ドリフト再スキャン、CIトリガーも手動スキャンと同様に検証済みドメインが必要です。インフラスキャンでは、別のクラウドを追加したり、クラウドを1つだけ切断したりできます。
• 毎日の MCP レジストリスキャンの対象は 53,270 サーバーになりました。 すべてのサーバーに署名付きの主張が付与され、その日の署名付きマニフェストは公開の Sigstore Rekor ログにアンカーされます。10月30日のスキャンでは、掲載のすり替え（名前の指す先が別のドメインまたはパッケージの所有者に変わっているもの）が 1,489 件、一度も公開されていないバージョンを指定している掲載が 227 件、宣言されたものとは別のリポジトリからビルドされたパッケージが 35 件見つかりました。詳しくは 最新の数値。
• ツール定義にフィンガープリントを付与（ルール atf-6）。 認証情報なしで応答するリモートサーバー（現時点で 20,504 台）について、スキャンはツール一覧の sha256 フィンガープリントを記録し、バージョンが変わっていないのにツールが変わったサーバーを不合格にします。これがラグプルの手口です。ゲートとフックはこれを拒否します。
• Claude Code と Cursor 向けのフックと AIBOM（プレビュー）。 atpp hook claude|cursor は、MCP ツールの呼び出しを実行する前に、サーバーの署名付きの主張と照合します。 atpp check-config --cyclonedx は、設定済みの MCP サーバーの CycloneDX 1.6 部品表を出力します。
• Enforce がコンテンツを検査（プレビュー）。 ゲートウェイがエージェントのトラフィックの中身を調べ、プロンプトインジェクションの指示、リクエストに含まれて外部へ出ていくシークレット、細工された MCP ツール一覧を検出するようになりました。アイデンティティを enforce に切り替えるまでは監視のみで、パターンに一致するかどうかで判定するため、言い換えをすり抜けられることがあります。これは防御の一層であり、保証ではありません。
• ワークスペースの署名鍵をアプリの外に移しました。 信頼イベントに署名する鍵は、別の署名サービスで保管され、Oracle Cloud Vault の鍵で封印されています。アプリは署名を依頼できますが、鍵を読み取ったりコピーしたりすることはできません。
• 信頼台帳は編集できません。 エージェントの信頼イベントは PostgreSQL に保存され、データベース自体が台帳の更新、削除、切り詰めを拒否するため、この保証はアプリケーションの動作に依存しません。
• コンプライアンスレポートと証明書（Attestation letter）を、標準ごとにアプリ内で開けます。 SOC 2、ISO 27001、ISO 42001、PCI DSS v4.0、GDPR、HIPAA、NIST CSF、NIST AI RMF、EU AI Act から選び、ダウンロード（HTML、PDF、JSON）するか、メールまたは Slack で共有できます。これらのビューは監査を支える相互参照であり、認証ではありません。詳しくは レポート & 証明。
• ウェブサイトがサインイン状態を認識します。 メニューには「ログイン」の代わりに「ダッシュボード」が表示され、サインインが必要なドキュメントのリンクは、サインイン後にそのセクションへ戻ります。
• アカウントとセッションのデータを安全に書き込みます。 書き込みはリカバリ用コピーを伴うアトミックな処理になったため、クラッシュしてもワークスペースが切り詰められることはなく、読み取りに失敗しても空のワークスペースになることはありません。

2026年10月7日

• Oracle Cloud がすべての Oracle アカウントで接続できるようになりました。 2023年以降に作成されたアカウントはアイデンティティ・ドメインを使用しており、メールアドレスを持たない当社のスキャン用ユーザーは拒否されていました。ワンクリック設定でこのユーザーにメールアドレスを付与するようになり、ユーザー、グループ、ポリシーの名前も Redthread に統一されました。
• エンドポイントセンサーを1つのコマンドでインストールできるようになりました。 Estate Scan でキーを発行し、macOS、Linux、Windows のいずれかでコマンドを1つ貼り付けるだけです。ダウンロードの検証、バックグラウンドサービスのインストール、最初のレポート送信が行われ、マシンが表示されると画面で確認できます。対応するアンインストールコマンドも同じ画面にあります。
• レポートを送信したマシンはすべてエステートに残ります。 以前は新しいレポートが届くたびに一覧全体が置き換えられ、最後にレポートしたマシンしか表示されませんでした。現在は各レポートが自分のマシンだけを更新し、クラウドの再スキャン後もセンサーはグラフに残ります。
• クラウド VM 上のセンサーは、その VM に統合されます。 AWS、Oracle Cloud、Azure、Google Cloud では、センサーがインスタンス ID を読み取るため、クラウドスキャンで既に検出された VM は、両方のビューを持つ1つのノードとして表示されます。
• 既存のクラウド VM には、ご自身の Cloud Shell からインストールできます。 Oracle Cloud、Azure、Google Cloud では、1つのコマンドで、ご自身のログインを使って実行中のすべての VM にセンサーをインストールします。Redthread が VM にアクセスすることはありません。
• 新しいクラウド VM には初回起動時にインストールされます。 VM の startup-script フィールド用の起動スクリプトにより、新しい VM の初回起動時に常駐型のセンサーがインストールされます。
• ペンテストスキャンの回数はエステートの規模に連動します。 各有料プランには、ワークロード10件ごとに月1回のペンテストスキャンが含まれます（Starter 3回、Growth 15回、Enterprise 15回以上）。それを超える場合は、スキャンパックを利用するか、スキャンごとにお支払いください。詳しくは次をご覧ください： プラン。
• 環境全体を1つのマップに。 Redthread Flow は、すべてのクラウド、マシン、アイデンティティと、クラウド間を含むそれらのつながりを示す環境マップから始まるようになりました。「クラウドの問題」と「攻撃経路」は左メニューに専用ページがあります。
• 接続済みのすべてのクラウドをスキャンします。 複数のクラウド（例：AWS と Oracle Cloud）を接続している場合、「環境をスキャン」はそれぞれをスキャンし、各クラウドの検出結果とグラフの該当部分を個別に保持します。そのため、あるクラウドのスキャンが別のクラウドを置き換えることはありません。
• Mac が名前で表示されるようになりました。 Mac は、ネットワークアドレスではなくコンピュータ名で表示されるようになりました。

ガイド：エステート全体を接続する

目標：すべてのソースを一度ずつ接続し、 エステートをスキャン を1回実行するだけで、Web サイト、コード、クラウド、マシン、そしてそれらで動作する AI をマッピングできるようにすることです。ここでの接続はすべて読み取り専用で、無料です。手順はどの順番でも構いません。接続が完了すると、 環境スキャン の各レーンが緑色になります。

始める前に

1. まず app.redthreadsec.com に業務用メールアドレスでサインインします。
2. 確認メールに記載されたリンクをクリックします。確認が済むまで、スキャンはロックされたままです。
3. 次を開きます： 環境スキャン。サインイン後に最初に表示されるページです。

1. Web サイトとアプリ

1. アプリの Web サイトとアプリ レーンに、メインの Web サイトまたはアプリのアドレスを貼り付けて追加します。
2. 公開サイトごとに繰り返します。認証情報は不要で、当社は公開ページのみを読み取ります。
3. 後でサイトに対してペンテストを実行するには、まずそのサイトの所有者であることを証明します（どのように)。

2. コード

1. アプリの コード レーンで、次をクリックします： Sign in with GitHub。
2. 読み取り専用のアクセスを承認します。リポジトリ内の AI フレームワーク、シークレット、インフラストラクチャコードがスキャンされます。

3. クラウドとインフラストラクチャ

各クラウドはワンクリックで接続でき、付与するのは読み取り専用のアクセスで、ご自身のコンソールでいつでも取り消せます。クラウドが接続されると、最初のスキャンが自動的に実行されます。

• AWS： 次をクリックします： AWS を開いてロールを作成。IAM の確認事項にチェックを入れ、次をクリックします： Create stack（スタックの作成）。1分ほど待ってから、12桁の AWS アカウント番号を Redthread に入力します。AWS の管理担当者でない場合は、次を使用してください： 送信用リンクを取得。
• Azure： 次の見出しの下で： AWS 以外をご利用ですか？、次を選択します： Microsoft Azure。Microsoft でサインインして Redthread を承認し、サブスクリプションを選んで、次をクリックします： Create。
• Google Cloud： 次を選択します： Google Cloud。Google でサインインして承認し、スキャンするプロジェクトを選びます。
• Oracle Cloud： 次を選択します： Oracle Cloud。次をクリックします： Oracle Cloud を開いてアクセスを作成 。管理者としてサインインします。次にチェックを入れます： I have reviewed and accept the Oracle Terms of Use。次をクリックします： 今後の予定 （2回）。次にチェックを入れます： Run apply 。次をクリックします： Create。Redthread に戻ると、数分で接続されます。

以降のスキャンはタイマーでは実行されません。変更を反映するには、次をクリックします： エステートをスキャン、または スキャン （クラウドのカード上）。

4. エンドポイントセンサー（任意）

センサーは1台のノート PC、サーバー、またはクラウド VM を監視し、そのソフトウェア、セキュリティ設定、動作している AI ツールをレポートします。何かをブロックすることはありません。

1. アプリの エンドポイントセンサーをインストール レーンで、次をクリックします： 登録キーを発行。
2. ノート PC またはサーバー： macOS または Linux のコマンドを Terminal に、Windows のコマンドを PowerShell にコピーします。サーバーでは、 sudo を sh の前に付けて、マシン全体にインストールされるようにします。マシンがレポートを開始すると、画面に表示されます。
3. 稼働中のクラウド VM： 次を開きます： 既存のクラウド VM：すべてにインストール。お使いのクラウド用のコマンドをコピーし、そのクラウドの Cloud Shell に貼り付けます。Oracle Cloud では、Cloud Shell は右上の次のメニューにあります： Developer tools 。Azure と Google Cloud では、コンソール上部の Cloud Shell アイコンから開きます。実行中のすべての VM にインストールされ、概要が表示されます。AWS では、各インスタンスでインストールコマンドを実行してください。
4. 新しいクラウド VM： 次を開きます： 新しいクラウド VM：自動でインストール 。VM の作成時に、スクリプトを startup-script フィールドに貼り付けます。
5. センサーを削除するには： 次の項目にあるコマンドを実行します： アンインストール （対象のマシン上で）。

5. AI エージェントとサービス

入力は不要です。上記のソースから検出され、AI インベントリに一覧表示されます。

6. スキャン

1. 次をクリックします： エステートをスキャン。接続済みのすべてをマッピングします。ペンテストスキャンの回数を消費することはありません。
2. グラフと次を開きます： 検出結果 。資産、そこで動作する AI、そしてそれらの間の攻撃経路を確認できます。
3. 1つのアプリに対して脆弱性の悪用を実証するペンテストを行うには、ペンテストスキャンを開始します。Free プランには生涯で1回、有料プランにはワークロード10件ごとに月1回が含まれます。

クイックスタート——ブラウザで

結果を確認する最速の方法です。インストール不要、カード登録不要。

1. アカウントを作成します。 ブラウザで app.redthreadsec.com/app にアクセスし、メールアドレスで新規登録してください。業務用メールが最適ですが、個人用でも利用できます。カード登録は不要です。
2. 環境を接続します。 最初に表示されるのは 環境スキャン。接続する範囲は自由です。Web サイトの URL には認証情報が不要で、GitHub はワンクリック、各クラウドもワンクリック、エンドポイントセンサーはマシンごとに1コマンドです。読み取り専用のクラウド接続が、カバレッジを最も大きく広げます。手順： 環境全体を接続する。これらすべてにわたる検出は無料・無制限です。メーターでまだ見えていない部分がわかり、スキャンが妨げられることはありません。
3. メールアドレスを確認します。 送信されたリンクをクリックします。これでアクティブスキャンが利用可能になります。（届かない場合は、アプリの「再送信」を使用してください。）
4. 1つの対象にペネトレーションテストを実行します。 エクスプロイトを実証するアクティブスキャンでは、アプリの ステージング URL を貼り付けます——アプリが稼働している実際のアドレスです（本番環境ではありません）。より詳細なスキャンを行う場合は、任意でコード（ .zipファイル）をドラッグして追加します。最後に次のボタンを押します： スキャンを開始。
5. 動作を確認します。 スキャンは隔離されたサンドボックスで実行され、通常は数分で完了します。各カテゴリをリアルタイムで検査する様子を確認できます。
6. 検出結果を確認します。 実証された各脆弱性には、深刻度、影響、わかりやすい修正策が付属します。有料プランでは、すべての検出結果に動作する概念実証（PoC）と修正案のドラフトも含まれます。

アプリを使いたい場合は Redthread は Mac 版と Windows 版も ダウンロードページから入手できます。専用ウィンドウで動く同じ製品であり、データはサーバー上に保存されるため、アプリとブラウザには常に同じワークスペースが表示されます。サインインするには、アプリにメールアドレスを入力し、メールで届いたリンクを開きます——ブラウザが Redthread を開くかどうかを確認し、サインインをアプリに引き渡します（ millenniums:// リンクは1回限り有効で、15分で失効します）。インストーラーはまだ Apple または Microsoft の証明書で署名されていないため、ダウンロードしたものは一度確認するまでブロックされます。Mac では、 ダウンロードページ にある1行の Terminal インストールを使えば確認プロンプトは表示されません。.dmg の場合は、次の手順で一度だけ確認します： ［システム設定］→［プライバシーとセキュリティ］→［このまま開く］。Windows では、次をクリックします： ［詳細情報］→［実行］。

クイックスタート——API で

ターミナルや CI から操作したい場合は、アプリで行うすべての操作が REST 呼び出しとして利用できます。 アクセストークン はサインアップ時に作成され、アプリに表示されます。これを Authorization: Bearer ヘッダーに指定します。

1. アカウントを確認する

トークンが機能することを確認し、プランと残りのクォータを確認します。

curl https://app.redthreadsec.com/api/me \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

{ "tenant": "acme-3f9a2c", "plan": "starter", "plan_display": "Starter", "poc": true,
  "scans_used": 1, "scans_limit": 5, "apps_used": 1, "apps_limit": 1, "verified": true }

2. スキャンを開始する

指定するのは targetです。任意で source （リポジトリまたはパス）を追加すると、はるかに詳細なホワイトボックススキャンになります。また budget で支出上限を設定できます。

curl -X POST https://app.redthreadsec.com/api/scan \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"target":"https://staging.yourapp.com/chat","budget":10}'

{ "run_id": "20260731-abc123" }

3. 結果を読む

実行状況をポーリングし、 running が falseになったら、検出結果を読み取ります。

curl https://app.redthreadsec.com/api/runs/20260731-abc123 \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

一連の流れはこれだけです： me → scan → runs/<id>。 API リファレンス にすべてのフィールドが記載されています。

仕組み

Redthread はエージェント不要です。スキャン対象やクラウドを接続し、ワークスペースごとに必要なモジュールを有効化すれば、すべて当社のクラウドから実行されます。すべてのモジュールの根底にあるのは、1つの考え方—— グラフ。

1. マップ。 Redthread は、接続したもの——エージェント不要のクラウドロール、リポジトリ、稼働中のアプリ——から、環境全体を1つのグラフにまとめます。対象は、エージェント、アプリケーション、コード、クラウドアカウント、アイデンティティ、そしてそれらが到達できるデータです。
2. 評価。 有効化したモジュールがこのマップ上で動作します。自律エージェントが隔離されたサンドボックスで AI アプリのペネトレーションテストを行い、シャドーAIの発見がすべてのモデルサーフェスを棚卸しし、クラウド & インフラのポスチャと DSPM がアセットと機密データを分類し、依存関係の CVE 分析が継承しているものを確認します。
3. 実証。 検出結果とは、エンジンが実際に到達またはエクスプロイトしたものであり、正確な再現手順が付属します。実際の結果だけが検出結果になり、未実証の手がかりは別に保持されます。推測によるものは一切ありません。
4. ランク付け。 検出結果はグラフに戻されるため、レイヤーをまたぐリスク——たとえば、インターネットに公開されたアプリの認証情報が別のクラウドの分類済みデータに到達するケース——が、孤立した問題の一覧よりも上位に表示されます。
5. 対応。 各検出結果には、わかりやすい修正策と、必要に応じてドラフトのプルリクエストが付属します。CI ゲートは実証済みの攻撃経路を生み出すマージをブロックし、修正をトリガーに署名付き Webhook を送信したり、Jira / ServiceNow のチケットを起票したりできます。

コア製品では、お客様のシステムに何もインストールしません。モジュールはクラウドからワークスペースごとに有効化します（ アーキテクチャ図を参照）。より深く調べたい場合は、任意のエージェントを利用できます：ネットワーク内部をスキャンするための、アウトバウンド通信のみの軽量な コネクタ 、Kubernetes の eBPF ランタイムセンサー、そしてホストごとの エンドポイントエージェント ——いずれも 検知のみで、ブロックは一切行いません。AI アプリのスキャンは、スキャンごとに隔離された Docker サンドボックスで実行され、スキャン終了時に破棄されます。

ツール： フロンティア LLM で動作し、当社の脆弱性スキルパック（OWASP LLM Top 10 2025 + MITRE ATLAS）に導かれる自律 AI エージェント。 CVSS 3.1 によるスコアリング。依存関係の CVE は osv-scannerで検出。環境グラフはシンプルなノードリンク形式の JSON としてエクスポートされます。主力モジュールは AI アプリケーションのペネトレーションテスト です——このセクションの残りでは、すべてのモジュールとその背後にある API を解説します。

プラットフォームアーキテクチャ

このセクションはアプリ内でお客様のみご覧いただけます： サインイン して、いずれかのドキュメントリンクを開いてください。

エンドポイントセンサー：収集するデータとその用途

センサーは 1 台のノート PC、サーバー、またはクラウド VM 上で動作します。読み取りと報告のみを行い、何かをブロック、強制終了、変更することは一切ありません。起動時と 15 分ごとにレポートを送信し、レポートの合間には 20 秒ごとに実行中の AI ツールを確認するため、短時間の実行も漏れなく記録されます。インストール前にマシンが送信する内容を正確に確認するには、次のコマンドを実行してください。 redthread-agent -print：レポートを表示するだけで、何も送信しません。

レポートの内容

センサーが導入されたマシンはすべて、Assess において Redthread の検知でカバーされているものとして計上されます。Estate Scan の エンドポイントセンサーをインストール には、レポートを送信している各マシンが、その報告内容と報告日時とともに一覧表示されます。

送信しないデータ

ファイルの内容、キーストローク、スクリーンショット、ネットワークトラフィック、環境変数、パスワードやトークン、生のハードウェア ID、プロセスのコマンドライン。コマンドラインは AI ツールを識別するためにマシン上でのみ読み取られ、その後破棄されます。

自動更新。 センサーは自動で最新に保たれます。6 時間ごとに新しい公開ビルドを確認し、インストーラーと同じく公開された SHA-256 チェックサムで検証してから入れ替え、再起動します。チェックサムが一致しないビルドは決してインストールされません。2026 年 10 月 7 日より前にインストールしたセンサーは、インストールコマンドをもう一度実行する必要があります。それ以降は再実行は不要です。マシンで更新を無効にするには MAI_AUTO_UPDATE=0 を設定します。

評価 & 統合

このセクションはアプリ内でお客様のみご覧いただけます： サインイン して、いずれかのドキュメントリンクを開いてください。

Agentic Trust & Protection Platform

SPIFFE に基づく、エージェントのアイデンティティ + 継続的な信頼シグナル。

「エージェントの信頼と強制」ページ。 コンソール（ガバナンス → エージェントの信頼と強制）では、オーナーがボタン 1 つで Agent Trust をオン／オフし、名前とスコープ（エージェントが報告するツール名またはアクション名そのもの）を指定してエージェントを登録します。各エージェントのカードには、バッジの状態、シャドーか強制かのモード、ID とスコープ、ゲートウェイが最後にトラフィックを判定した時刻、そしてバーンインの進捗（シャドー判定 100 件中の件数、シャドー 60 分中の分数、レビュー待ちのブロック予定）が表示されます。オーナーはこれらをグループ単位でレビューし（ブロックすべき／正当だった）、バーンインが完了するとエージェントを強制に切り替えられます。ゲートウェイと強制モードはプレビューと表示されます。

1 コマンドのゲートウェイ（プレビュー）。 エージェントを登録すると、ID とキーが入力済みのコマンドが 1 つ表示されます。エージェントを実行するマシン（macOS または Linux、Python 3.10 以降）で実行すると、リファレンスゲートウェイを 127.0.0.1:8888 のバックグラウンドサービスとしてインストールし、エージェントの起動に使う行（プロキシのアドレスと、そのマシンでゲートウェイが生成した証明書）を表示します。シャドーではすべてのリクエストを判定・記録し、何もブロックしません。判定はエージェントのカードの「アクティビティ」と「バーンイン」に表示されます。各カードには付与の編集欄（ホスト、メソッド、パス）もあります。削除するには --uninstall を付けて実行します。

検出されたすべてのエージェントとアイデンティティに、永続的で検証可能なアイデンティティを付与し、その 信頼状態 — safe / unsafe / degraded / revoked ——をリアルタイムで配信するオプトインモジュールです。これにより、オーケストレーター、エージェントゲートウェイ、SIEM は、誰かがレポートを読むのを待つことなく、数秒で対応できます。既存のグラフとエクスプロイト検証パイプラインの上で動作し、デフォルトはオフで、純粋に追加的な機能です——有効化しないワークスペースには何の変化もありません。

このモジュールは、業界の2つのカテゴリが交わる位置にあります： 非人間／ワークロードアイデンティティ （SPIFFE/SPIRE がサービスアカウントやマシンに対して解決しているのと同じ課題を、AI エージェントに拡張したもの）と 継続的アクセス評価 （エンタープライズのアイデンティティ管理でリアルタイムの失効に使われる CAEP/RISC Shared Signals パターン）です。Agentic Trust & Protection Platform は、この両者を1つのメッシュとして提供する当社の名称です——すべてのエージェントが検証可能なアイデンティティを持ち、その信頼状態は必要とするあらゆるシステムにリアルタイムで配信されます。

• アイデンティティ——SPIFFE/SPIRE。 すべてのエージェント／アイデンティティ／AI ノードに spiffe_idが付与されます。コンソールから Terraform の1ステップで、CNCF の SPIRE エンジンをテナントごとにデプロイできます（対象はディスカバリーがすでに読み取っているのと同じクラスターで、署名鍵がお客様のクラウドの外に出ることはありません）。SPIRE は短期間有効で自動ローテーションされる SVID を発行し、それがグラフに反映されます。デプロイするまでは、Redthread が決定論的な SPIFFE ID を割り当てるため、このレイヤーは今日から機能します。ベンダーやモデルに依存しません：アイデンティティはワークロードに対して発行され、その中のモデルに対して発行されることはありません。
• グラフ上の信頼バッジ。 有効化すると、Redthread フロー ビューのすべてのノードに信頼バッジ（緑 safe／赤 unsafe／琥珀 degraded／灰 revoked）が表示されます。その情報源は、同じ trust_state フィールドです。
• 信頼状態は、推測ではなく実証に基づく。 ノードが unsafe に切り替わるのは、 実証済み のエクスプロイトがあった場合のみです（推測によるものでは切り替わりません）。 degraded は、潜在的だが未確認の検出結果、または期限切れの SVID を表します。 revoked は、オペレーターによる手動のオーバーライドです。
• 署名付き・TTL 付きのイベント。 すべての信頼状態の変化は、CAEP/RISC 標準に沿った形式で、Ed25519 署名付きの有効期限のあるイベントとして発行され、その原因となった検出結果へのリンクが含まれます。第三者はワークスペースの公開鍵を使って、イベントをオフラインで検証できます——Redthread へのリアルタイム呼び出しは不要です。
• 配信。 1つ以上の Webhook を登録します（任意で HMAC 共有シークレットを設定可能）。変化があるたびに署名付きイベントが配信されます。追記専用の台帳により、イベントを取りこぼしたサブスクライバーも追いつくことができます。
• 鍵と台帳。 各ワークスペースの署名鍵は別の署名サービスが保持し、Oracle Cloud Vault の鍵で封印されています。アプリは署名を依頼できますが、鍵を読み取ったりエクスポートしたりすることはできません。追記専用の台帳は PostgreSQL にあり、データベース自体が更新、削除、切り詰めを拒否します。
• Enforce——プレビュー。 オプトインのインラインゲートウェイで、 allow / deny / deny-and-pause を、構造化された許可（ホスト、メソッド、パス、ボディサイズ）と照合して、稼働中のリクエストに対して判定します。判定はリクエストが宛先に到達する 前に 行われ、事後に記録するだけではありません。新しい許可はすべて shadow から始まります——判定して記録し、すべてを転送する、これまでとまったく同じ動作です。そして、バーンインゲートの条件が満たされるまで、API 自体がアイデンティティを強制モードに切り替えることを拒否します。条件とは、その許可のもとで実際のトラフィックを十分な期間監視し、ブロックされるはずだったすべてのリクエストをオペレーターが確認・承認していることです。オーバーライドはありません。10月以降、ゲートウェイはコンテンツも検査します。対象は、送信リクエスト内のプロンプトインジェクションの指示とシークレット、およびレスポンス内の細工された MCP ツール一覧（ tools/list ）です。これはパターンマッチングであり、アイデンティティを enforce に切り替えるまでは監視のみで、言い換えによって回避される可能性があります。詳しくは API でルート全体を確認してください。

デフォルトは引き続きアイデンティティ + 信頼状態のみです——権限／VC のシステムではなく、（v1 では）組織間フェデレーションでもありません。Enforce は、それに値するアイデンティティについて、リクエスト経路に実際の判定ポイントを追加します。どのルールにも一致しない新種の攻撃に対する保証として謳うことは決してありません。

公開バッジ：画像はポインターにすぎず、主張は署名付きファイル

README のバッジはどれも誰かのサーバーから取得される画像であり、その画像はサーバーが決めた内容を何でも表示できます。そのため、ATPP の主張を画像に持たせることはありません。レベル1（MCP パブリッシャー）の主張は、 当社の日次スキャンジョブが Ed25519 で署名した、DSSE エンベロープ内の in-toto ステートメント （このジョブは Redthread 自身のインフラストラクチャ上で実行されます）であり、その subject はスキャンしたレジストリマニフェストそのものの sha256 です。ルール atf-5 以降、主張にはその掲載が何をインストールするかも記載されます：npm の integrity ハッシュ、PyPI ファイルの sha256 または各イメージタグの背後にあるコンテナダイジェスト、そして npm または PyPI がパッケージの Sigstore ビルドプロベナンスを保持している場合は、そこに記載されたリポジトリです。 trust.redthreadsec.com の背後にあるサーバーは公開鍵しか保持していないため、検証に通る主張を作り出すことはできず、署名の検証に失敗したバッジは灰色で表示されます。

• 固定バッジ（デフォルト）。 パブリッシャーは .atpp/badge.svg と .atpp/attestation.dsse.json をコミットします（どちらも /v/mcp/<namespace>/<server>からダウンロード）。README は当社から何も取得しません。バッジにはバージョンと日付が記載され、その sha256 は署名付きの主張の中に含まれています。
• ライブバッジ（任意）。 /badge/mcp/<namespace>/<server>.svg は再スキャンのたびに更新されます。GitHub では約10分遅れて反映されます（画像キャッシュのため）。単純な図形とテキストのみで、リンクやアニメーションは含みません。
• ご自身で検証できます。 python3 atpp.py verify <namespace>/<server> またはリポジトリのパスを指定して実行します（入手先： github.com/bl014h/atpp）。検証内容：固定鍵による署名、レジストリのライブハッシュ、コミット済みバッジ、有効期限。鍵： /.well-known/atpp-keys.json。全エンベロープの署名付きマニフェストは毎日 /v/log/latest.jsonに公開され、そのハッシュは同じ公開リポジトリにコミットされます。
• インストール済みのものを確認する。 python3 atpp.py check-config は、お使いのマシン上の Claude Desktop、Claude Code、Cursor、VS Code、Windsurf の MCP 設定を読み取り、各パッケージまたは URL の背後にあるレジストリ掲載を特定して、その署名付きスコア、固定すべき正確なバージョンまたはダイジェスト、ビルドした主体を表示します。 !! は、名前だけで信頼すべきでないサーバーを示します（掲載すり替え、バージョンの欠落、別のリポジトリからのビルド）。設定ファイルがアップロードされることはありません。
• ツール定義にフィンガープリントを付与。 ルール atf-6 以降、スキャンは MCP ハンドシェイクと tools/list （ツールは一切呼び出しません）を、認証情報なしで応答する各リモートサーバーに送り、ツール定義のフィンガープリントを主張に署名して含めます。 tools-stable は、バージョンが変わらないのに定義が変わった場合に不合格になります。これがラグプルの手口です（OWASP MCP03）。
• フックと部品表（プレビュー）。 atpp hook claude （Claude Code の PreToolUse フック）と atpp hook cursor は、MCP ツールの呼び出しを署名付きの主張と照合し、掲載のすり替え、バージョンの欠落、別のリポジトリのビルドプロベナンス、ツールのひそかな変更を拒否します。 atpp check-config --cyclonedx bom.json は、設定済みサーバーの CycloneDX 1.6 AIBOM を出力します。
• 起動のゲート（プレビュー）。 python3 atpp.py gate <namespace>/<server> は、許可なら 0、拒否なら 1 で終了します。実行できなかったチェックは拒否として扱われます。起動前、CI（ atpp GitHub Action を mode: check-config に設定すると、レビューが必要なサーバーを追加するプルリクエストが失敗します）、または ToolHive の前段（atf_receipts.py serve --gate）で使用できます。公開された掲載とアーティファクトのダイジェストを静的スキャンと照合するものであり、サーバーが実行を開始した後の動作を監視するものではありません。
• お客様のポリシーを、お客様のランタイムで適用。 組織の許可リストと固定されたイメージダイジェストは、お客様が所有するファイルに保存されます： atpp gate --policy org.json はそれ以外をすべて拒否し、 atpp profile --policy org.json はエントリを thv run --isolate-network用の ToolHive 権限プロファイル（許可する送信先ホストとファイルマウント）に変換します。署名付きの主張が権限を付与することはありません。
• キーレス連署。 毎日のマニフェストは、公開 atpp リポジトリ内の読み取り専用ワークフローによって、Sigstore のキーレス署名でも署名されます（GitHub の ID、短期間のみ有効な証明書、Rekor エントリ）。検証には sigstore verify identityを使用します。バンドルはそのリポジトリの log/ フォルダにあります。
• ロールバック耐性。 毎日のマニフェストは公開の Sigstore Rekor 透明性ログにもアンカーされ、検証ツールは主張が最新のマニフェストに含まれていることを確認します——そのため、サーバーが侵害されても、より古くスコアの良い主張を再利用することはできず、リポジトリが別のサーバーの .atpp/ ファイルを流用することもできません（主張は、それが置かれているリポジトリに属している必要があります）。
• 外部から監視。 1時間ごとの カナリア と毎日の レッドチーム が GitHub 上で本番環境に対して実行され、結果は公開されています。
• 設計の全容（開発者とセキュリティリーダー向け）： trust.redthreadsec.com/technical。
• 問題の報告： [email protected] · 脆弱性開示ポリシー。

他製品との比較

チームがすでに知っているプラットフォームと比べて、Redthread がアーキテクチャ上どこに位置するかを示します。 エージェント の軸では、Wiz と同様にエージェント不要を第一としています。違いは、当社がリスクをエクスプロイトによって 実証 する点、そして Redthread グラフ がクラウドインフラだけでなく、AI エージェントとアプリケーションをファーストクラスのノードとして扱う点です。これはアーキテクチャの比較です——Wiz、Palo Alto、CrowdStrike は大規模なマルチプロダクトスイートであり、ここで示すのは機能の同等性ではなく 形の違いです。

Wiz に最も近い。 デフォルトでエージェント不要であり、中核にセキュリティグラフを持ち、生の検出結果をランク付けされた攻撃経路と危険な組み合わせに変換します。違いは次の点です。Wiz は 推測 によってクラウドの状態からリスクを導きますが、当社はリスクを 実証 します——自律的なペネトレーションテストが実際にエクスプロイトを実行し、再現可能な PoC を添付します。さらに当社のグラフは、クラウドリソースだけでなく、LLM アプリとエージェントをファーストクラスのノードとして扱います（OWASP LLM Top 10、MITRE ATLAS）。つまり形としては、「攻撃型の AI アプリケーションペンテスターを上に載せた、エージェント不要の CNAPP グラフ」です。

Palo Alto との違い。 Prisma Cloud + Cortex はプラットフォーム化——多数の製品とエージェント（エージェント不要 + Defender + エンドポイント、ネットワーク、クラウド、アイデンティティにまたがる AI SOC）——の路線です。当社は、ワークスペースごとにモジュールを有効化する、1つのエージェント不要プラットフォームです。Palo Alto はランタイムで防御・対応しますが、当社は設計上あくまでテストと評価のツールであり、任意のランタイムセンサーも検知のみを行います。

CrowdStrike との違い。 Falcon の前提は、すべてのエンドポイントに1つのエージェントを置いてランタイム EDR を行うことです。当社はコア製品で何もインストールせず、ランタイムの防御も行いません。重なるのは「クラウドで有効化するモジュール」と相関グラフを動かす点だけです——ただし Falcon がグラフ化するのはエンドポイントイベントであり、Redthread がグラフ化するのはお客様の環境とその実証済みの攻撃経路です。

スキャン対象の選び方

最もよくある質問に、最初にお答えします：指定していただくのは target、そして任意で ソースです。この2つは別物です。

ステージングと本番環境——常にステージングを対象に

• 本番環境 は、顧客が実際のデータとともに使う本物のアプリです。
• ステージング は、テスト環境で稼働する別のコピーです——同じアプリですが、実際の顧客やデータは含まれません。

スキャナーは 本物の攻撃者として動作します：入力を送信し、レコードを作成し、アプリが公開しているアクションを実行し、アプリに対するモデルコストを押し上げることがあります。ステージングでは無害ですが、本番環境では不要なデータや、実際のユーザーへの実害につながる可能性があります。本番環境をスキャンするのは、それを理解し受け入れる場合に限ってください（テスト用アカウントと利用の少ない時間帯が役立ちます）。

自分の URL がわからない場合は？ ステージング URL の例…

アプリが稼働している Web アドレスのことです。よくある形式：

• staging.yourapp.com または app-staging.yourapp.com
• プレビュー URL（Vercel や Netlify で、変更ごとに発行されるもの）
• *-staging.onrender.com または *.herokuapp.com アプリ
• ローカルアドレス（localhost:3000）をトンネル（ngrok、cloudflared）でインターネットに公開したもの

最も簡単な方法：アプリに探してもらう

アプリで、すでに知っているリンク——メインの Web サイトまたはアプリのアドレス——を1つ 「何をスキャンすべきか分かりませんか？」 に貼り付けて、次を押します： スキャン対象を探す。当社がページを調べ、AI 機能と API エンドポイントを見つけ、公開記録からほかの環境（例： staging. と app.）を確認します。推奨されるスキャン対象の短いリストが返されるので、1つクリックすればスキャンできます。ホスティングへのログインも、探し回る必要もありません。

自分で探す——開発者は不要

手作業で行いたい場合や、念のため確認したい場合でも、技術者は必要ありません。確実な方法は2つあります：

1. 自社のアプリを開いてリンクをコピーする。 顧客と同じように製品を使います——AI 機能（チャット、アシスタント）のあるページに移動し、ブラウザのアドレスバーからアドレスをそのままコピーします。そのアドレス が スキャン対象です。
2. お金の流れからホスティングアカウントをたどる。 アプリはどこかで稼働しており、ホスティング料金を支払っているカードの持ち主は、すべての URL を確認できます。明細書で Vercel、Netlify、Render、Heroku、AWS、DigitalOcean、Google Cloudを探し、そのアカウントにログインすると、ダッシュボードにアプリのアドレス——本番環境と、ステージング／プレビュー環境——が一覧表示されます。

別の方法： ドメインレジストラ／DNS （GoDaddy、Namecheap、Cloudflare——ドメインを購入した場所）では、次のようなサブドメインを確認できます： staging., app., api.。または、アカウント内から ホスティングプロバイダーのサポート に問い合わせます。

ステージング URL がない場合は、どうすれば入手できますか？

• ほとんどのホスティングサービスでは、アカウントから ワンクリックでステージング用のコピー を作成できます——Vercel、Netlify、Render はいずれも無料のプレビュー／ステージング環境を提供しており、コードは不要です。
• アプリが GitHub にある場合、プルリクエストごとにプレビュー URL が自動生成されることがよくあります。
• 本番環境しかない場合でもスキャンは可能です——ただし実際の攻撃として扱ってください（利用の少ない時間帯、テスト用アカウント、多少の不要なデータが生じる前提で）。詳しくは上記の ステージングと本番環境 を参照してください。
• 技術者がまったくいない場合は？ フリーランサーなら半日でステージングを用意できます——その URL をここに貼り付けてください。

URL が用意できたら、 最初のスキャンを実行するの手順に従ってください。より詳細なホワイトボックススキャンを行うには、コード（アップロード またはリポジトリ）を追加します。

ブラックボックスとホワイトボックス

スキャナーに与える情報の量が、見つかるものの量を決めます。

• ブラックボックス ——稼働中の URL または API だけを渡します。スキャナーは匿名の攻撃者のように外部から攻撃します。高速でセットアップ不要ですが、見つけられるのは正面玄関から到達できるものだけです。
• ホワイトボックス ——アプリケーションの ソースも渡します。スキャナーは攻撃しながらコードを読むため、エンドポイントの背後にあるツール、プロンプト、データ経路を理解できます。検出結果の数と深さの両方が大きく向上します。

ソースを渡す方法は2つあります——git の知識は不要です：

• プロジェクトの .zip をアップロードします。アプリではスキャンボックスにドロップし、API では アップロードして 、返された upload_idを渡します。コードはそのスキャンの間だけ保持され、終了時に削除されます——学習に使われることは決してありません。
• git リポジトリを指定する ——GitHub、GitLab、Bitbucket、Azure DevOps に対応しています。リポジトリの URL を source フィールドに貼り付けるか、アプリで GitHub を接続 を一度行い、ドロップダウンからリポジトリ（プライベートを含む）を選択します。その他のホスティングでは URL を貼り付けます。そこでのプライベートリポジトリは .zip アップロードを使用してください。

完全スキャン——両方のパスをワンクリックで

スキャンフォームのチェックボックス 完全スキャン をオンにすると、1つの対象に対して 2つの パスを自動で実行します：まず ブラックボックス パスで稼働中のエンドポイントを検査し、次に ホワイトボックス パスでソースを読み、既知のサーフェスを再テストします。結果は1つに統合された検出結果リストとして得られ、各カードには検出したパスのタグが付きます。ソース（リポジトリまたは .zip）が必要で、単一スキャンの約2倍の予算を使用します。

ホワイトボックスパスはブラックボックスの検出結果を引き継ぎ、それぞれを再テストします：まだエクスプロイト可能な問題は ↻ 再確認済み の回帰として表示され（2回ではなく1回としてカウント）、ソースからしか判明しないものは新規として追加されます。 無料 プランでも完全スキャンを実行できます——上限は合計 $20 （1パスあたり $10）です。

テスト内容

OWASP LLM Top 10 のすべてのカテゴリを、MITRE ATLAS にマッピングしてテストします：

• プロンプトインジェクション
• 機密情報の漏えい
• サプライチェーン
• データ & モデルポイズニング
• 不適切な出力処理
• 過剰な権限（ツール & エージェントの悪用）
• システムプロンプトの漏えい
• ベクトル & 埋め込みの脆弱性（RAG）
• 誤情報
• 無制限の消費（コストの暴走）

MITRE ATLAS へのマッピングを含む完全なマトリクスは、次のページで公開しています： トラストセンター。

ツール： カテゴリ別の当社の脆弱性スキルパック。対応するのは OWASP LLM Top 10 2025 と MITRE ATLAS v5.6.0 です（テクニック ID は記憶に頼らず、原典と照合して検証済み）。 サプライチェーン は、専用の セクションがあります。

検出結果 & 概念実証（PoC）

検出結果とは、スキャナーが 実証した脆弱性であり、推測ではありません。各検出結果には次の情報が含まれます：

検出結果の読み方——ラベルの解説

すべての検出結果には標準的なセキュリティラベルが付けられており、リスクを判断して最初に何を修正すべきかを決められます。各ラベルの意味、読み方、重要な理由を説明します。

OWASP LLM Top 10——各リスクの意味

支出上限 & 安全性

自律エージェントは言語モデルを呼び出すため、費用が発生します。2つの独立した上限により、スキャンが想定外の費用を生むことはありません：

• スキャンごとの予算上限。 すべてのスキャンには budget を指定します（米ドル、デフォルト 10）。エンジンはその上限に達した時点で停止します。
• トークンウォッチドッグ。 独立したバックストップが、トークン数の上限を超えたスキャンを強制終了します。料金レイヤーから見えないセルフホストのモデルでも同様です。そのため、暴走したループがアカウントの残高を使い果たすことはありません。

すべてのスキャンはそれぞれ隔離されたサンドボックスで実行され、同時実行数はプランごとに上限があるため、誤って100件のスキャンを一度に起動することはありません。

認可 & ドメイン検証

スキャンは 実際の攻撃であるため、スキャンできるのは自社が所有する、またはテストの権限を持つアプリだけです。これを単なる約束で終わらせないよう、新しい公開ドメインを初めてスキャンする際には、 そのドメインの所有権を証明 していただきます——ドメインごとに1回だけです。これにより、競合他社を対象に指定されることを防ぎます。

次のいずれかの方法で検証します（アクセスできる方を選んでください——どちらか1つで十分です）：

• メタタグ（最も簡単）。 ホームページの <head>に1行追加します。ほとんどのサイトビルダー——Wix、Squarespace、Webflow、Shopify——には、まさにこのための「ヘッダーコード」や「サイト認証」の入力欄があります：

  <meta name="millenniums-verification" content="YOUR-TOKEN">

• DNS TXT レコード。 ドメインレジストラで TXT レコードを追加します：

  millenniums-verification=YOUR-TOKEN

ルートドメイン を検証すると、そのすべてのサブドメインが対象になります—— acme.com を一度検証すれば、 staging.acme.com, api.acme.comなどをスキャンできます。また、最初のスキャンを実行する前に、短い 認可の証明 （アプリを所有している、またはテストの権限があること）を確認していただきます。

プロンプトが表示されたらアプリで検証するか、API で次を使用します： POST /api/domains/verify。発見機能（公開ページの読み取り）には検証は不要です——検証が必要なのは スキャン だけです。

お客様のデータ

コードとスキャン結果はお客様のものです。各スキャンは使い捨てのサンドボックスで実行され、スキャン終了時に破棄されます。そのため、当社が保持するコードは最小限であり、スキャンに必要な期間だけです。 お客様のコードや結果を、モデルの学習に使用することは決してありません。 サブプロセッサーを含む詳細は、次をご覧ください： トラストセンター と プライバシーポリシー。

トレーサビリティレポート

すべてのスキャンは 管理の連鎖（Chain of Custody）レポート を生成します。これにより、データに何が起きたかを正確に——自分自身、顧客、監査人に対して——証明できます。マーケティング上の主張ではありません。各行は、スキャンのライフサイクルで記録されたイベントから導出されています。

レポートの内容：

• タイムスタンプ付きのタイムライン： スキャン作成 → ソース受領 → 隔離サンドボックス起動 → スキャン完了 → サンドボックス破棄 →（アップロードの場合）アップロードされたソースの削除。
• ソースの来歴： スキャンがブラックボックス（稼働中の対象のみ）だったか、アップロードまたは git リポジトリからのホワイトボックスだったか。git の URL はホスト名のみ記録され、パスや認証情報は記録されません。
• 証明事項： 隔離サンドボックス、サンドボックスの破棄（コンテナランタイムと照合して検証）、アップロードされたソースの削除、支出上限の適用、モデル学習への不使用。
• 使用量： その実行のトークン数と LLM 呼び出し数。

アプリでは、任意の実行の データ証跡——管理の連鎖（Chain of Custody） から取得できます（JSON をワンクリックでダウンロード可能）。API では次を使用します： GET /api/runs/{run_id}/trace。

継続スキャン & ドリフト

概要： 一時点のスキャンを、継続的なカバレッジに変えます。アプリを アセットとして登録し、スケジュールを設定すると、Redthread が代わりに再スキャンし、変更があるたびに再チェックします。

仕組み： アセットごとに設定する2つのコントロールです。設定場所は 継続 ビュー（または API):

• スケジュール ——毎日、毎週、毎月の頻度。再スキャンは手動スキャンと同じ経路で実行されるため、クォータ、同時実行数、支出上限はすべて引き続き適用されます。
• ドリフト検知 —— 変更を監視 をオンにすると、スケジュール実行の合間にアプリのフィンガープリントを取り直します（OpenAPI/Swagger 仕様を優先）。重要な変更があれば、予定外のスキャンが開始されます。フィンガープリントは CSRF トークン、nonce、タイムスタンプ、キャッシュバスターを無視するため、動的なページで誤ってトリガーされることはありません。

重要な理由： アプリはリリースのたびに変わり、年1回のペネトレーションテストでは、火曜日のデプロイで生じた穴を見つけられません。継続スキャンは回帰が入り込んだ時点で捕捉します。ドリフト検知により、実際に何かが変わったときだけスキャンを消費します——カレンダーのリマインダーではなく、手間のかからない監視です。

ツール： アセットごとのスケジューラーで動く同じスキャンエンジン。OpenAPI/Swagger 仕様（または正規化したサーフェスのクロール）からアプリのフィンガープリントを取得し、動的トークンによるノイズを除外したうえで実行間の差分を比較します。

ダッシュボード & トレンド

ホームのダッシュボードは、活動ログではなくリスクを読むための画面です。 最上部には4つのタイルからなるリスクバンドが表示されます—— 実証済みの攻撃経路 （いくつのリスクのうち、いくつの未解決の検出結果から）、 深刻度別の未解決の検出結果 （前回のスキャンとの新規／解決の差分付き）、 カバレッジ （登録済みアセット、クラウド接続、エンドポイントホスト、最終スキャンからの経過時間）、そして Agentic Trust & Protection Platform の状態（safe / unsafe / degraded のエージェント、またはオフ）です。その下には、Redthread による 上位3つの攻撃経路 がホップの連鎖として描かれます—— Internet → web-01 → data-ingest-role → customer-records ——それぞれに Proven · PoC または 潜在のマークが付き、深刻度順、実証済みを潜在より優先して並びます。最近のスキャンはその下に表示されます。

各タイルとパネルには、何を数えているかを示す 1 行の説明があります。「カバレッジ」タイルは 4 つのクラウド（AWS、Azure、Google Cloud、Oracle Cloud）のうち接続済みの数を数え、その名前を表示します。

すべてのタイルは保存済みクエリです：クリックすると、その数値を生成したビューがフィルター済みの状態で開きます——深刻度バーはその深刻度の検出結果を、経路はその元となったランク付け済みリスクを、カバレッジはスキャン対象を、信頼タイルは評価を開きます。未解決の検出結果の件数は、登録済みの各アセットの最新スキャンから取得されます（再実行で二重にカウントされることはありません）。登録済みアセットがないワークスペースでは、代わりに最新のスキャンを読み取ります。数値の取得元： /api/cloud/risks, /api/overview, /api/cloud/status, /api/endpoint と /api/trust-signal/status。

経路の下には、さらに3つのパネルがあります。 前回のスキャンからの変更 には、登録済みの各アセットが、前回のスキャンとの新規／解決の件数と次回の予定実行とともに一覧表示されます——新たに検出結果が出たアセットが先頭に並び、行をクリックするとそのアセットの最新スキャンが開きます。 次のアクション は、すでにある状態から導出されます：マージ可能な自動修正のプルリクエスト、確認待ちのシャドーAI候補、ローテーションすべき漏えいした認証情報（ランク付け済みリスクから）、そして最初に修正すべき実証済みの経路。 未解決の検出結果 · 8週間 は、登録済みアセット全体を合計したスパークラインです（各アセットの最新の未解決件数を週ごとに繰り越し、取得元は /api/assets/<id>/trend）。前週比の ↑ / ↓ 矢印が付き、深刻度タイルにも同じ矢印が表示されます。登録済みアセットの2回目のスキャン後に表示されます。

エグゼクティブビュー。 ダッシュボード上部のアナリスト／エグゼクティブ切り替えで、同じ数値を一段高い視点で表示します：ファネル行付きの実証済み経路の数値、現状から作成した平易な要約（Redthread がマッピングしているもの、実証されたもの、深刻度別の未解決の検出結果、前回のスキャンからの変化、エージェントの信頼状態、次のアクション）、続いてカバレッジ、信頼、深刻度、8週間のトレンド、上位の攻撃経路です。スキャンの仕組みは表示されません。デフォルトはエグゼクティブビューで、アナリストビューにはワンクリックで切り替えられ、選択はブラウザに記憶されます。

保存済みビュー。 スキャンの検出結果画面では、深刻度／PoC／エクスプロイト済みのチップでリストを絞り込めます。 ＋ ビューを保存 で現在の深刻度フィルターと非表示の切り替え状態に名前を付けて保存します（ワークスペースごと、ブラウザ内に保存）。保存済みビューは、フィルターの横に ★ チップとして表示されます。

コンソールのナビゲーションは、スキャン種別ではなく、行う作業ごとにグループ化されています： 概要 （ダッシュボード）· 接続 （スキャン種別。登録済みのスキャン対象は［設定］→［スキャン対象］で管理）· 探索 （Redthread Flow、評価と統合、チャット、クラウドの問題。ナレッジはチャットページの「ナレッジ」ボタンから開きます） · 対応 （検出結果、PR レビュー）· ガバナンス （評価 & 統合、設定）。

継続 ビューは、登録済みのすべてのアセットを1か所に集約します。これにより、セキュリティ責任者——あるいは取締役会——は環境全体をひと目で把握し、正しい方向に進んでいることを示せます。データはすべて、スケジュールや CI がすでに実行しているスキャンから供給されるため、追加で計測を組み込む必要はありません。

アセットごとの集計 — GET /api/overview。各アセットには、最新のスキャン状況、深刻度別の検出結果、前回のスキャンに対する 新規／解決の差分 、スケジュールと次回の実行が表示されます。アセットの現状だけでなく、前回からの変化もわかります。

リスクトレンド — GET /api/assets/<id>/trend。各アセットは検出結果の時系列データを持ちます——スキャンごとに古い順 → 新しい順で、その時点の未解決件数と新規・解決の件数を記録します——そのため、単一のスナップショットではなく、数週間にわたってリスクが 減少 していることを示せます。これがダッシュボードのスパークラインの元データです。

エクスポート — GET /api/overview.csv。ワンクリックで組織全体の集計を CSV としてエクスポートでき、スプレッドシート、QBR の資料、独自の BI に利用できます。

シャドーAIの発見（AI インベントリ）

概要： 組織で使われているにもかかわらずセキュリティ部門が把握していない AI——「シャドーAI」——を見つけます。LLM API をひそかに呼び出しているリポジトリ、クラウドアカウントで有効化されたマネージド AI サービス、自社ドメインに公開されたセルフホストのモデルサーバーやチャットボット UI などです。これは 発見とインベントリ の機能です：わかるのは AI がどこにあるかであり、脆弱かどうかではありません。

仕組み： 調べたいサーフェスを接続すると、各実行が対象とした範囲を正確に報告します。すべての結果は お客様が確認する候補 です——自動で何かを登録することはありません。確認された候補は、重複を除いた1つの AI インベントリ にカバレッジバナー付きで統合されます。既知のものや対象外のものは却下してください。

重要な理由： 存在を知らない AI は、保護も統制もできません。シャドーAIは、データ漏えい、コストの暴走、コンプライアンスのギャップが潜む場所です——インベントリは最初のコントロールです。ここで確認したものが、テストと監視の対象になります。詳しくは次を参照してください： 発見 & インベントリ。

ツール： GitHub の組織／リポジトリ API + LLM SDK の使用検出（リポジトリ）。エージェント不要のクラウド列挙（ boto3 を使用）——Bedrock、SageMaker、Lex、Comprehend（クラウド）。モデルサーバーと OpenAI 互換エンドポイントに対する HTTP/TLS サーフェスの検査（外部）。すべてエージェント不要です。

AI サプライチェーン

概要： アプリが 基盤としている AI コンポーネントに由来するリスク——サードパーティの基盤モデル、ファインチューニング済みまたは事前学習済みの重み、学習用および RAG 用のデータセット、埋め込み、プラグイン／ツール、そしてスタック内の ML/LLM ライブラリとモデルレジストリ。汚染されたモデル、バックドアが仕込まれたデータセット、ハブ上のタイポスクワッティングされたモデル、脆弱な ML 依存関係は、コードを1行も書く前にアプリを侵害し得ます。該当する OWASP の項目： LLM03:2025 Supply Chain。

仕組み： スキャン中、エージェントは対象範囲の AI コンポーネントを検査します——モデルとデータセットの出所とその信頼性、プラグイン／ツールの接続方法と信頼の度合い、ML/LLM スタックの依存関係ツリー。依存関係の CVE は実際のエクスプロイト可能性（KEV / EPSS）と到達可能性でトリアージされるため、ノイズの山ではなく本当に重要なものだけが表示されます。

重要な理由： AI アプリの信頼性は、それが継承するモデル、データ、ライブラリの信頼性で決まります——しかもそれらはコードベースの外から来て、アプリレベルのコントロールを迂回します。OWASP LLM Top 10 に含まれているのは、まさにそのためです。

ツール： osv-scanner で依存関係の CVE インベントリを作成し、続いて EPSS / CISA-KEV / 到達可能性のトリアージファネルを適用します（ 依存関係の CVEを参照）。当社の LLM スキルパックは、検出結果を OWASP の LLM03 と MITRE ATLAS の AI Supply Chain Compromise（AML.T0010）にマッピングします。

インフラ & クラウド

概要： クラウドセキュリティポスチャ管理（CSPM）。アプリの外側で、攻撃者が狙う露出をクラウド内でチェックします——公開バケット、過度に広い IAM、全世界に開放されたポート、暗号化されていないデータや公開データ、監査証跡の死角。エージェント不要で、CVSS によるスコア付き。

仕組み： エージェント不要のロールを接続すると、当社がそのロールを引き受け、読み取り専用で列挙し、決定論的なチェックを実行します——キーは不要、書き込みアクセスもありません。検出結果が発生するのは、実際にチェックに失敗したリソースに対してだけです。

AWS は2クリックで、コマンドライン不要。 まず AWS を開いてロールを作成を押すと、AWS CloudFormation コンソールがすべて入力済みの状態で開きます——当社のスキャナー、 お客様の 一意の外部 ID、そして読み取り専用ロール（ReadOnlyAccess + SecurityAudit）。ロール名は millenniums-cloud-scanです。IAM の確認ボックスにチェックを入れ、次をクリックします： Create stack（スタックの作成）。1分ほど待ってから、12桁の AWS アカウント番号をアプリに入力します。ロール ARN は当社が組み立て、何かを保存する前に実際の読み取り専用呼び出しを1回行って検証します。スタックがまだ作成中の場合は、エラーではなく、待ってから再試行するよう案内されます。取り消すには、 MillenniumsCloudScan スタックを削除します。以前に millenniums-cloud-scan をすでに作成している場合（例：Terraform で作成）は、スタックがロールの既存を報告します——その場合はスキップして、アカウント番号だけを入力してください。既存のロールは、当社のスキャナーをお客様の外部 ID で信頼している限り機能します。テンプレートは公開されており短いので、実行前にお読みください： millenniums-cloud-scan-v1.yaml。Terraform や独自のロールを使いたい場合は、インフラストラクチャページで引き続き Terraform を生成でき、ロール ARN も入力できます。

AWS の管理者ではありませんか？ 環境スキャンページの 送信用リンクを取得 で、AWS を管理している担当者に同じ2つの手順を開くプライベートリンクを作成できます——相手側にアカウントは不要です。このリンクでできることは1つだけです：ワークスペースに AWS を接続すること。表示されるのは会社名のみで、メールアドレスや検出結果は表示されません。7日後に失効し、新しいリンクを作成すると以前のリンクは無効になります。担当者が完了すると、環境スキャンのレーンが緑色に変わります。

Azure、Google Cloud、Oracle Cloud もワンクリックで接続でき、コピーや貼り付けは一切不要です。 Azure： Microsoft でサインインし、Redthread を承認します。Azure で入力済みのデプロイが開き、選択したサブスクリプションに対して当社のスキャナーに Reader + Security Reader を付与します。各付与にはワークスペース固有のマーカーが付いており、当社はお客様のマーカーが付いた付与を持つサブスクリプションにのみ接続します。 Google Cloud： Google でサインインし、所有しているプロジェクトを選択すると、当社がお客様のサインインを使ってそのプロジェクトで当社のスキャナーに Viewer + Security Reviewer を追加します。Google のトークンはその1回の変更にのみ使用され、その後破棄されます。 Oracle Cloud（OCI）： Oracle で入力済みの Resource Manager スタックが開き、 RedthreadCloudScan グループと API キー専用ユーザー（アイデンティティ・ドメインを使用する Oracle アカウントで必須となるメールアドレス付き）、読み取り専用ポリシー（inspect all-resources、および read をバケット、ネットワーク、ユーザー設定に対して付与——ファイルの内容、データベースウォレット、VM コンソールの出力は含みません）を作成し、ワークスペースの 公開 鍵をアップロードしてから、そのユーザーを当社に通知します。いずれの場合も、お客様が当社にシークレットを渡すことはなく、取り消しは自社のコンソールでワンクリック、そしてすべての接続は保存 前に 、実際の読み取り呼び出しで検証されます。コマンドラインを使いたい場合は、各クラウドで引き続き手動のコマンド（Azure のアプリ登録、GCP のサービスアカウントキー、OCI Cloud Shell）を利用できます。そこで貼り付けたシークレットは書き込み専用で、どの画面や API からも返されることはありません。Kubernetes と、任意の Prowler インベントリは、引き続き直接取り込めます。詳しくは次を参照してください： API。

重要な理由： アプリが完璧でも、それが稼働するインフラを通じて侵害されることがあります——しかもポスチャはチームが出荷するたびにドリフトします。エージェント不要なので、四半期に1回ではなく、継続的に安全に実行できます。

ツール： エージェント不要のクラウド列挙（ boto3 を使用、AWS）を、お客様が付与したロール（ReadOnlyAccess + SecurityAudit）に対して実行し、続いて当社の決定論的な CVSS スコア付きポスチャチェックを行います。代わりに任意の Prowler形式のインベントリを取り込むこともでき、GCP / Azure / Kubernetes にも同じチェックが実行されます。

Redthread——リスクグラフ & 攻撃経路

Redthread は当社のグラフエンジンです。攻撃経路レポート、プルリクエストゲート、クエリビルダー、ランタイムセンサーの土台となるレイヤーであり、4つすべてが同じグラフを読み書きするため、互いに矛盾することはありません。

概要： 複数のクラウドにまたがるすべてのアセット、アイデンティティ、ネットワーク経路、検出結果を、 1つの 正規化されたグラフにまとめ、そのグラフを通る 攻撃経路 のランク付けされた一覧を提供します。検出結果が示すのは 「このバケットは公開されている」。 リスクが示すのは 「インターネットからこのワークロードに到達でき、そのワークロードは認証情報を保持しており、その認証情報で顧客データを読み取れる」。 経路こそが製品です。

仕組み： プロバイダー固有の用語はコレクターの段階で吸収されます。AWS のロール、Entra ID のサービスプリンシパル、GCP のサービスアカウントはすべて同じ種類のノードになるため、経路はクラウドの境界をまたぐことができます。結果に対して8つのルールが実行されます——公開されたワークロード → 機密データ、認証情報の連鎖、クラウド間のピボット、権限昇格、シャドーデータ、公開された AI アセット、実証済みのレイヤー横断の連鎖。各ルールが返すのは path（経路）であり、アラートではありません。

重要な理由： ポスチャツールは何百ものクリティカルを出しても、優先順位は示しません。CVSS だけでランク付けしても、攻撃者が実際にそこに到達できるかどうかは何もわかりません。優先すべきは到達可能性であり、到達可能性はグラフの中にしか存在しません。

ツール： Redthread はエンジンにすぎません。 ファイル は独自形式ではありません。グラフは graphifyのノードリンク形式で出力されるため、ご自身でたどることができます—— graphify path "internet" "customer-data" ——または、リスクビューからダウンロードすることもできます。運用すべきグラフデータベースはなく、ロックインもありません：解約しても、グラフはお客様とともに持ち出せます。

アーキテクチャと検証

このセクションはアプリ内でお客様のみご覧いただけます： サインイン して、いずれかのドキュメントリンクを開いてください。

Redthread フロー——グラフの読み方

Redthread フロー は、グラフに質問すると、答えを一覧ではなく図として描くコンソールのパネルです。左側のナビゲーションで、ダッシュボードのすぐ下にあります。

環境マップ。 Redthread Flow を開くと、環境全体がネットワークとして表示されます。各アセットは所在によって色分けされた点で（AWS はオレンジ、Oracle Cloud はティール、Azure は青、Google Cloud は緑、センサーを入れたマシンは紫、外部 ID はピンク、インターネットは黒）、大きさは種類で決まるため、マシン、ワークロード、AI エージェントが目立ちます。同じクラウドのアセットは薄く色付けされた領域にまとまり、アセットが 3 つ以上あるクラウドには中央にラベル付きのマーカーが付きます。通常のリンクは細い青の線で、クラウドをまたぐリンクは赤、攻撃パスは深刻度の色の太い線で描かれます。ワイルドカード権限（すべてのストアですべてを許可されたロール）は、ストアごとの線ではなく、そのクラウドの「すべてのデータストア」ハブへの 1 本の線として描かれます。名前は短く（例: aws-ecs）、互いに重ならない小さな白いラベルに表示されます。インターネット、ハブ、深刻度がクリティカルまたは高の攻撃パス上のアセットは常に名前が表示され、その他はズームインすると表示されます。クリティカルまたは高の問題があるアセットには赤いリングが付きます。マップは Sigma.js で描画されるため、数千のリンクがある環境でも滑らかに動き、アセットにカーソルを合わせると、それに関係しないものはすべてグレーアウトします。

リスクを強調。 マップは リスクを強調 がオンの状態で開きます。問題のないものはすべて薄いグレーになり、目立つのはクリティカルまたは高の問題があるすべてのアセット（赤いラベルで名前を表示）と、クリティカルまたは高のすべての攻撃パスです。右側のパネルにはそれらの攻撃パスが一覧表示されます。1 つをクリックするとそのパスだけが表示されてズームし、もう一度クリックすると元に戻ります。リスクを強調をオフにすると、環境全体がクラウドごとの色で表示されます。

見方： スクロールまたは + と − でズーム、背景をドラッグして移動、点をドラッグして配置し、「全体表示」で表示を戻します。色付きの輪と数字は問題を示し（輪は最も高い重大度）、小さな緑の点はセンサーが報告中であることを示します。点をクリックすると詳細・問題・つながりのカードが開き、隣接する資産は強調され、それ以外は薄く表示されます。アイデンティティを非表示にしたり、クラウド間のつながりだけを表示したりできます。

グラフに質問 は2つ目のタブで、下で説明する質問と回答のビューです。 攻撃経路 は3つ目のタブで、インターネットから守るべきものへ至る経路を順位付けして表示します。「クラウドの問題」は左メニューの「チャット」の下に専用ページがあり、クラウド全体の設定ミスをクラウド別に絞り込んで一覧表示します。

使い方

パネルを開くと、すでにグラフが描かれています。保存済みの質問を順に実行し、経路を返した最初の質問で停止して、どれを選んだかをハイライトします——そのため、空のキャンバスではなく実際の答えから始められます。独自の質問をする方法は3つあります：

• 自然言語で。 質問を入力します—— 「インターネット上に、別のクラウドの顧客データに到達できるキーを持っているものはあるか？」 ——そして［質問］を押します。モデルが質問を構造化されたグラフクエリに変換します。 実行したクエリは常に表示されます ——「実行したクエリ」の下に表示されるので、展開して意図どおりに理解されたかを確認してください。質問がグラフで表現できる範囲外の場合は、その旨と不足しているものを示します。たまたま検証に通る最も近いクエリを実行することはありません。誰も尋ねていない質問への答えは、答えとまったく同じに見えてしまうからです。
• 保存済みの質問。 入力欄の下のボタンは、よく使う質問をあらかじめ用意したものです：漏えいしたキーを持つ公開 VM が別のクラウドの PII に到達するもの、データストアに到達する認証情報を持つワークロード、別のアイデンティティになれるアイデンティティ、インターネットから到達できる機密データストアなど。クリックすると実行されます。
• 手動で作成。 次を展開すると 手動で作成 、ドロップダウンで指定できます：検索対象の ［アセット種別］ は ［クラウド］ にあり、 ［露出］の状態で、 ［関係］によってつながる先は ［アセット種別］ で、保持するデータは ［データ分類］。クエリ言語を覚える必要はありません。

質問はプランごとに1時間あたりのレート制限があります——Free は10回、Starter は40回、Growth は120回、Enterprise は400回——自然言語での質問ごとにモデルの呼び出しが発生するためです。保存済みの質問と手動で作成したクエリはグラフに対して直接実行され、制限はありません。

図の読み方

図は左から右へのレイヤー型のフローです： 矢印の向きは攻撃の向きです。左端の列は攻撃者の出発点——通常はインターネット——で、右端は攻撃者が到達するものです。

連鎖を断つ

グラフの下には、ランク付けされた遮断リストがあります。結果セット全体のすべてのホップが、それを断った場合に消えるルートの数でスコア化され、各行にアクションが示されます（認証情報のローテーションと削除, 権限の絞り込み, 露出の遮断）、それが有効な理由、そして証拠が示されます。左の数値は断たれるルートの数です。実際の AWS アカウントでは、上位の遮断ポイント——1つのロールの認証情報を1つローテーションすること——によって 1,382 経路のうち 86 経路が遮断されました。

「一致する経路がありません」の意味

空の結果は失敗ではなく、1つの答えです。現在のグラフには、それらをつなぐものが何もありません。正直な注意点が2つあります：カバレッジは接続した範囲そのものなので、当社に見えない経路は存在しない経路と同じではありません。そして データ分類は決して推測しません ——データストアは unknown のままです（DSPM がサンプリングするか、ラベルを付けるまで）。そのため、まだ分類されていないアカウントでは、分類でフィルターした質問は正しく何も返しません。分類を有効にしてスキャンを実行すれば、回答が得られるようになります。

攻撃経路分析とは

攻撃経路分析は、攻撃者が環境内を移動して重要なアセットに到達するために使えるルートをマッピングします。これが必要なのは、個々のスキャンが何千もの検出結果を出しても、そのうちどれが 連鎖 して悪用可能なものになるかは示されないからです。設定ミス単体が侵害になることはまれですが、設定ミスに弱い権限と公開されたホストが加われば侵害になります。

4つのステップがあり、当社はそのすべてを実行します：

1. アセットとリスクの発見。 ワークロード、アイデンティティ、設定、データに対するエージェント不要の完全な可視化——さらに脆弱性、露出したシークレット、設定ミス、過剰な権限。中規模の AWS アカウントでは、通常数百のアセットと数万の権限関係になります。
2. グラフベースのマッピング。 これらのリスクは、リソースを結び付けてその関係を示す1つのグラフに配置されます——たとえば、パブリック IP を持つワークロード と クリティカルな脆弱性が、過剰な権限を持つアイデンティティに結び付いている状態です。すべてのエッジには信頼度があります：実証済み、設定からの抽出、推測のいずれかです。
3. 経路の特定。 グラフ上で 危険な組み合わせ を探索します——個々には深刻度の低い複数の問題が連鎖して、価値あるものへの影響の大きいルートになる組み合わせです。グラフに対して8つのルールが実行され、それぞれが path （経路）を返します。アラートではありません。
4. 優先順位付け。 経路は深刻度順、次に 実証済みを理論上のものより優先、次に経路の直接性、最後に影響範囲でランク付けされます。最重要アセットや権限昇格に至るルートは、無害な場所で終わるルートよりも上位になります。

探索の仕組みについて補足します。答えが変わるからです。単純な最短経路探索で見つかるのは、各ターゲットへの 最短 のルートですが——それが重要なルートでないことはよくあります。公開読み取り可能なバケットには1ホップで到達でき、その1ホップが、同じバケットに到達する3ホップの認証情報窃取の連鎖を覆い隠してしまいます。そのため、特定の種類のホップに依存するルールは、そのホップを 経由する 経路を明示的に探索し、連鎖は覆い隠されずに報告されます。

クロスクラウドリスク

概要： あるクラウドで始まり別のクラウドで終わる攻撃経路——各プロバイダーのツールは自分自身しか見ないため、どちらのツールにも見えない経路です。

仕組み： 実際に境界をまたぐ信頼関係を読み取ります：信頼ポリシーで Entra ID や Google の発行者を指定している AWS のロール、AWS アカウントを信頼している GCP のワークロードアイデンティティプールなど。エッジが成立するのは双方が合意している場合だけです——付与された権限だけでは決して十分ではありません。

グラフ上: 確認された境界をまたぐ信頼は、クラウド間の can-assume エッジになり、それを通る攻撃経路はすべて T3——クラウド間ピボット のリスクとしてランク付けされます（ GET /api/cloud/risks）。エッジごとの完全な経路と証拠が付属し、実証済みが潜在より先に並びます。グラフはオープンなノードリンク JSON としてエクスポートされるため、ご自身でたどることもできます： graphify path "aws-prod" "azure-tenant" --graph graph.json。

過度に広い信頼は、それ自体が検出結果です。 信頼ポリシーに sub （subject）条件がないロールは、その外部テナントの すべての アイデンティティを信頼してしまい、意図した1つだけではなくなります——OIDC のスニペットをコピーする際にうっかり出荷しやすく、経路が描かれる前の時点でも、それ単体でクリティカルな検出結果です。

アイデンティティの信頼に加えて、クラウド間のリンクがさらに3つあります。

• ネットワーク： AWS、Oracle Cloud、Azure、Google Cloud のサイト間VPNトンネルを両側で読み取り、パブリックIPで照合します。そのため、AWS から Oracle ゲートウェイへのトンネルは2つのネットワーク間の1本のリンクとして表示されます。
• 実際の利用： AWS CloudTrail は過去24時間のすべてのAPI呼び出しの送信元アドレスを記録します。接続済みの別クラウドのVMからの呼び出しは、そのVMから使用されたAWSアイデンティティへの実証済みリンクになります。
• 他所で使うためのキー： Oracle の S3 互換キーを所有ユーザーとともに一覧表示します。コード内で見つかったクラウドキー、および identity domains を使うアカウントでの Oracle サインインのフェデレーションは、まだ対象外です。

重要な理由： フェデレーテッドアイデンティティは、チームが長期間有効なキーを避けるための手段です——そして、攻撃者がクラウド間を移動する手段でもあります。AWS、Azure、GCP のいずれも、 相手 側が付与した信頼にはフラグを立てません。これはまさに、単一クラウドのポスチャツールが見逃す死角です。

ツール： AWS IAM の信頼ポリシー、Microsoft Graph 経由の Entra ID、GCP のワークロードアイデンティティフェデレーション。発行者は 識別されたもののみを扱い、推測は決してしません——認識できない発行者からはクラウド間のエッジは生成されません。誤ったラベルのエッジは、エッジがないことよりも悪いからです。

データセキュリティポスチャ（DSPM）

概要： 可視化するのは実際の中身です。対象 は お客様のデータストア——個人データ、カード会員データ、健康データ、認証情報——と、本番環境のコピーがひそかに置かれている場所です。

仕組み： 2つの階層があります。 範囲を限定したサンプリング では、すでに付与したのと同じエージェント不要のロールを通じて、上限付きの少量のオブジェクトをサンプルとして読み取ります——スナップショットも追加の権限も不要で、何もインストールしません。VM のディスク上にある管理対象外のデータベースについては、 一時的なスナップショットワーカー が お客様のアカウント内で実行され、スナップショットを読み取り専用でマウントし、 検出結果のみ を送信します——値、ファイルの内容、行は一切送信しません——その後終了します。

シャドーデータ： データストアはスキーマのフィンガープリントで識別されるため、ステージングのバケットにある本番環境のスキーマは、確認すべきコピーとしてフラグが立てられます——そのコピーがインターネットにも公開されている場合は、クリティカルに引き上げられます。

重要な理由： 何が懸かっているかを知らなければ、深刻度に意味はありません。CSS ファイルの公開バケットと顧客レコードの公開バケットは、同じ検出結果でありながら、まったく異なるリスクです。両者を分けるのが分類であり——だからこそ当社は決して推測しません：ラベルのないデータストアは unknownのままであり、安全とも機密とも決して仮定しません。

ツール： パターン + エントロピーによる分類器と妥当性チェック（Luhn、SSN の構造）、列名による裏付け、系統追跡のためのスキーマフィンガープリント。オブジェクトごと・合計ともに上限があり、カバレッジは実際にサンプリングした範囲として報告され、外挿されることはありません。

コードからクラウドへ——出荷前に止める

概要： すべてのプルリクエストで Terraform、CloudFormation、ARM、Kubernetes のマニフェストを読み取り、変更が実際の問題を生む場合にビルドを失敗させるチェックです。

仕組み： 計画されたリソースをお客様の 稼働中の リスクグラフに統合し、その変更が もたらす ものを報告します——アカウントの現状ではありません。検出結果はプルリクエストに1件のコメントとして返され、プッシュのたびにそのコメントが編集されます。毎回新しいコメントが追加されることはありません。

ゲートがブロックするのは、差分に責任があるものだけです： 差分が宣言するクリティカルな設定ミス、差分がもたらす攻撃経路、差分がコミットする認証情報。既存のアカウントのリスクが 決して プルリクエストをブロックすることはありません——そうしたゲートはいずれ無効化されるからです。レポートのみのモードへの切り替えは1行の変更で済みます。

重要な理由： 設定ミスを修正するのに最も安価なタイミングは、それが存在する前です。それ以降はすべて、修正作業、変更ウィンドウ、そして優先順位をめぐる議論になります。

ツール： 本物の HCL パーサー（行マッチングではありません）に加え、CloudFormation / ARM / Kubernetes に対応。シークレットスキャンはプレースホルダーや変数参照を除外します—— password = var.db_password にフラグを立てるようなスキャナーは、人に無視することを覚えさせるだけです。対応環境： GitHub Actions と Azure DevOps。認証にはアセットごとのキーを使用し、アカウントのトークンは決して使用しません。

グラフに質問

概要： 保存済みの質問と、想定していなかった質問のためのクエリビルダー—— 「個人データを含むデータストアへのアクセスを許可する平文のキーを保持している、インターネットに公開された VM をすべて表示して。」

仕組み： アセットの種別を選び、属性で絞り込み、関係をたどって到達できるものを表示します。結果は 経路 であり、各ホップの証拠が付属します。名前の一覧ではありません。

重要な理由： インシデント対応中に生じる質問は、ベンダーがあらかじめ用意したものとは限りません。フリーテキスト検索では「A と B と が C に到達する」を表現できません——これは集合への所属と到達可能性の問題であり、グラフが必要です。

ツール： 閉じた安全なクエリ形式——クエリはコードではなくデータであり、関係は検証され、探索範囲には上限があります。そのため、コード実行に転用されることも、大規模な環境で停止することもありません。

修正 & チケット管理

概要： リスクがルールに一致したときに送信される署名付き Webhook——自社の自動化につなぐことも、攻撃経路をチケットに含めて Jira や ServiceNow に直接送ることもできます。

仕組み： ワークフローは POST /api/workflows — { name, url, kind: "webhook|jira|servicenow", rules: ["T2"], min_severity: "critical", proven_only: false, auth_header }で登録します。配信は、リスクがフィルターの すべて に一致した場合にのみ行われます：名前付きグラフルール（T1–T8）のいずれかであること、 min_severity以上であること、そして—— proven_only を設定した場合は——経路が単に到達可能なだけでなく、実際にエクスプロイトされたこと。署名シークレットが返されるのは 一度 だけで、再表示はされません。 POST /api/workflows/<id>/test は疑似的な配信を行うため、実際のイベントの前に接続を検証できます。

すべての配信を検証してください。 各リクエストには、生のボディに対する HMAC 署名が X-Millennium-Signature ヘッダーに含まれます。シークレットで再計算し、一致しないものはすべて拒否してください。配信にはリプレイ制限（タイムスタンプ + nonce）があり、宛先は 公開 アドレスに解決される HTTPS である必要があります——Webhook が内部サービスやクラウドのメタデータエンドポイントに向けられることは決してありません。

上流での防御： 同じリスクグラフが コードからクラウドへの PR ゲート — POST /api/iac/scan を支えています。このゲートは、稼働中のグラフに対してクリティカルな攻撃経路を もたらす プルリクエストを失敗させます。そのため、最も安価な修正（マージしないこと）が、修正すべきものが生じる前に行われます。

重要な理由： クラウド全体への書き込み認証情報を保持するセキュリティベンダーは、壊滅的な障害の単一障害点であり、セキュリティレビューを通すのが最も難しい存在です。検出と実行を分離することで、この両方の問題が解消されます。

ランタイムセンサー エンタープライズ向けアドオン

概要： Kubernetes ノード、Linux VM、エンドポイントセンサーのあるマシンからの任意のランタイム検出結果を、他のすべてと同じリスクグラフに表示します。

仕組み： 構成： Falco 検出結果を Redthread に直接送信する DaemonSet と、静かなノードでもオンライン表示を保つ小さなハートビート用サイドカー。アプリで有効化し、センサーを追加して、表示される 3 つのコマンドを実行します。オフにするとすべてのセンサーが即座に取り消されます。

Linux VM: センサーを登録した後に表示されるコマンドを、VM 上で root として実行します。公式の falco.org パッケージリポジトリから Falco をインストールし、モダン eBPF プローブ（Linux 5.8 以降、カーネルモジュール不要）を選択し、各検出結果を Redthread に送信する root 専用の設定を書き込み、再起動後も動作するサービスとして Falco を起動します。Falco の HTTP 出力はヘッダーを設定できないため、センサーキーはその設定の URL に含まれます。このキーでできるのは検出結果の送信だけです。Debian と Ubuntu（apt）、RHEL、Oracle Linux、Amazon Linux、Fedora（dnf または yum）に対応しています。削除するには同じコマンドを --uninstall 付きで実行してください。

クラウド内のすべての VM: MAI_SENSOR_KEY を加えると、Cloud Shell のフリートコマンドで Falco もインストールされます（Runtime → センサーを追加 で入力済みのものが表示されます）。Azure（Run Command は root で実行）と Google Cloud（sudo 付きの gcloud ssh）ではすべての Linux VM に Falco が入ります。Oracle Cloud では Run Command が制限付きユーザーで実行されるため、1 回限りの管理者設定でそのユーザーに sudo が与えられた VM にのみ Falco が入り、その他の VM はサマリーに表示されます。

エンドポイントセンサーのあるマシン: エンドポイントセンサーは 20 秒ごとに実行中のプロセスを確認し、暗号資産マイナー、リバースシェルのパターン、一時フォルダから実行されるプログラムを検出すると、最初に現れた時点で送信します（一致ごとに 1 時間に 1 回）。カーネルアクセスは不要で、macOS と Linux で動作します。1 回の確認より短いものは見えないため、Linux では Falco がより網羅的な選択肢です。コマンドラインはマシン上で照合され、送信されることはありません。検出結果に含まれるのはルール、短いプロセス名、時刻だけです。検出結果は Runtime がオンの間だけ受け付けられ、オフの場合センサーは 6 時間送信を停止します。

重要な理由： 設定はドリフトしますし、設定が1つも変わらないままワークロードが侵害されることもあります。プロバイダーの脅威フィードは、エージェントなしでもその多くを捕捉します——これは、1分未満のカーネル内の可視性に特権 DaemonSet を置く価値があると判断したチーム向けの機能であり、当社のデフォルトではなく、意図的にそのチームの判断に委ねています。

防御ではなく、検知。 ブロック、強制終了、隔離は一切行いません。プラットフォームのほかの部分はサーバーに何もインストールしませんが、これは意図的にインストールを伴います。そのため、独立したアドオンとして提供し、デフォルトではオフです。完全にエージェント不要のままにしたい場合は、GuardDuty、Security Hub、Inspector の検出結果を、エージェントなしで同じグラフに取り込めます。

ツール： eBPF プローブとルールセットには Falco（CNCF）を使用します。ハートビート用サイドカーは非特権で、すべての capability を外しています。取り込み量には上限があり、上限を超えたイベントは破棄 カウントされ、黙って失われることはありません。

ネットワークペネトレーションテスト——各フェーズ

このセクションはアプリ内でお客様のみご覧いただけます： サインイン して、いずれかのドキュメントリンクを開いてください。

コンプライアンスレポート & 証明

完了したすべてのスキャンから、企業がテストの拠り所とする標準（PTES、NIST SP 800-115、OWASP WSTG、CREST、CVSS）に基づいた監査対応レポートが作成されます。読み手ごとに適切な内容を届けられるよう、3 つの階層で提供されます：

• 証明書（Letter of Attestation） ——機密情報を伏せた署名付きの 1 ページの文書で、 お客様の 顧客、調達部門、サードパーティリスクの審査担当者にそのまま提出できます。スコープ、期間、手法、深刻度別の件数を記載し、エクスプロイトの詳細は含みません。取得先： GET /api/runs/{id}/attestation。
• 完全なコンプライアンスレポート ——エグゼクティブサマリーと、検出結果ごとの技術的詳細：実施規則（Rules of Engagement）、深刻度ヒートマップ、修復ロードマップ、そして各検出結果を OWASP LLM 2025 → MITRE ATLAS → NIST AI RMF / ISO 42001 / EU AI Act にマッピングする AI トレーサビリティマトリクス。SOC 2、ISO 27001、NIST CSF にもクロスマッピングされています。 GET /api/runs/{id}/compliance。
• JSON 版 ——内容は report.json と同じデータで、Vanta、Drata、Secureframe 向けです。 GET /api/runs/{id}/compliance.json。

スコアリングを正直に。 CVSS は、依存関係の CVE については実際のアドバイザリスコア、脆弱性クラスについてはそのクラスの標準ベースベクトル（その旨を明記）であり、捏造した数値を使うことはありません。振る舞いに関する検出結果（ジェイルブレイク、プロンプトインジェクション）には、 攻撃成功率（Attack Success Rate） を付与します——実際の成功回数 / 試行回数に基づく数値で、測定を行った場合に限ります（POST /api/runs/{id}/measure-asr）。100 回中 3 回しか成功しないジェイルブレイクは、90 回成功するものとは別物だからです。

ツール： CVSS 3.1 スコアリング、 OWASP LLM 2025 + MITRE ATLAS v5.6.0 によるトレーサビリティ、PCI DSS 11.4、SOC 2、ISO 27001 / 42001、NIST CSF / AI RMF、EU AI Act へのフレームワーク・クロスマップ、 OpenVEX による影響あり / 影響なしの判定、Wilson 95% 信頼区間付きで報告する攻撃成功率。オプションで、認定 CREST/OSCP 資格者による人手のレビュー。

SSO、SCIM & ロール

概要： チーム向けのエンタープライズ向けアイデンティティ管理——シングルサインオン、ユーザーの自動プロビジョニングと デプロビジョニング、ロールベースのアクセス制御、監査ログを提供します。すべてのアセット、スキャン、検出結果はワークスペース単位でスコープされます。

仕組み： 4 つのロール—— owner （請求を含むすべて）、 admin （ワークスペースの管理）、 member （実作業）、 viewer （読み取り専用）——に加えて：

• シングルサインオン（OIDC） ——チームは自社の ID プロバイダー（Okta、Entra/Azure AD、Google、Auth0）でサインインし、自社メールドメインの新規ユーザーは自動的にプロビジョニングされます。オーナーが、発行者 URL、クライアント ID / シークレット、ドメインを設定します。
• SCIM 2.0 プロビジョニング ——IdP がユーザーの作成と、そして何より重要な プロビジョニング解除 を自動的に行います。IdP でユーザーを無効化すると、ここでのアクセスも即座に遮断されます。フラグを切り替えるだけでなく、トークンそのものが失効します。
• 監査ログ ——誰がどのスキャンを実行し、誰がどのレポートを閲覧またはエクスポートしたかを記録します。

重要な理由： チーム規模になると、リスクは外部だけではありません——アクセス権が削除されないままの元従業員や、過剰な権限を持つアカウントもリスクになります。SSO はサインインを IdP のポリシー（MFA、条件付きアクセス）に一元化し、SCIM はオフボーディングを即時に完了させます。誰かが処理を忘れるチケットに頼ることはありません。

ツール： SSO には OpenID Connect（OIDC）——Okta、Microsoft Entra ID、Google Workspace、Auth0。 SCIM 2.0 でプロビジョニング / プロビジョニング解除。テナントごとのベアラートークン（定数時間比較と即時失効に対応）。Enterprise プラン。設定方法は SSO & SCIM を参照してください。

ガイド：最初のスキャンを実行する

目標：新しいアカウントから、実証済みの検出結果を得るまで。

前提条件

• 確認済みのアカウント (ブラウザ版クイックスタート)。
• 対象 URL ——所有している、またはテストを許可されている、稼働中のアプリのインスタンスです。 ステージング URLを使用し、本番環境は使用しないでください。これは 必須項目です。コードだけでは稼働中のアプリになりません。お持ちでない場合は、次を参照してください： スキャン対象の選び方。
• 任意：ソースコード ——git リポジトリの URL、または .zip のアップロード。より詳細な ホワイトボックス スキャンに使用します。

手順

1. アプリを開いてスキャンボックスに対象を貼り付けるか、次を呼び出します： POST /api/scan。
2. ソースコードがある場合は追加してください——リポジトリ URL またはローカルパスを source フィールドに指定します。検出結果の品質を左右する、最も効果の大きい手段です。
3. スキャンを開始し、次の値を控えておきます： run_id。
4. 完了するまで待ちます（ステータス running → false）。通常は数分です。
5. レポートを開き、上から順にトリアージします。まずはクリティカルから。

トラブルシューティング

• 403「verify your email」 ——確認リンクをクリックするか、「再送信」を押すか、次を呼び出します： POST /api/resend。
• 402、利用枠の上限に到達 ——プランに含まれるスキャンもパックのスキャンも残っていません。「請求」でスキャンパックを購入してください（プラン)。
• 500「scan did not start」 ——エンジンを起動できませんでした（Docker またはモデルキーの問題）。セルフホストの場合は .envを確認してください。当社のホスト型アプリの場合は、再試行してください。
• URL のみのスキャンで検出結果がゼロ —— source を指定して再実行してください。ブラックボックスだけでは、AI 固有の経路を見逃すことがよくあります。

ガイド：スキャン対象を登録する

同じアプリを繰り返しスキャンする場合は、毎回貼り付ける代わりに スキャン対象 タブで一度登録してください。各対象は個別の設定を記憶するため、再スキャンは 今すぐスキャンを 1 回クリックするだけです。CI プランがプルリクエストごとに自動スキャンするのも、この登録済みの対象です。

各フィールドの役割

［今すぐスキャン］をクリックしたときの処理

1. 設定がチェックされ、実行できない指定はすぐに検出されます——たとえば 変更されたファイルのみ にはコードリポジトリが必要なため、スキャンが失敗した後ではなく、開始する前に通知されます。
2. お客様の プランと支出上限 が適用されるため、スキャンが予算を超えて実行されることはありません (参照： 支出上限 & 安全性)。
3. テストは使い捨ての隔離されたサンドボックスで実行されます——コードが再利用・保持されることはありません (参照： お客様のデータ)。
4. 完了すると、結果は次の場所に表示されます： ペネトレーションテストの検出結果 (参照： スキャン結果の読み方)。

ガイド：スキャン結果を読む

スキャンが完了したら、 スキャン 一覧から開きます。結果は ペネトレーションテストの検出結果に表示され、タブごとに整理されているため、目的のセクションまでスクロールする必要はありません。

タブ

検出結果を絞り込む

大規模なスキャンでは、数百件の検出結果が表示されることがあります。一覧の上にある色付きのピルで絞り込めます——いずれかをクリックすると絞り込まれ、 ✕ フィルターを解除 をクリックするとすべてが再表示されます：

1. 深刻度ピル — クリティカル 高 低 ——その深刻度の検出結果のみを表示します。大規模なスキャンは、デフォルトで最も深刻なものに絞った状態で開くため、最も重大なものが最初に目に入ります。
2. ⚡ PoC ——実際に動作する、実証済みのエクスプロイトを伴う検出結果（最も確度の高いもの）のみを表示します。

すべての検出結果は、表示前に敵対的な再チェックも受けます。スキャナーが 誤検知の可能性が高い と判断したものは、デフォルトで非表示になります（トグルで再表示できるため、その判断を自分で確認できます）。

個々の検出結果を読む

1. クリティカルと高から始める ——攻撃者が最も早く到達するのはこれらです。
2. 「概念実証（PoC）」を開く と、脆弱性がどのように悪用されるかを、平易な手順で正確に確認できます。有料プランでは、 ▸ エクスプロイトスクリプト を展開すると、実際に実行可能なエクスプロイトが表示され、エンジニアが再現できます。
3. 「修正方法」を読む ——具体的な修正内容——と、該当するコードの 箇所を確認します。
4. 修正し (次のガイドを参照)、 再スキャン して、穴が塞がれたことを確認します。

ガイド：スキャンで見つかった問題を修正する

ご利用中のプランが Starter プラン以上で、 GitHub を接続済みであれば、Redthread が修正を プルリクエスト として作成します——レビューとマージはお客様が行います。 何も自動では変更されません。完了したスキャンの上部の行に、ワンクリックで実行できるアクションが 2 つあります。

始める前に

• ご利用中のプランが Starter プラン以上であること。
• 事前に GitHub を接続 し（連携タブ）、スキャンのソースとして GitHub リポジトリ を使用していること。
• スキャンが 完了 していること——途中で停止したスキャンは、先に 再開 して完了させることができます。

1. 自社のコードを修正する—— ⚙ 修正 PR を生成

対象： アプリケーションの検出結果 —— お客様の コードに含まれる欠陥（アクセス制御の不備やインジェクションなど）：

1. 完了したスキャンを開き、次をクリックします： ⚙ 修正 PR を生成 （上部の行にあります）。
2. 各検出結果の原因となっているコードを特定し、 最小限の修正を書いたうえで、リポジトリに ドラフトのプルリクエスト を作成します。
3. 次をクリックします： ↗ 修正 PR を表示 ——GitHub でレビューできます。
4. 修正内容が適切でない場合は、次をクリックします： ↻ 再生成 ——変更する点や維持する点を指示してください（例： 「既存のセッションチェックを維持する」）。 指示を反映して再試行し 、同じ PR を更新します——重複した PR は作成されません。

2. 脆弱なライブラリを修正する—— ⬆ 依存関係を更新

対象： 依存関係の検出結果 ——アプリが依存するサードパーティライブラリの既知の CVE：

1. 次をクリックします： ⬆ 依存関係を更新 （上部の行にあります）。
2. 脆弱な各パッケージを 修正済みバージョン に更新し（対象は編集可能なマニフェスト：requirements.txt, package.json）、次を作成します： ドラフト PR。
3. バージョンが ロックファイル (package-lock.json, poetry.lock, uv.lock) で固定されている脆弱性は、手作業では安全に編集できません——PR には、それぞれについて実行すべき正確なコマンドが記載されます (例： npm install [email protected])。
4. 変更内容をレビューし、記載されたロックファイル用のコマンドを実行してから、マージします。

ガイド：すべてのプルリクエストでスキャンする

Starter プラン以上では、AI の攻撃面に関わる各プルリクエストに対してスコープを絞ったスキャンが実行され、実証済みの新規脆弱性があればマージをブロックします。繰り返し現れる検出結果は重複排除されるため、本当の問題が見つかるまでパイプラインは静かなままです。また Starter プラン以上では、確認済みの検出結果からドラフトの修正プルリクエスト（および依存関係更新 PR）を作成し、エンジニアがレビューすることもできます——自動でマージされるものはありません。レビューのステータスは次で確認できます： GET /api/pr-reviews。

ガイド：GitHub Action でスキャンする

当社が公開している GitHub Actionを使えば、あらゆるパイプラインにスキャンを組み込めます。push 時にスキャンしてビルドをゲートします——または通知だけを行います。

GitHub Marketplace からインストール →

1. トリガーキーを取得します。 アプリの 継続 ビューでアセットを開き、 CI をクリックすると、アセットごとのトリガーキーとアセット ID が表示されます。キーはその 1 つのアセットにスコープされます——そのアセットのスキャンの開始と読み取りはできますが、アカウント全体にはアクセスできません。
2. リポジトリのシークレットとして保存します 。名前は次のとおりです： REDTHREAD_SCAN_KEY。
3. ワークフローを追加します 。配置先： .github/workflows/security.yml:

name: security
on: [push]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: bl014h/redthread-scan-action@v1
        with:
          api-key: ${{ secrets.REDTHREAD_SCAN_KEY }}
          asset-id: "abcd1234"
          fail-on: high   # critical | high | medium | low | never

fail-on: never は通知のみのモードです——スキャンを実行してジョブサマリーを投稿しますが、ビルドを失敗させることはありません。キーは同じパネルからいつでもローテーションでき、古いキーは即座に無効になります。

ガイド：ChatGPT と Claude で Redthread を使う

Redthread は MCP サーバーを提供しているので、AI アシスタントにセキュリティ状況を普通の言葉で質問できます。前回のスキャンから何が変わったか、どの攻撃パスが実証済みか、誰もレビューしていない AI サービスはどれか。ChatGPT、Claude、OAuth 付きのリモート MCP サーバーに対応するあらゆるクライアントで使えます。

1. サーバーを追加します。 アドレスは https://app.redthreadsec.com/mcpです。Claude では Settings → Connectors → Add custom connectorを開きます。ChatGPT では Settings → Apps & Connectors を開いてコネクタを作成します（開発者モードが必要です）。
2. サインインして許可します。 アシスタントが Redthread のページを開きます。サインインしてワークスペースを確認し、次をクリックします： 許可。
3. 質問します。 例：「最も深刻な攻撃パスは？」や「checkout API の前回スキャンの検出結果を見せて」。

アシスタントは、セキュリティ概要、攻撃パス、スキャンの検出結果、シャドー AI 一覧を読み取り、Redthread の署名付きレジストリスキャンで MCP サーバーを確認し、接続済みクラウドの読み取り専用の再スキャンを開始できます。新しいクラウドの接続、設定変更、キーの閲覧、削除はできません。

ガイド：スキャンについて質問する

検出結果の意味や、自社のスタックでの修正方法がわからない場合は、質問してください。 POST /api/chat はメッセージのリストと、オプションで run_id を受け取り、そのスキャンの検出結果に基づいて回答します。レポートを修正計画に落とし込む際に活用してください。

プラン、クォータ & 超過分

プランは、環境の規模と使用量に合わせてお見積もりします——料金ページから 見積もりを依頼 してください。プランの利用枠と上限は、アプリの次の画面に表示されます： 請求。

• スキャンとは？ 1 つの対象に対する 1 回の実行です。プルリクエストのチェックとフルスキャンは、それぞれ 1 回としてカウントされます。
• ペンテストスキャン。 各有料プランには、ワークロード10件ごとに月1回のペンテストスキャンが含まれます（切り上げ。Starterは3回、Growthは15回）。環境が大きいほど回数が増えます。それを超えるスキャンは、プリペイドのスキャンパック（5回または20回、有効期間12か月）を使用するか、カード登録済みの場合はスキャンごとに課金されます。
• 無料枠。 生涯1回のペンテストスキャン（リセットなし）で、判断する前に実際の検出結果を確認できます。動作するエクスプロイトと自動修正は有料プランで利用できます。

既存のお客様は、アプリから、または次の API でプランを変更できます： POST /api/billing/checkout。新しいプランをご希望の場合は、こちらへ： お問い合わせ。

開発フェーズ

このセクションはアプリ内でお客様のみご覧いただけます： サインイン して、いずれかのドキュメントリンクを開いてください。

API リファレンス

このセクションはアプリ内でお客様のみご覧いただけます： サインイン して、いずれかのドキュメントリンクを開いてください。