クラウドの弱点をAIに読み取り専用で調べさせるOSS「Cynative」の仕組みと導入前の注意点

「クラウドの設定の見直しをAIに手伝わせたいが、本番の権限を持たせるのは怖い」「読み取り専用と書いてある道具なら、管理者の鍵のまま動かしても大丈夫なのか」——クラウドの運用とセキュリティを兼ねる担当者から、こうした相談が増えています。論点は、AIがどれだけ賢く弱点を見つけるかではありません。本当に問うべきなのは、AIの手に渡る鍵と、AIが集めた結果を、誰がどこまで管理するのかという点です。この記事では、クラウドやコードの置き場の設定を読み取り専用で調べるAIエージェントのOSS「Cynative」を取り上げ、読み取り専用を守る仕組み、公開元の実績、導入前に確かめる点を整理します。導入や設定の手順は扱いません。

Cynativeとは何か。2026年10月時点で確かめられる事実

Cynativeは、GitHubで公開されているOSSです。リポジトリの説明は「AWS、Azure、GCP、Kubernetesにまたがるクラウドセキュリティのための、オープンソースのAIエージェントの枠組み」で、READMEの見出しは「自分のセキュリティエージェントを作る」です。READMEによると、利用者の基盤に対して生きた状態のまま、読み取り専用で触れるセキュリティエージェントを作るための枠組みだとされています。

このラインの精査を行った2026年10月19日時点で、スターは223、派生は31でした。リポジトリは2026年6月24日に作られ、最後の更新は10月18日です。1日あたりのスターの伸びは約1.9件で、不自然に急な伸びは見られません。ライセンスはApache-2.0です。READMEには、オープンソースの開発体制の自己点検の制度であるOpenSSFのベストプラクティスの認定を示す印も掲げられています。

リリースは頻繁に出ており、確認した時点の最新は10月13日の1.14.0版でした。9月から10月にかけて、小さな修正と依存部品の更新が数日おきに重なっています。一つのプログラムとして配られ、利用者が用意した言語モデルの接続先を使う形で、自社の環境の中だけで完結させることもできるとREADMEは説明しています。

なぜクラウドの調査にAIエージェントを使うのか

クラウドの設定の点検は、範囲が広いうえに、つながりを追わないと危険が見えない仕事です。ある役割の権限だけを見ても問題がなくても、別の役割を引き受けられる設定や、自動化の仕組みが持つ鍵と組み合わさると、管理者の権限に届くことがあります。READMEが例に挙げる問いも、「公開されるべきでないのに公開されているものは何か」「どの役割が管理者まで権限を上げられるか」といった、複数の設定をまたいで答える必要がある問いです。

Cynativeは、この種の問いを一つ受けると、コードの置き場、クラウド、コンテナ基盤を一つの仕組みとして推論し、検証した答えを返すと説明されています。READMEには、権限の高いクラウドの許可を、それを与えた変更の提案までさかのぼる、ソースコードに漏れたクラウドの鍵と、その鍵が今どこまで届くかを調べる、といった例も並びます。

公開元は、既存のコーディング用のAIエージェントに外部の接続部品をつないだ形との違いも強調しています。READMEの比較では、既存の形は一回の呼び出しで一つの操作しかできず、結果も検証されないとし、Cynativeは読み取り専用を既定にし、判断できないときは止める側に倒す作りだとしています。ここは公開元自身の主張であり、第三者による検証ではない点を押さえておく必要があります。

45の組み込みエージェントで何を調べるのか

READMEとエージェントの一覧によると、Cynativeには45のエージェントが組み込まれています。内訳はAWSが20、Azureが11、GCPが5、GitHubが4、Kubernetesが5です。それぞれが、特定の問いに答えるための確認済みの指示文だと説明されています。

一覧から主なものを挙げます。AWSでは、利用者や役割から管理者の権限へ届く経路、保存領域の公開状態、資源の設定に直接書き込まれた鍵を調べます。Azureでは、コンテナ基盤の管理窓口への到達性や、秘密の保管庫の公開状態を見ます。GCPでは、すべての利用者に権限を与えている設定や、サービス用の鍵と成りすましの連鎖を扱います。GitHubでは、信頼できないコードが鍵を持ったまま動く自動化の流れや、実質的な確認なしに取り込める設定を、Kubernetesでは部品から土台の機械へ権限が広がる設定などを調べます。

組み込みのエージェントは、中身の指示文をそのまま表示して確かめられるとされています。利用者は、それを写して名前を変え、自分用のエージェントとして書き換えることもできます。エージェントは一つの文書ファイルで、冒頭に説明の一行を置き、その後に指示文を書く形式です。つまり、何を調べるかは、人が読める文章として定義されていることになります。調べる観点を社内の基準に合わせて増やせる一方で、その文章の管理も利用者の責任になります。

仕組み1：隔離した場所で調査用のプログラムを書いて動かす

Cynativeの特徴の一つは、AIが調査のための小さなプログラムを自分で書き、隔離された場所で動かす点です。READMEによると、一つの問いが基盤全体に広がり、各サービスの窓口へ並行して問い合わせることで、少ない手間で速く答えに届くとされています。

この隔離環境については、それ自体は外の網にも、動かしている機械にも触れられないと説明されています。触れられるのは、Cynativeが用意した道具の呼び出しだけで、プログラムが書き出した内容だけが言語モデルに戻ります。一回の実行には既定で120秒の時間制限と、出力の大きさの上限があります。

また、プログラムは動かす前に利用者へ示され、承認を求められます。道具の呼び出しも一件ごとに承認が必要です。ただし、端末のない環境で動かすときなどのために、承認をまとめて省く使い方も用意されているとREADMEは書いています。承認を省くかどうかは、導入する側が決めるべき大きな分かれ目です。

仕組み2：鍵を付ける前に権限を照らす「関門」

Cynativeが「作りからして読み取り専用」と名乗る根拠が、READMEで「アクションゲート」と呼ばれる関門です。呼び出しのたびに、その操作に必要なクラウドの権限を割り出し、読み取り用の基準に照らして、合格したものにだけ鍵を付けます。判断できない呼び出しは止める側に倒す作りとされています。基準には、AWSでは監査用の既定の権限の組、GCPでは閲覧者の役割、Azureでは閲覧者の役割、Kubernetesではクラスタの閲覧用の役割が使われます。

ここで目を引くのが、READMEの比較表にある一例です。AWSで秘密の値を取り出す操作は、権限の分類の上では「読み取り」に入ります。そのため、単に書き込みを止めるだけの仕組みでは通ってしまいますが、監査用の基準では止まる、と説明されています。読み取りであっても、秘密の値に届けば被害になるという点を意識した設計だと読めます。

このほか、通信は対応づけたサービスと地域に固定され、直接つなぐ場合は接続先の住所を確かめてから鍵を送るとされています。接続部品の資料によると、社内向けの住所の範囲は多くのクラウドで拒否され、GitLabの自動化用の変数は既定で読めません。READMEによれば、GitHubの秘密の検出結果を返す窓口も閉じられています。道具の出力に含まれる秘密の値は、言語モデルに送る前に伏せられるとも説明されていますが、伏せる規則の中身は、確認した資料には書かれていない点は留意が要ります。

仕組み3：結果を突き合わせて検証し、すべてを記録する

READMEによると、Cynativeは見つけたことを、生きた環境の証拠と突き合わせて検証し、その出どころまでたどると説明されています。言語モデルの答えをそのまま報告にしないための工夫で、AIの出力を証拠で裏づける考え方です。ただし、検証の正確さを示す数値は、確認した資料の範囲では見つけられませんでした。

記録についても具体的に書かれています。すべての道具の呼び出しは、1行ごとに区切った形式の監査用の記録として既定で残され、記録できなければ実行そのものを止める作りです。記録には、使ったエージェントの名前、出どころ、ファイルの指紋に当たる値も残ります。既定の保存は30日、大きさの上限は100メガバイトとされています。

一方で、注意書きもあります。道具の結果は記録する前に伏せられますが、承認を求める画面に出した引数はそのまま保存され、秘密の値を含むことがあるとREADMEは明記しています。記録のファイルは実行した利用者だけが読める設定になっています。監査用の記録そのものが守るべき情報になるということです。

使っている鍵と、つなぐ言語モデル

Cynativeは新たな権限を作りません。接続部品の資料によると、AWSなら各社の開発用部品が標準で探す鍵、GCPやAzureならそれぞれの標準の認証の仕組み、GitHubやGitLabなら各社の道具が持つ合言葉、Kubernetesなら接続設定のファイルを使います。READMEの言葉では、利用者の端末にすでにある鍵をそのまま拾う作りです。鍵が実際に使えると確かめられた接続先だけが登録されます。

ここから分かるのは、Cynativeが実際に何を読めるかは、その端末にどんな鍵が置かれているかで決まるということです。管理者の鍵を持った端末で動かせば、関門の判定さえ通れば、管理者が読めるものはすべて読める範囲に入ります。

言語モデルは利用者が選びます。READMEには、大手の言語モデルの提供元のほか、クラウド各社の言語モデルの提供の仕組みや、自社の機械で動かす仕組みも並んでいます。READMEは、調べるクラウドの中で、そのクラウドの言語モデルの提供の仕組みを通して動かせば、情報が自社の環境の外に出ないと説明しています。公式サイトは、利用状況の送信は行わないとしています。

似た手段と何が違うのか

クラウドの設定の点検には、ほかにも手段があります。確認できた範囲の事実をもとに、Cynativeと比べます。優劣ではなく、何に向いているかの違いとして読んでください。

見る点	クラウド各社の標準の点検機能	コーディング用AIに接続部品を足す形	Cynative
調べ方	決められた規則で設定を点検	AIが一つずつ操作を呼ぶ	AIが調査用のプログラムを書き、並行して問い合わせる
複数の設定をまたぐ推論	規則で定めた範囲	AIしだい	主な狙い。コード、クラウド、コンテナ基盤を一つの仕組みとして扱うと説明
読み取り専用の担保	点検機能の権限による	多くは任意の設定	既定で有効。権限を照らしてから鍵を付ける
結果の検証	規則による判定	検証されないことが多い	生きた環境の証拠と突き合わせると説明
結果の再現性	高い	低い	言語モデルに左右される可能性がある
提供元の実績	大手クラウド事業者	接続部品ごとに異なる	2026年に作られた組織

表のとおり、Cynativeが強みとするのは、決められた規則では拾いにくい、設定どうしのつながりを追う調査です。逆に、毎回同じ結果を出すことが求められる定期の点検では、規則で動く標準の点検機能を置き換えるものではないと考えるのが妥当でしょう。標準の点検で網羅し、つながりの調査をAIで補う、という重ね方が現実的です。

安全性の評価：注意付きとした根拠

このラインでは、紹介するOSSを公開されている事実だけで精査しています。OSSを入手したり動かしたりはしていません。Cynativeの判定は「注意付き」です。

問題が見つからなかった点から挙げます。ライセンスはApache-2.0で、商用を含めて使えます。GitHub上にこのリポジトリのセキュリティ勧告は登録されていません。リポジトリの直下には導入用のスクリプトがありますが、利用者が自分で実行するもので、取り込んだだけで自動的に動く処理ではありません。READMEによると、導入用のスクリプトは配布物の照合値を確かめ、合わなければ止まるとされています。弱点の報告の窓口を示したセキュリティ方針の文書もあります。

注意を付けた理由は二つです。一つは公開元の実績です。リポジトリを持つ組織のアカウントは2026年2月7日に作られ、公開リポジトリは3件、フォロワーは1でした。公式サイトには共同創業者の一人の名前が記事の署名として見えるだけで、所在地や設立時期は書かれていません。もう一つは、クラウドの強い権限を扱う設計であることです。読み取り専用とはいえ、基盤の全体像と秘密に近い情報に触れる道具です。勧告がないことは安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。

導入前に知っておきたい注意点

第一に、読み取り専用の守りの厚さは、クラウドによって違います。接続部品の資料は、鍵そのものの権限を絞り込む仕組みはAWSだけで、しかも役割を引き受けた形の鍵に限られると明記しています。AWSでも、利用者や最上位の管理者の鍵の場合は元の鍵のまま動きます。それ以外の接続先では、利用者の手元の判定が唯一の制御だとされています。資料自身が、上流の権限の仕組みの代わりにはならず、最小限の権限の鍵を使うよう勧めています。

第二に、関門の判定の正しさは、各社の膨大な窓口と権限の対応づけに依存します。リリースノートを見ると、9月10日の1.11.3版では符号化された要求の道筋の分類と認可、10月6日ごろの1.13.0版ではGitHubの関門の経路の抜けを閉じる修正が入っています。勧告として出されたものではありませんが、関門の対応づけは今も詰められている途中と受け止めるのが現実的です。

第三に、中継の設定です。中継の資料によると、中継を通す場合、Cynativeは接続先の住所を自分では確かめず、中継に任せます。中身を読み書きできる種類の中継であれば、鍵を読めるうえ、応答を書き換えて手元の判定を広げることもできると書かれています。第四に、セキュリティ方針の文書には、どの版を修正の対象とするかは書かれていませんでした。報告への受領は3営業日以内、確認した弱点の公開は90日以内とされています。日本語で仕組みや注意点を整理した資料は、確認した範囲では見つけられませんでした。

悪用されうるリスク

Cynativeは守りのための道具ですが、置き方しだいで生まれうる危険はあります。まず押さえたいのは、Cynativeが出す結果そのものが、攻撃者にとっての地図になるという点です。公開されている資源、管理者に届く権限の経路、漏れた鍵の届く範囲の一覧は、守る側にも攻める側にも同じ価値を持ちます。報告の保管先と共有の範囲は、秘密情報と同じ扱いにする必要があります。

次は推測ですが、検討の材料になります。読み取り専用の調査は、権限を盗んだ攻撃者が最初に行う下調べと、見かけの上では似ています。社内で誰かが無断でこの種の道具を動かした場合、正規の点検と、侵入者の下調べを、記録の上で見分けにくくなる可能性があるということです。誰が、いつ、どの鍵で調査してよいかを決めておかないと、検知の担当者が判断に迷います。

もう一つは、言語モデルへ渡る情報です。秘密の値は伏せる作りとされていますが、伏せる規則の中身は確認できませんでした。調べる対象の設定や名前、構成の情報は、選んだ言語モデルの提供元へ送られます。また、クラウドの資源に付けた説明書きなどに紛れた指示を、AIが読み取ってしまう可能性も一般論としては考えられます。公開元は、渡されたデータを指示ではなく分析の対象として扱うとしていますが、その効果を示す数値は見当たりませんでした。なお、Cynativeが実際に悪用された事例は、2026年10月19日時点で確認した一次情報からは見つけられませんでした。

導入を検討するときに確かめること

検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、道具の安全装置より先に、渡す鍵の側で範囲を絞ることです。Cynativeの関門はよく考えられていますが、公開元自身が上流の権限の代わりにはならないと書いています。関門は二重目の守りとして位置づけるのが妥当です。

企業が取るべき対策

一つ目は、調査用の鍵を専用に分けることです。誰の端末で、どの鍵を使って調査したかが記録の上で分かるようにします。クラウドの側の操作の記録と、Cynativeの監査用の記録を突き合わせられる形にしておくと、正規の点検と不審な下調べを見分けやすくなるはずです。

二つ目は、調査の許可の取り決めです。AIエージェントによる設定の調査を、誰が、どの範囲に、どの頻度で行ってよいかを社内の決まりに書きます。セキュリティの監視の担当には、予定された調査を事前に伝えます。三つ目は、結果の扱いです。報告は、弱点の一覧として秘密情報と同じ扱いにし、修正の担当と期限を決めてから共有します。

四つ目は、調達のときの確認です。公開元が2026年に作られた組織であること、どの版を修正の対象とするかが明記されていないこと、関門の修正が今も続いていることを踏まえ、試験用の環境で評価してから本番の調査に広げる段取りを文書で決めます。五つ目は、自社で書き足したエージェントの文書の管理です。調べる観点を定義する文章なので、変更の履歴と確認者を残します。

AIに任せる範囲と、人が決める範囲

Cynativeは、クラウドの設定の調査をAIに任せるための道具です。だからこそ、AIに判断させない部分を先に決める必要があります。どの範囲を調べてよいか、どの鍵を使うか、見つかった弱点をどの順で直すか、誰に報告するか。この四つはAIに委ねず、人が決めて記録に残します。

AIが出した結論は、そのまま対応の根拠にしないことも大切です。Cynative自体も証拠との突き合わせを売りにしていますが、報告を受け取る側でも、各指摘について根拠となった設定や記録を書かせ、人が確認する範囲を先に決めておくと、後から判断を振り返れます。やってはいけない向き合い方を挙げます。

• 読み取り専用とあるのを理由に、管理者の鍵が入った端末のまま動かす
• 一件ごとの承認を省いた自動の調査を、範囲を決めずに定期的に回す
• AIが出した弱点の一覧を、根拠を確かめずにそのまま修正の指示として配る
• 調査の報告を、誰でも読める共有の場所に置く
• セキュリティの監視の担当に知らせずに、本番の調査を始める
• 自社で書き換えたエージェントの文書を、確認者を置かずに使い続ける

裏を返せば、人が決める範囲ははっきりしています。どこを調べ、どの鍵を渡し、何を外に送り、結果を誰が持つか。これが決まっていれば、AIの調査は守りの手数を増やす道具として生きます。

よくある質問：読み取り専用なら本番に向けてよいのか

READMEは「自信を持って本番に向けられる」と書いています。ただし、その前提には、手元の関門が正しく判定することと、渡した鍵が最小限であることの両方があります。読み取り専用は、書き換えられないという意味であって、何も漏れないという意味ではありません。読めた情報は、言語モデルの提供元へ送られ、報告と記録に残ります。

もう一つ、「45のエージェントがあれば、クラウドの点検はこれで足りるのか」という問いもありそうです。答えは「足りない」です。対応するのはAWS、Azure、GCP、Kubernetes、GitHub、GitLabで、接続部品の資料によると、自社で動かす版のGitHubには対応していません。AIの推論に頼る以上、同じ問いでも毎回同じ結果が出るとは限らない可能性があります。

結局のところ、本番に向けてよいかは、道具の性能ではなく、渡す鍵と送る情報と結果の扱いを社内で決めたかどうかで決まります。決めたうえで、標準の点検機能を補う調査の道具として使うのが妥当でしょう。

• Cynativeの機能・版・仕組み・制限は、GitHubのリポジトリとその中の文書、リリースノート、セキュリティ勧告の一覧、公式サイトを2026年10月19日に確かめた範囲に基づきます。リリースが頻繁なため、内容は変わる可能性があります
• 秘密の値を伏せる規則の中身、結果の検証の正確さ、修正の対象となる版は、確認した一次情報の範囲では確かめられませんでした。導入の判断では最新の資料を確認してください
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Cynativeは、AWS、Azure、GCP、Kubernetes、GitHub、GitLabの設定をAIエージェントに読み取り専用で調べさせ、公開状態や権限の昇格経路、漏れた鍵の届く範囲などを洗い出すOSSです。呼び出しごとに権限を照らしてから鍵を付ける関門、外とつながらない隔離環境、記録できなければ止まる監査用の記録など、守りの工夫が資料に具体的に書かれています。Apache-2.0で公開され、GitHub上にセキュリティ勧告は登録されていません。

一方で、公開元の組織は2026年に作られたばかりで実績が乏しく、鍵の権限を絞り込む仕組みはAWSの一部に限られます。結果そのものが攻撃の地図になりうる点も見逃せません。渡す鍵を上流で絞り、送る情報と結果の持ち主を先に決めたうえで使うことが、Cynativeを守りの道具として生かす条件です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。