ガードレール / セキュリティ

LiteLLMモデルサービング

ライブラリとしては、1つの関数呼び出しで対応プロバイダのどれにでも、OpenAI形式のリクエストとレスポンスのまま到達できます。多くのチームが導入する理由は後者のゲートウェイのほうです。自己ホストのサーバーが、個別の予算と流量制限を持つ仮想キーを発行し、プロバイダの障害時には代替へ切り替え、複数の配備先へ負荷を分散し、キーごとの費用を記録します。代償として、リクエスト経路に自分で運用する構成要素が1つ増えます。またenterpriseディレクトリ配下のコードはMITの対象外です。

promptfoo可観測性

テストケースはYAMLです。プロンプト、いくつかの入力、そして出力に対する表明を書きます。それだけで、同じ入力に対して複数のプロンプトやモデルを並べた比較表が得られ、変更で品質が下がったときにビルドを失敗させられます。同じツールがアプリケーションへの攻撃も行い、敵対的な入力を生成して脆弱性やコンプライアンス上のリスクを洗い出します。ただし外側から、プロンプトを入れて回答を見る形で動きます。稼働中のエージェントのどの段階で問題が起きたかを知りたい場合、この道具は向きません。

SkillSpectorガードレール

スキルやMCPサーバーの導入は、ライブラリの追加よりブラウザ拡張の導入に近い行為です。届くのは指示とスクリプトであり、エージェントは自分の認証情報とファイルが手の届く範囲にある状態でそれに従いますが、事前に中身を読む人はほとんどいません。SkillSpectorはそれを読みます。リポジトリや書庫、ディレクトリを対象に、プロンプトインジェクション、データが本来と違う先へ送られる動き、権限の昇格、細工されたツール説明、供給網の危険といった観点の検出パターンで走査し、危険度と推奨対応を添えた指摘を返します。NVIDIAは、調査したスキルの26.1%に脆弱性、5.2%に悪意の疑いがあったとする研究を引いています。パターンによる走査が示すのは証明ではなく疑いなので、指摘を人が確認し、許容したものを記録していく運用が前提になります。

エージェントはチャットアプリよりはるかに多くモデルを呼ぶため、提供元のたまの流量制限が日常的な停止に変わります。Portkeyのゲートウェイは、自分のコードと提供元の間に入ってそれを吸収します。失敗した呼び出しは再試行し、制限に達した鍵は別の鍵に譲り、使えないモデルは次の候補に切り替わります。同じプロンプトはキャッシュから返せるため、二重に支払わずに済みます。振り分けの規則を書けば、分類には安いモデル、難しい処理には高いモデルというように送り先を変えられ、その判断がコード全体に散らばりません。遅延の増加は1ミリ秒未満、大きさは約122KBだとプロジェクトは述べています。機能を前提に設計する前に確認したい点が1つあります。資料はオープンなゲートウェイと同社のホスティング型製品をまとめて説明しています。

codex-securityガードレール

基本形は`npx @openai/codex-security scan .`で、結果のJSONはstdoutに出ます。`--mode deep`ではworkerとsubagentを並べ、新しい検出が出なくなるまで探索を続けます。再スキャン時は`scans compare BEFORE_SCAN_ID AFTER_SCAN_ID`が根本原因で前回と突き合わせ、new／persisting／reopened／resolved／unknownに分類するため、差分だけを追えます。ただし探索は既定で96時間まで回る長丁場であり、コミット前の軽量チェックには向きません。実行にはCodex Securityへのアクセスが前提で、一部のサイバーセキュリティ要求やprotected findingsはTrusted Access for Cyberの承認が必要になる点も、導入前に確認しておきたいところです。

cloudflare-os実行環境

Cloudflare OSは、エージェントとの対話と、そのエージェントが書き上げる小型アプリ（Gadget）を同じ画面に載せた業務環境です。Gadgetのサーバー側はインターネット接続を無効化したDynamic Worker、クライアント側はサンドボックス化したiframeで動き、両者の通信はpostMessage経由のCap'n Web RPCに限られます。外部サービスへは利用者が明示的に「紹介」したリソースだけにGatekeeper経由で到達し、副作用のある操作はいったん模擬結果を返してエージェントを止めずに進ませ、実行そのものは後からまとめて承認・却下できます。ただし設計はWorkers固有の機能に深く依存しており、ワークスペースはDurable Object、GadgetはDynamic WorkerのFacetとして動きます。自前サーバーのworkerdへ載せる手順はREADMEでもCOMING SOONのままで、実質的な選択肢はCloudflareアカウントへのデプロイになります。2026年8月時点のv2は開発元自身がearly accessと位置づけているうえ、Gatekeeper側にも接続先ごとの設定が必要なものが多く、サービスによってはOAuthクライアント資格情報の取得が必要です。

garakガードレール

チャットボットやモデルに向けると、プロンプトインジェクション、脱獄、符号化による回避、データ漏洩と再現、有害表現、誤った推論といった攻撃の系統を順に試し、どれが通ってしまったかを報告します。攻撃、判定、対象への接続を別々の部品として保つ設計により、新しいプローブや新しいバックエンドを、他を書き換えずに追加できます。担うのはセキュリティの発見側であって修正側ではありません。出力が示すのは、どのプローブが成功したかであり、それに対してどんな方針を書くべきかではありません。

NeMo Guardrailsガードレール

多くのガードレール製品は1か所で1つのことを検査します。こちらは介入点を5つ定義します。モデルが要求を見る前、検索が取り込んだ内容、会話の流れ、ツール呼び出しの周囲、そして応答が利用者に届く前です。アプリケーションとモデルの間に位置するため、既に稼働中のシステムに、どちら側も変えずに後付けできます。代償はレイテンシと語彙です。強力な制御のいくつかはそれ自体がモデル呼び出しであり、対話の規則はColangという専用言語で記述します。

Agent Governance Toolkitガードレール

エージェントが持つ権限は、渡した認証情報が持つ権限であって、本来許してよい範囲とはほとんど一致しません。表を読める鍵はたいてい表を消せます。このツールキットは、その差を呼び出しの地点で埋めます。規則はYAMLで書きます。破壊的な操作は拒否する、メール送信は指定した担当者の承認を必須にする、といった内容です。ツールの関数を包めば、呼び出しのたびに規則が評価され、監査記録に残り、規則に触れる場合は理由を添えて拒否されます。あわせて、ある操作をどのエージェントが行ったかを特定するための識別の仕組みと、自分のプロセスで動かしたくないツールのための隔離実行が用意されています。公開プレビュー段階で、パッケージ構成はすでに一度変わっています。

Giskardガードレール

評価で分かるのは、自分が思いついた質問に対する出来です。安全性についてはそれでは形が合いません。問題になるのは、思いつかなかった質問のほうだからです。Giskardはそこを反転させます。スキャンが敵対的な入力を自ら生成し、拒否すべきだったのに答えてしまったものを報告するため、試験項目は想像力ではなくツールが用意します。あわせて、検索を使う仕組みが静かに壊れていく典型的な形を調べるスキャンと、期待する振る舞いを通常のテストとして書き、pytestで合否を出す仕組みがあります。一度気になった確認事項を、変更のたびに走る確認に変えられます。開発元は、指摘ゼロが安全性や法令遵守の保証ではないと明記しています。

agentgatewayガードレール

エージェントと、その呼び出し先——モデルプロバイダ、MCPサーバー、他のエージェント——の間に置くRust製のデータプレーンです。認証、RBAC、レート制限、OpenTelemetryへの送出をエージェントごとに実装せず、ここで一度だけ設定します。Solo.ioが2025年8月にLinux Foundationへ寄贈し、2026年6月にはMCPやgooseと同じAgentic AI Foundationの傘下へ移りました。ただしリクエスト経路上に置く基盤としては歴史が浅く、下流のMCPサーバーへ利用者ごとの識別情報を引き渡す仕組みは未対応の課題として残っているため、必要な認証方式を先に確認してください。

Inspect AIベンチマーク

この分類の他の項目がそれぞれ1つの計測であるのに対し、これは計測を作るための機構です。データセットが入力と正解を与え、ソルバーが応答を生成し、スコアラーが正誤を判定し、タスクがこの3つを束ねます。ソルバーは単一のモデル呼び出しでも、多ターンのエージェント全体でも構いません。200を超える既製の評価が同梱され、モデルが書いたコードはサンドボックス内で実行され、ログビューアで各サンプルの実際の経過を確認できます。できないのは、何を測る価値があるかを教えてくれることです。

numbatガードレール

デスクトップ・CLI・IDE・ゲートウェイの各エージェントの動きをhookやplugin、OTLP/HTTPのログエクスポータ経由で取り込み、単一のイベントモデルへ正規化したうえでローカルのCELルールで評価し、events・findings・enforcement決定をバージョン付きNDJSONとして書き出します。`numbat scan`はディスク上のセッション成果物を読むため、事前に計装していなかった過去の作業も後から再構成できます。一方で遮断は保守的な設計で、enforceモードは既定で無効、同梱ルールはすべて監視専用なので、実際に止めるにはルールYAMLを運用側のディレクトリへ複製し、idを保ったままenforce: trueを追加してversionを上げる手順が必要です。観測できる範囲はエージェントとサーフェスごとにcoverage matrixで決まり、永続化されなかった活動は後から復元できず、findingsは実行された事実の証明ではなくルールの一致にすぎません。網羅的な記録や確定的な事実認定を期待する用途には向きません。