AIエージェントの危険な操作を実行前に検知して止めるOSS「Prismor」を解説

「開発の現場でAIエージェントに端末の操作を任せ始めたが、何を実行しているのか後から追えない」「秘密の鍵が入ったファイルを読まれて外に送られたらと思うと、許可の範囲を決めきれない」——AIエージェントの業務利用を任された情報システム部門やセキュリティ担当の方から、近ごろ立て続けに届く二つの悩みです。どちらも、もっと賢いAIを選べば解決する話に見えるかもしれません。しかし足りないのはAIの賢さではありません。本当は、AIが道具を使う「実行の手前」に、人が決めた規則で止める関所がないことが問題の芯です。この記事では、その関所を自社の端末の中に置くOSS「Prismor」を取り上げ、仕組みと、2026年10月に公開された重大度の高いセキュリティ勧告から見えた「守りの道具そのものの守り方」を、一次情報に基づいて整理します。導入や設定の手順は扱いません。

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

Prismorは、GitHubで公開されているOSSです。リポジトリの説明では、AIエージェントのための自己運用型の実行時の制御基盤と位置づけられています。AIエージェントが道具を呼び出す前に、その動きを観察する・人の承認を求める・遮断する、のいずれかを選べる仕組みで、秘密情報の漏えい、プロンプトインジェクション（外部の文章に紛れ込ませた命令でAIを操る攻撃）、ソフトウェアの供給網の危険などを、手元の画面で見張れるとしています。

配布の形も確かめておきます。ライセンスはApache-2.0で、商用でも使える一般的なOSSの条件です。公開しているのは開発元の組織のアカウントで、組織の作成は2025年10月、リポジトリの作成は2026年2月です。2026年10月15日時点でスターは約420、フォーク（派生）は54、最終更新は10月14日でした。GitHub上の「リリース」欄は空で、配布はPythonの公開パッケージ置き場であるPyPIを通じて行われています。

PyPIの記録では、最初の版0.1.0が2025年10月19日、最新の1.61.0が2026年10月8日に公開されています。作者は開発元の会社の名義で、保守担当として登録されたアカウントは一つです。リポジトリの作成日とパッケージの初版の日付がずれている理由は、一次情報では確認できませんでした。日本語での紹介記事は、2026年10月15日の検索では見つかっていません。

運営元の公式サイトには、組織全体の規則の管理や承認の通知先の連携など、企業向けの機能をうたう説明と料金のページへの案内があります。ただし、どの機能が無償のOSSに含まれ、どれが有償の提供に限られるのかは、サイトの説明からは読み取れませんでした。OSS版でできることと有償版でできることの線引きは、導入前に運営元へ確かめる必要があります。

なぜ今、エージェントの「実行の手前」に関所が要るのか

READMEは、Prismorが応えようとする問題をはっきり書いています。AIエージェントは端末の命令を実行し、ファイルを読み書きし、認証情報に触れ、外部の窓口を呼び出します。しかもそれを、人の確認が少ないまま、何段階にもわたって自分で進めます。READMEが挙げる危険は、外部の文章による乗っ取り、指示の読み違いによる取り消せない操作、設定ファイルにある秘密情報の持ち出し、子のエージェントを生んだときの見通しの悪さ、権限の引き上げ、依存する部品の書き換え、危ない部品の取り込みです。

ここで大事なのは、READMEの次の指摘です。従来の端末向けの防御製品は、基本ソフトの中核やファイルの動きを見ています。けれど、その動きがAIの判断によるものか、何の作業の途中なのかという文脈までは分からない、という点です。人が打った命令とAIが打った命令は、端末から見れば同じに見えます。

たとえば、エラーを直す作業の途中でAIが設定ファイルを開き、中の鍵を外部に送ったとします。端末側から見えるのは「ファイルを読んだ」「通信した」という事実だけで、それが正当な作業か乗っ取られた結果かは区別しにくいのです。だから、AIが道具を呼び出す瞬間に、その呼び出しの中身を見て判定する層が求められます。Prismorはこの層を、利用者の手元で動かす形で提供する試みです。

こうした考え方自体は、Prismorだけのものではありません。AIエージェントの安全を論じる議論では、AIの出力をそのまま信じず、実行の前に外側で検査するという設計が繰り返し勧められています。Prismorの特徴は、それを多くのAIエージェントに共通の仕組みとして、自社の環境の中に置ける点にあります。

仕組みの芯：道具の呼び出しを実行前に規則と照らし合わせる

READMEと説明文書によると、PrismorはAIエージェントと、そのエージェントが使う道具の間に入ります。つなぎ方は一つではなく、エージェントごとの「道具を呼ぶ前後に処理を差し込む仕組み」、MCP（AIと道具のつなぎ方の取り決め）の中継役、各種のエージェント開発用の部品向けの接続口、AIのモデルとの通信を経由させる中継など、複数が用意されています。

対応するエージェントとして、READMEはClaude Code、Codex、Gemini、Cursor、GitHub Copilot、OpenCode、Kiro、Google Antigravityなどの開発向けのAIエージェントに加え、業務用のエージェントを組むための主な開発部品も挙げています。特定の一社のAIに縛られず、使っているAIエージェントが複数あっても、同じ規則で見張れることを売りにしている点が読み取れます。

判定の中心にあるのは規則の集まり（ポリシー）です。説明文書では、まず配布元が用意した初期の規則があり、プロジェクトごとの規則で個別に上書きできる、とされています。誤検知を抑えるための例外の一覧も置けます。READMEはさらに、組織・プロジェクト・リポジトリの段階で規則を重ね、下の段からは弱められない最低線を置ける、と書いています。規則を文書として管理し、チームで共有できる形になっているのは、企業にとって扱いやすい点です。

初期の規則が見張る範囲として、説明文書は、取り消せない破壊的な命令、秘密情報の持ち出し、資源の使い尽くし、外部から端末を操るための通信、権限の引き上げ、プロンプトインジェクション、外から取ってきたものをそのまま実行する動き、危ない権限を求める拡張機能を挙げ、それぞれに重大度を付けています。なお、言い換えで紛れ込む命令をAIに見分けさせる追加の検査も用意されていますが、初期状態では止まっており、使うかどうかは作業場所ごとに決めるとされています。

観察と強制の二つの動き方と、四つの判定

Prismorには二つの動き方があります。一つは「観察」で、規則に当たった動きを記録するだけで、止めはしません。もう一つは「強制」で、規則に決めた処置を実際に行います。READMEによれば、初期状態は観察で、記録はしても止めることはないとされます。動き方は全体でも、規則ごとにも切り替えられます。

強制のときの処置は、説明文書では四つに分かれています。遮断する、警告して記録したうえで通す、人の承認を求める、そして入力を書き換える（たとえば命令を隔離した環境で動かすように変える）、の四つです。さらに、つないだエージェントの側がその判定に応えられない場合は、黙って通すのではなく遮断に倒すと明記されています。迷ったら止める側に倒す設計で、守りの道具として筋の通った考え方です。

この「まず観察、慣れたら強制」という順番は、導入の現実に合っています。いきなり強制で動かすと、誤検知で開発者の作業が止まり、反発を招きがちです。まず観察でどんな動きが規則に当たるかを見て、誤検知を例外で整え、確かに危ない規則だけを強制に移す。この段階の踏み方は、AIエージェントに限らず、新しい監視の仕組みを入れるとき全般に効きます。

逆に言えば、観察のまま運用を続けている間は、何も止まっていないという点を見落とさないことです。画面に記録が並ぶと守られている気分になりますが、観察は見ているだけです。導入の計画には、どの規則をいつ強制に移すかの期限まで書いておくと、観察のまま放置される事態を防げます。

人の承認を挟む仕組みと、その限界

Prismorの説明では、人の承認を求める処置は、エージェントによって動きが異なります。説明文書によると、Claude Code、GitHub Copilot、Qwen Code、Google Antigravityでは、その場で利用者に承認を求める画面が出ます。一方、それ以外のエージェントでは、OSS版は承認を求める代わりに遮断するとされます。つまり人は問いを目にせず、操作は止まるだけです。

企業向けの版には、承認待ちの操作を管理画面に送り、管理者が承認・却下するまでエージェントを待たせる仕組みが加わる、と説明されています。待ち時間の初期値は300秒で、時間切れ・却下・通信の失敗はいずれも遮断に倒れます。公式サイトには、承認の依頼をSlackやメールなどに送る機能も挙げられていますが、これがOSS版で使えるかは確認できませんでした。

ここから読み取れるのは、どのAIエージェントを使うかで、人の承認の挟み方が変わるという事実です。社内で複数のエージェントを使っているなら、承認を求める規則を書いても、エージェントによっては承認ではなく遮断になります。承認が要る操作を決めるときは、使っているエージェントでそれがどう動くかを、導入前に確かめておく必要があります。

また、承認の画面が出ても、承認するのは人です。毎回同じような問いが続くと、人は中身を読まずに承認しがちになります。承認を求める操作は、取り消せないものに絞り込んでこそ意味があります。何にでも承認を求める設計は、かえって承認の重みを失わせる、という点も押さえておきたいところです。

秘密情報の隠し込みと、外への通信の制御

READMEが挙げる機能のうち、企業の担当者にとって分かりやすいのが秘密情報の扱いです。Prismorには、道具の呼び出しの境目で秘密情報を隠し込み、道具が返した出力からも秘密情報を取り除く仕組みがあるとされます。公式サイトも、秘密情報がAIのモデルに届く前に伏せることを中心的な機能として説明しています。

もう一つは外への通信の制御です。READMEによれば、規則に基づいて外への通信先を絞り、住所を数字で直接指定した通信や、通信を隠すための抜け道（トンネル）を見つけて止める機能があります。AIが乗っ取られて秘密情報を外に送ろうとしても、送り先への通信そのものが止まれば被害は抑えられます。持ち出しを「読ませない」と「送らせない」の両側から抑える考え方です。

加えて、READMEには、わざと置いたおとりのファイル（触られたら異常と分かる目印）や、エージェントごとの権限の設定、道具ごとの分類の付与といった機能も並んでいます。おとりのファイルは、AIが本来の作業と関係のない場所を探り始めたことに気づく手がかりになります。ただし、これらの機能がどの程度確実に働くかは、利用者の環境での確認が必要です。機能があることと、自社の環境で効くことは別だからです。

説明文書には、Prismor自身の安全点検の機能もあり、秘密情報の隠し込みが有効か、秘密を置いたファイルの権限が絞られているか、外への通信の許可の一覧が設けられているかなどを確かめ、一部は自動で直せるとされています。自動で直す機能は便利ですが、何が直されたかを人が記録で確かめる運用とあわせて使うのが安全です。

供給網とMCPの見張り役

AIエージェントは、作業を速く進めるために、外部の部品（パッケージ）を自分で取り込むことがあります。READMEは、ここに危険があると指摘しています。乗っ取られた指示に従って部品を書き換えたり、弱点のある部品を取り込んだりするおそれです。Prismorの供給網の機能は、各言語の部品の取り込みを、脅威の情報や攻撃の痕跡の一覧と照らして危険度を付け、取り込みの時点で規則に基づいて止められるとされています。

MCPに関わる機能も複数あります。一つは、つないでいるMCPの道具や拡張機能の危険度を調べる点検の機能です。もう一つは、特定のMCPの道具を遮断したり、呼び出す前に人の承認を求めたりする規則を、利用者が自分で書ける機能です。

さらにREADMEは、つないでいるすべてのMCPの道具の前に立つ一つの中継役を挙げています。この中継役は、道具を呼ぶたびに規則と照らしてから先に渡し、道具から返った結果にも乗っ取りの命令が混じっていないかを調べてからAIに見せる、と説明されています。道具から返る結果も疑ってかかるという設計は、道具の結果に命令を仕込む攻撃が知られている今、筋の通った方向です。

ただし、これらの照合は、規則や脅威の情報に載っているものを見つける仕組みです。まだ知られていない手口や、言い換えで紛れ込む命令をすべて見つけられるわけではありません。READMEも、AIに見分けさせる追加の検査は、判定役のAIを設定するまでは決まった型での照合だけで動く、と断っています。見張り役を置いても、つなぐMCPの道具を選ぶ判断は人に残ります。

記録の残し方と、改ざんに気づく仕組み

守りの道具として見逃せないのが記録です。説明文書によると、Prismorは遮断した操作だけでなく、AIエージェントのすべての道具の呼び出しを記録するとされます。端末の命令とその出力、ファイルの読み書き、ウェブからの取得、利用者が入力した指示までが対象です。

記録は作業の回ごとに追記だけができる形で残され、手元のデータベースで検索できるようにまとめられます。登録した端末では、記録を鎖のようにつなぎ、電子署名を付けることで、後から書き換えたり消したりすると確認に失敗する仕組みも説明されています。AIが何をしたのかを後から確かめ、記録が改ざんされていないことも示せる。監査や事故の調べに使える形の記録を持てるのは、企業にとって大きな利点です。

一方で、裏返しの注意もあります。すべての命令と出力、入力した指示まで記録されるということは、記録そのものに秘密情報や個人情報が含まれうるということです。秘密情報の隠し込みが働いていても、記録の保管場所と見られる人の範囲、残す期間は、別に決めておく必要があります。

また、READMEには、AIエージェントがPrismor自身の設定を書き換えられないように常に働く自己防衛の規則があり、人が設定を変えるときだけ、時間を区切って合言葉で窓を開けられる、と書かれています。AIに見張りを外させない設計は大切です。ただし次の章で見るとおり、今回の勧告は、AIではなくウェブの閲覧という別の経路から規則を書き換えられるおそれがあったというものでした。

想定される使い方と、従来の手段との違い

Prismorが想定する使い方は、大きく二つに分けられます。一つは、開発者がAIエージェントに端末の操作を任せる場面で、命令やファイル操作を見張り、危ない操作を止める使い方です。もう一つは、業務用のAIエージェントを自社で組むときに、開発用の部品を通じて同じ規則を当てる使い方です。READMEは両方を対象として挙げています。

従来の手段とどう違うのかを、下の表にまとめました。ここでの比較は、一次情報で確かめた説明に基づく一般的な目安で、製品ごとの優劣を示すものではありません。

手段	見ているもの	AIの文脈	止める時点
端末向けの防御製品	基本ソフトの中核・ファイル・通信	分かりにくい	実行の後が中心
AIエージェント側の許可設定	そのエージェントの操作	分かる（一社のみ）	実行の前
Prismor	複数のエージェントの道具の呼び出し	分かる（複数に共通）	実行の前（初期状態は観察のみ）
人の目による確認	画面の表示	分かる	人が見ている間だけ

表のとおり、Prismorの強みは、複数のエージェントに同じ規則を当てられることと、実行の前に止められることです。とはいえ、端末向けの防御製品を置き換えるものではありません。Prismorが見られるのはAIの道具の呼び出しであり、その外で起きることは従来の手段で見張る必要があります。重ねて使う前提で考えるのが現実的です。

性能の面では、READMEは模擬のエージェントの作業で道具の呼び出し1回あたり約0.8ミリ秒の上乗せで済んだとし、規則の組み合わせごとにどの程度の危険を防げるかの比率も示しています。公式サイトにも、Prismorを使うと有害な結果が減ったとする試験の結果が載っています。ただし、いずれも開発元が自ら測った数値で、第三者による検証は確認できていません。参考値として扱うのが妥当です。

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

このラインでは、紹介するOSSを、公開されている事実だけを基に精査しています。OSSをダウンロードしたり動かしたりはしていません。Prismorの判定は「注意付き」です。最大の理由は、重大度「高」のセキュリティ勧告が2026年10月1日に公開され、1.57.0で修正済みであることです。未修正の勧告ではありませんが、1.56.0以前の版には弱点が残るため、使うなら1.57.0以降の版に限ることが条件になります。修正は最新版にだけ入る方針なので、実際には最新版への更新を続ける前提で考えてください。

ほかに確かめた事実も挙げておきます。ライセンスはApache-2.0で、利用の条件に独自の制限は見当たりません。配布の設定に、取り込んだ時点で自動的に動く処理は見つかりませんでした。公開元は組織のアカウントで、更新は活発です。セキュリティの方針の文書があり、弱点の報告は非公開の窓口で受けると定めています。勧告も、報告者が非公開の手順で届け出たものとされ、弱点の扱いの手順が実際に回っていることは前向きに評価できます。

一方で、気になる点もあります。PyPIに登録された保守担当のアカウントは一つで、運営元の公式サイトには所在地や運営する人の名前が見当たりませんでした。公式サイトには第三者の認証を示す印も載っていますが、その中身は本記事では確かめていません。守りの道具は、強い権限で動き、すべての操作の記録を持ちます。道具そのものを誰が保守しているかは、ふつうの道具以上に重い確認項目です。

なお、ここで問題が見つからなかった点についても、それは安全の保証ではありません。このラインの精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。導入するかどうかは、自社の確認の手順に沿って判断してください。

公開された勧告の中身と修正の状況

勧告の中身を、悪用の手順に踏み込まない範囲で整理します。Prismorは、手元の画面のために、自分のパソコンの中だけで待ち受ける窓口を開きます。この窓口のうち、全体の規則とプロジェクトの規則を書き換える二つの窓口に、認証がなかったことが一つ目の問題です。

二つ目は、その窓口がすべての応答で、どのサイトから来た要求でも受け付けると答える設定（異なる配信元からの読み書きを許す設定を、すべて許可にした状態）になっていたことです。この二つが重なると、利用者がPrismorを動かしたまま悪意のあるウェブページを開くだけで、そのページから規則の書き換えの要求が送られ、利用者が気づかないうちに全体の規則を上書きされるおそれがありました。勧告はこれを、サイトをまたいで利用者に偽の要求を送らせる攻撃の一種として分類しています。規則を書き換えられると、以降の作業でファイル操作・命令・通信の見張りが外れうる、と勧告は影響を説明しています。

加えて、プロジェクトの規則を書き込む先の場所を確かめておらず、指定された任意の場所に規則のファイルを書き込めてしまう点も、副次的な問題として挙げられています。勧告によれば、影響を受けるのは1.56.0以前の版で、修正版は1.57.0です。PyPIの記録では、1.56.0の公開が2026年9月30日、1.57.0の公開と勧告の公開がともに10月1日で、2026年10月15日時点の最新版は1.61.0です。

勧告には、回避策は示されておらず、修正版への更新が対処とされています。勧告が勧める直し方は、書き込みの窓口に起動のたびに作る合言葉での認証を必須にすること、書き込みの窓口ではほかのサイトからの要求を許さないこと、書き込み先の場所を利用者の作業場所の中に限ることの三点です。1.57.0でこれらがどこまで入ったかのコードの検証は、本記事では行っていません。共通番号（CVE）は2026年10月15日時点で付いておらず、報告者は修正の公開時に番号の付与を求めたと記されています。

悪用されうるリスク：守りの道具そのものが狙われる

今回の勧告から学べる最も大きな教訓は、守りの道具の管理画面は、それ自体が攻撃の入り口になりうるという点です。PrismorはAIエージェントに規則を書き換えさせない自己防衛を備えていました。けれど、規則を書き換える経路は、AIの外側、つまり同じパソコンで動くウェブの閲覧の側に開いていました。

自分のパソコンの中だけで待ち受ける窓口は、外から届かないので安全だと思われがちです。しかし、利用者が開いたウェブページは、利用者のパソコンの中から要求を送れます。「自分のパソコンの中だけ」は、ウェブの閲覧と同じ場所にいるという意味でもあるのです。これはPrismorに限らず、手元で管理画面を開く多くの開発用の道具に共通する注意点です。

見張り役を黙って外されると、被害は二重になります。守っているつもりで、実際には守られていない状態が続くからです。しかも記録の画面には異常が出ない可能性があり、気づくのが遅れます。勧告に書かれているのはおそれであり、実際に悪用された事例があったかどうかは、2026年10月15日時点で一次情報からは確認できませんでした。

ほかに考えられるリスクも、推測であることを断ったうえで挙げておきます。すべての操作を記録する仕組みは、記録の保管場所が狙われれば、命令の出力や入力した指示がまとめて漏れるおそれがあります。また、AIのモデルとの通信を中継する使い方では、中継役が止まったり乗っ取られたりしたときの影響が大きくなる可能性があります。中継役が動いていないときにエージェントがどう振る舞うかは、説明文書では確認できませんでした。止まったときの動きは、導入前に自社の環境で確かめる必要があります。

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

Prismorのような守りの道具を検討するとき、機能の豊富さより先に確かめたい点があります。下の手順は、OSSを動かす前の段階で、資料と社内の取り決めで確かめられることに絞っています。

この手順の要は、道具を入れる前に、人が決めることを決めておくことです。守りの道具は、入れた後に設定を詰めようとすると、すでに開発の現場で使われていて止めにくくなります。検証は、本番の秘密情報や本番につながる経路から切り離した環境で行ってください。

企業が取るべき対策

Prismorを導入するかどうかにかかわらず、AIエージェントの実行時の守りについて、企業として決めておきたい対策を挙げます。一つ目は、守りの道具も含めて、版の更新を管理対象にすることです。開発者が個人の判断で入れた道具は、更新が漏れがちです。どの端末にどの版が入っているかを把握し、勧告が出たら速やかに更新できるようにしておきます。

二つ目は、手元で開く管理画面の扱いを社内の決まりに入れることです。今回の勧告のように、手元の窓口がウェブの閲覧から狙われる形は、ほかの道具でも起こりえます。管理用の窓口を使わないときは止める、管理画面を使う作業とふだんのウェブ閲覧を分ける、といった運用の決まりが考えられます。三つ目は、記録の扱いです。すべての操作が記録されるなら、記録の保管場所・見られる人・残す期間を、個人情報や秘密情報の扱いと同じ水準で決める必要があります。

四つ目は、規則の変更そのものを監視することです。規則が書き換えられたら誰かが気づける仕組み、たとえば規則の文書を変更の履歴が残る場所で管理し、変更のたびに人が確かめる運用が有効です。見張り役の設定が変わったことに気づけないなら、見張り役を置いた意味は半分になります。五つ目は、調達の段階での確認です。保守の体制、弱点の報告への対応の約束、OSS版と有償版の範囲を、導入前に書面で確かめておきます。

セキュリティの方針の文書には、報告を受けてから48時間以内に受領を返し、重大なものは7日以内、重大度が高・中のものは30日以内に修正版を出すと書かれています。こうした約束が文書で示されていること自体は評価できますが、約束が守られているかは、勧告の履歴を見て自社で判断するものです。今回の勧告では、修正版の公開と勧告の公開が同じ日でした。

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

Prismorは、AIの外側で規則に基づいて止める道具です。言い換えれば、何を止めるかを決めるのは人です。READMEには、言い換えで紛れ込む命令をAIに見分けさせる追加の検査もありますが、これも初期状態では止まっています。AIに判定を任せる部分を増やすほど、その判定がなぜそうなったかが分かりにくくなります。AIに判断させない部分を先に決め、AIに判定させるときは根拠を書かせて人が確かめるのが基本です。

やってはいけない向き合い方を挙げておきます。

• 守りの道具を入れたことで安心し、観察のまま何も止めずに運用を続ける
• 守りの道具の更新を開発者個人に任せ、勧告が出ても古い版を使い続ける
• 手元の管理画面を開いたまま、ふだんのウェブ閲覧を続ける
• すべての操作の記録に秘密情報が含まれうることを考えず、保管場所と見られる人を決めない
• AIに見分けさせる検査の判定を、根拠を確かめないまま最終判断にする
• 何にでも人の承認を求めて、承認する人が中身を読まずに押すようになる

裏を返せば、人が決める範囲ははっきりしています。どの規則を強制にするか、どの操作に承認を挟むか、規則の変更を誰が確かめるか、記録をどう守るか。この四つはAIにも道具にも委ねず、人が決めます。AIと道具に任せてよいのは、人が決めた規則の範囲で、速く広く見張る部分です。人が確認する範囲を先に決めておけば、守りの道具は心強い味方になります。

よくある質問：Prismorを入れればAIエージェントは安全になるのか

最も多いと思われる問いに答えておきます。Prismorを入れれば安全になるか、という問いへの答えは「それだけでは安全にならない」です。Prismorが見られるのは、つないだAIエージェントの道具の呼び出しです。つないでいないエージェントや、規則に書いていない動き、まだ知られていない手口は、見張りの外に残ります。初期状態は観察なので、規則を強制に移すまでは止める力もありません。

では入れる意味がないのかというと、そうではありません。AIが何をしたかの記録が残り、危ない操作を実行の前に止められる関所を持てることは、何もない状態より大きく前進します。大切なのは、道具を入れることを守りの完成ではなく、守りの設計の始まりと捉えることです。AIエージェントに任せる範囲、人が承認する範囲、記録の扱いを決めたうえで、その決めごとを実際に守らせる手段として使うのが本来の位置づけです。

もう一つ、「勧告が出た道具を使ってよいのか」という問いもありそうです。弱点が見つかること自体は、多くのソフトウェアで起きます。見るべきは、報告が非公開で受け付けられ、修正版が出て、勧告として公開されたかという対応の流れです。今回はその流れが確認できます。そのうえで、最新版を保てる体制を自社が持てるかどうかが、使ってよいかの分かれ目になります。

• Prismorの機能・対応範囲・ライセンス・版の情報は、GitHubのリポジトリと説明文書、PyPIの記録、公式サイトを2026年10月15日に確かめた範囲に基づきます。更新が活発なため、内容は変わる可能性があります
• セキュリティ勧告の内容は、2026年10月1日に公開された勧告の記載に基づきます。修正版でどこまで直ったかのコードの検証や、実際の悪用の有無の確認は行っていません
• 性能や防げる危険の比率などの数値は、開発元が自ら測ったものです。第三者による検証は確認できていません
• この記事は防御と評価の目線で書いています。導入・設定・起動の手順や、勧告の再現の方法は扱いません

まとめ

Prismorは、AIエージェントの道具の呼び出しを実行の前に規則と照らし、記録・人の承認・遮断を行う、自社の環境で動かすOSSです。複数のエージェントに同じ規則を当てられること、迷ったら止める側に倒す設計、改ざんに気づける記録は、企業の守りに役立つ要素です。一方で、初期状態は観察のみで、エージェントによっては人の承認が遮断に置き換わるなど、導入するだけで守られるわけではない点を押さえておく必要があります。

そして2026年10月1日の勧告は、守りの道具そのものの管理画面が、ウェブの閲覧という思わぬ経路から狙われうることを示しました。勧告は1.57.0で修正済みで、10月15日時点の最新版は1.61.0です。使うなら1.57.0以降、できれば最新版に限ります。使うなら最新版を保ち、管理画面と記録の扱いを決め、規則の変更を人が確かめる。どの規則で何を止め、どこに人の承認を挟むかを人が先に決めたうえで、その決めごとを守らせる手段として使うことが、AIエージェントの時代の守りの基本です。

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