Open Secure AI Alliance とは何か - NVIDIA主導のAIエージェント防御連合とオープンソース化された NOOA

2026年7月27日、NVIDIA が Open Secure AI Alliance（OSAIA） の発足を発表しました。オープンなモデル・ハーネス・ツールを「防御側の資産」として整備し、AIエージェントを守るための共通基盤を業界横断で作る、という趣旨の連合です。同日、Linux Foundation と Red Hat も参加表明のブログを出しています。

あわせて NVIDIA は、エージェントハーネスの研究フレームワーク NOOA（NVIDIA Labs Object-Oriented Agent） を GitHub で公開しました。ライセンスは Apache 2.0 です。

当ブログではプロンプトインジェクションが RCE になる構図や、AWS Kiro の CVE-2026-10591のように「エージェントの穴」を個別事件として追ってきました。今回はその逆方向、穴を塞ぐ側の共通規格を作ろうという動きです。この記事では、一次ソースで確認できた事実だけを積み上げて、何が発表され、何がまだ決まっていないのかを整理します。

何が発表されたのか

まず事実関係を押さえます。

NVIDIA の公式ブログは、連合の位置づけをこう説明しています。Linux Foundation の Akrites イニシアチブと OpenSSF のコミュニティ活動の上に乗る形で、オープンな技術を使って脆弱性の修正と開示を進める、というものです。つまり完全な新設というより、既存のオープンソースセキュリティ基盤への「AIエージェント向けの積み増し」という性格が強いです。

参加社数の「37社」はどこから来た数字か

報道では「37社の連合」という表現をよく見かけます。ただ、ここは注意が必要です。

• NVIDIA 公式ブログ本文が列挙している団体名を数えると、NVIDIA を含めて52団体でした（当方カウント）。Adobe、Box、Cadence、Capital One、Cisco、Cloudera、Cloudflare、Cognition、CrowdStrike、Crusoe、Databricks、Dell Technologies、DoorDash、Elastic、F5、Factory AI、Fortinet、G42、GitHub、HPE、Hugging Face、IBM、LangChain、Linux Foundation、Microsoft、Mistral、NAVER、NetApp、Nokia、Nous Research、OpenClaw、Palantir、Palo Alto Networks、Perplexity、Red Hat、Reflection AI、Salesforce、SAP、ServiceNow、Siemens、SK Telecom、Snowflake、SpacexAI、Synopsys、Thinking Machines Lab、TrendAI、Uber、Upwind、vLLM、WWT、Zscaler が並んでいます。
• 一方、Linux Foundation 側のブログが列挙している団体を数えると37団体になります。The Hacker News の「37-member」という見出しは、この短いリストと一致します。

なお、Meta は OSAIA の列挙リストには入っていません。Meta が名を連ねたのは、その前週に出たオープンウェイトモデルに関する業界公開書簡のほうです。ここは混同しやすいので分けて理解しておくとよいです。

なぜ今か: Hugging Face のインシデントが突きつけたもの

NVIDIA と Linux Foundation の両方が、根拠として同じ事件に言及しています。2026年7月中旬に Hugging Face が公表したセキュリティインシデントです。

公開されたインシデント報告によれば、経緯はこうです。悪意あるデータセットが2つのコード実行脆弱性を突いてデータ処理ワーカーに初期侵入し、そこからノードレベルの権限へ昇格、認証情報を収集して内部クラスタへ横展開しました。そして重要なのは、この攻撃が端から端まで自律的なAIエージェントシステムによって駆動されていたと報告されている点です。攻撃側の行動は数千件に及びました。

問題はその後のフォレンジックで起きます。攻撃コマンドやエクスプロイトのペイロードそのものを解析にかけようとしたところ、商用フロンティアモデルの安全ガードレールにリクエストをブロックされたとされています。ガードレールは攻撃者と防御側インシデント対応者を区別できません。

最終的に Hugging Face は、オープンウェイトモデルの GLM 5.2 を自社インフラ上で動かし、17,000件を超える攻撃者イベントを解析して攻撃タイムラインを再構成しました。通常なら数日かかる作業が数時間で完了し、しかも攻撃データも認証情報も自社環境の外に出なかった、と報告されています。

NVIDIA のブログはここから、次の一文を引き出しています。

防御側が自らのインフラ上で高度なAIを検査し、適応させ、実行できないとき、その対応能力は、速度が最も重要な瞬間にこそ制約される。

「オープンモデルが必要な理由」を、思想ではなく実際のインシデント対応の詰まりどころから説明している点が、今回の発表の説得力の中心です。

AIエージェントの攻撃面はどこにあるのか

Alliance のスコープを理解するには、先に「エージェントのどこが危ないのか」を整理しておくのが早いです。NVIDIA も Linux Foundation も、揃って同じ前提を強調しています。AIエージェントは言語モデルそのものではなく、モデル・ハーネス・ガードレールから成る複合システムである、という前提です。

実際の攻撃面は、モデルの外側に広く散らばっています。

• プロンプトインジェクション: 入力に紛れた指示がモデルの行動を書き換える。Web ページ、ドキュメント、ツールの説明文（description）、他のエージェントの出力など、経路はいくらでもあります
• ツール権限: モデルが呼べる関数の集合が、そのまま攻撃者の到達範囲になります。ファイル書き込みやコマンド実行を1つ渡した時点で、注入は実行に化けます
• サプライチェーン: エージェントが引く依存パッケージ、MCP サーバー、スキル定義。npm のインストールスクリプト既定オフ化のような動きは、この層の話です
• モデルファイル: 重みファイルの形式自体が任意コード実行を許すことがあります。Python の pickle 系形式が典型でした
• 監査可能性: 事故が起きたあとに「エージェントが何を見て、何を判断し、何を実行したか」を再構成できるか。ここが弱いと、そもそも被害範囲の確定ができません

Alliance が掲げるスコープは、この5つの層に素直に対応しています。

Alliance のスコープを分解する

NVIDIA のブログは、エージェントスタックの構成要素として identity、permissions、harnesses、guardrails、logs、evaluation を挙げ、さらに「identity と isolation から、安全なモデル形式、マルチモデルスキャン、セキュアコーディングワークフローまで」の防御スタックを構築中だと述べています。それぞれ何が問題で、何が持ち寄られているのかを見ていきます。

identity: エージェントは「誰」なのか

人間のユーザーには ID があり、サービスにはサービスアカウントがあります。ではエージェントは何者でしょうか。ユーザーの権限を借りているのか、独立した主体なのか。多くの実装では前者で、結果としてエージェントは人間と同じ権限で動く匿名の代理人になっています。乗っ取られたときに「誰がやったか」を切り分けられません。

ここで持ち寄られたのが HPE の SPIFFE/SPIRE への貢献です。SPIFFE はワークロードに暗号的に検証可能な ID を発行するゼロトラスト ID の標準で、認可されたワークロードだけが通信し企業リソースにアクセスできるようにする、というのが狙いです。エージェントを「ワークロード」として ID 付与の対象に含める、という発想です。

permissions: 何をしてよいかを、どこで決めるか

権限をプロンプトで指定するのは、境界を作ったことになりません。プロンプトはデータであり、データは注入されます。必要なのはプロンプトの外側にある権限モデルです。どのツールを、どのスコープで、どの承認フローの下で呼べるのか。MCP の認可仕様の議論も、まさにこの層を埋めようとするものです（MCP 2026 ロードマップ）。

isolation: 壊れた前提で、何を守るか

権限を絞っても、コードを実行させる以上どこかで破れます。そのとき何が守られるかを決めるのが隔離です。コンテナ、VM、専用の実行サンドボックス。NVIDIA は関連プロジェクトとして OpenShell というセキュアランタイムを持っており、NOOA のドキュメントも実行の隔離をこれに委ねる前提で書かれています。

guardrails: 検証は防御であって、境界ではない

入出力のフィルタ、危険操作の検知、ポリシー違反のブロック。有用ですが、これらは多層防御の一枚であって、突破不能な壁ではありません。この区別は後述する NOOA の README で、かなり率直に書かれています。

logs と evaluation: 事後に何が言えるか

エージェントの実行ログは、単なるアプリケーションログでは足りません。どのモデルに、どのコンテキストを渡し、どのツールをどの引数で呼び、何が返り、それがどの意思決定に影響したか。この粒度がないと、インシデント後の説明責任も、回帰テストも成立しません。EU AI Act の高リスクAI要件が監査ログ保持を求めているのも同じ理由です。

model formats: 重みファイルを開くだけで負ける形式をやめる

Hugging Face は Safetensors を PyTorch Foundation に提供しました。Safetensors はモデル重みを安全に保存する形式で、透明性とリモートコード実行が起きないことの保証を提供する、と説明されています。「モデルをダウンロードして読み込む」という日常操作が任意コード実行になり得た状況を、形式のレベルで潰す取り組みです。

model scanning: エージェントで脆弱性を探す

Microsoft の MDASH は、マルチモデルのエージェント型スキャンハーネスです。専門化した複数のAIエージェントを束ね、バグを発見し、議論させ、実際に悪用可能であることを証明させる、という構成が説明されています。攻撃側がAIで自動化するなら防御側も、という発想の具体例です。

secure coding workflow: 見つけた後に、直せるか

IBM と Red Hat の Lightwell は、デジタル署名付きのパッチでオープンソースサプライチェーンにセキュリティを届ける取り組みです。Red Hat のブログでは、自動化された脆弱性発見と、安定した修正配布をセットにすると位置づけられています。SpaceXAI はターミナルベースのコーディングエージェント Grok Build をオープンソース化し、Grok 系モデルの重み公開も計画していると NVIDIA のブログに記載されています。

NOOA とは何か

ここからが技術者にとっての本題です。NOOA は NVIDIA Labs Object-Oriented Agent の略で、モデル非依存の Python フレームワークです。

確認できた事実を先に並べます。

バージョン番号が v0.0.6 であること、GitHub Releases が0件であることからも分かるとおり、プロダクション向けの安定版ではなくリサーチプレビューです。NVIDIA 自身も開発者ブログで「オープンソースのリサーチプレビュー」と表現しています。

設計思想: エージェントは Python オブジェクトである

NOOA の主張は明快です。多くのエージェントフレームワークはプロンプトテンプレート、ツールスキーマ、コールバック、ワークフローグラフを別々の抽象として持ちますが、NOOA はそれらを1つの Python クラスに畳むという選択をしました。

from nooa import Agent
 
class SupportAgent(Agent):
    """You are a support agent."""
 
    # 状態はオブジェクトに置く。フィールドは型付き。
    order_db: OrderDB
 
    # 通常のメソッド。ただの Python。
    def is_refund_eligible(self, order: Order) -> bool:
        return order.delivered and order.days_since_delivery <= 30
 
    # エージェントメソッド: ランタイムが LLM に渡す。
    async def triage(self, message: str, order: Order) -> Ticket:
        """Create a typed support ticket."""
        ...

対応関係はこうなります。

論文（arXiv 2607.20709）では、typed input/output、live object への参照渡し、code as action、programmable loop engineering、explicit object state、model-callable harness API という6つのモデル向け設計要素を、単一のインターフェース上で初めて組み合わせたと主張しています。評価は SWE-bench Verified、Terminal-Bench 2.0、ARC-AGI-3 で実施されたと記載されています。

セキュリティ的に重要なのはトレースのほう

Alliance の文脈で NOOA が「AI安全性の機能をエージェントハーネスにとって利用しやすくする」と説明されている理由は、性能ではなくトレーサビリティにあります。

README によれば、すべての LLM 呼び出し、コード実行、メソッド呼び出しが既定でトレースされ、オーケストレータ・生成メソッド・ヘルパーにまたがって親子スパンの関係が保持されます。付属の CLI にはトレースビューアが同梱されており、ローカルで実行結果を追えます。

uv run nooa start-dev        # ブラウザでトレースを確認

ビューアが起動していない場合はトレースが黙って無効になるだけ、という設計になっています。エージェントの挙動を「テストし、トレースし、監査し、統治できる」ようにする、という Alliance 側の説明は、この部分を指しています。

率直な安全上の注記が、この記事で一番重要かもしれない

NOOA の README には、フレームワークの宣伝としてはかなり踏み込んだ注意書きがあります。要旨はこうです。

• NOOA は研究用ソフトウェアであり、エージェントは LLM が生成したコードを実行するように構成できる
• 生成コードは、私的データの外部送信・ファイル削除・環境の改変といった危険な行動を取り得る
• NOOA は生成コードに対して AST 検査を行い、モジュールの deny-list を適用する
• ただしこれらは多層防御のガードレールであって、封じ込め境界ではない
• Python に対する静的チェッカーはその保証を与えられない。open() は任意のファイルアクセスを与え、importlib はパスから直接モジュールを読み込め、リフレクションが残りに手を伸ばす
• 封じ込め境界は OS レベルの隔離である。コンテナ、VM、あるいは OpenShell のようなサンドボックスの中で必ず動かすこと。プロセス内バリデータだけに依存してはならない

これは、当ブログがエージェントのRCE事例で紹介した「LLM はセキュリティ境界ではない」という原則の、フレームワーク提供者自身による言い換えです。ベンダーがここまで明示的に「うちのガードレールは境界ではない」と書くのは、実務者にとってはむしろ信頼できる態度だと思います。

確認できなかったこと

正直に書いておきます。

• NOOA が Alliance の共同ガバナンス下に置かれるのかは未確認です。現状は NVIDIA が保守し、外部からは Pull Request で貢献を受ける形と報じられています
• Alliance 自体の憲章、理事会、技術ワークストリーム、リリース計画、共有リポジトリは、確認できた範囲では公開されていません。The Hacker News もこの点を指摘しています
• 「NOOA が Alliance の標準実装になる」といった記述は、一次ソースには見当たりませんでした

つまり現時点の OSAIA は、意思表明と初期コード提供のフェーズであり、標準化団体としての実体はこれから、と理解するのが正確です。

既存の取り組みとの関係

OSAIA は既存の枠組みの上に重なる形で立ち上がっています。整理しておきます。

Akrites は2026年6月25日に Linux Foundation が発表したイニシアチブで、AWS、Anthropic、Chainguard、Cisco、Citi、Endor Labs、Ericsson、Google、IBM、JPMorganChase、Microsoft と GitHub、NVIDIA、OpenAI、RapidFort、Red Hat、Rust Foundation、Sonatype、Vodafone、Zscaler などが創設メンバーです。共有の Security Incident Response Team（SIRT）と、CVE / CVSS に基づく統一された協調的脆弱性開示（CVD）プロセスを持ち、保守者不在の重要プロジェクトに対する「最後の保守者（maintainer of last resort）」の役割も担うとされています。資金は Linux Foundation の Alpha-Omega ファンドがシードを提供しています。

構図としては、Akrites が「重要OSSの脆弱性を直す仕組み」、OpenSSF が「安全に作る仕組み」、OSAIA が「AIエージェント固有の防御スタック」という分担です。

政策面では、NVIDIA のブログが規制当局に対して明確な主張をしています。オープンなモデル・ハーネス・セキュリティツールを、AI およびサイバーセキュリティ政策における負債ではなく防御資産として認識すべきであり、オープンなフロンティアAIへの一律の制限は防御能力を弱め、少数のクローズドな提供者に権力と依存と脆弱性を集中させるリスクがある、という論旨です。

「オープンウェイトは防御側の資産」という主張と、その反論

Linux Foundation のブログは、オープンウェイトの意義を3点にまとめています。アクセスの拡大、競争の強化、利用者による制御の維持です。そして Jim Zemlin CEO のコメントとして、オープンソースが現代コンピューティングの背骨になったのは「誰もが自分の依存する技術を見て、改善し、守れるようにしたから」であり、AI にも同じ基盤が必要だ、と述べています。

同ブログの中核的な主張はこれです。

攻撃者が高度なAIを使う世界では、防御側も同等の能力を持つモデルにアクセスできる必要がある。新たな脅威を検知し、シミュレートし、理解し、対応するために。

さらに、政策上の対立軸を「オープン対クローズド」ではなく「透明かつ安全」対「不透明で未検証」に置き直すべきだ、と提案しています。

批判的に見ておくべき点

一方で、この主張を額面通り受け取るべきではない理由もいくつかあります。

第一に、オープンであることは安全であることを意味しません。これは NVIDIA 自身が認めています。公式ブログは「オープンモデルは、他のあらゆる強力な技術と同様に、セーフガードを弱める試みやサイバー攻撃への転用を含めて悪用され得る」と明記しています。Linux Foundation も「一度公開された重みは、いかなる開発者の制御も及ばず、改変版の追跡は困難になり得る」と書いています。両者の主張は「リスクがない」ではなく「リスクはクローズドでも消えない」という比較論であり、この違いは重要です。

第二に、透明性と悪用可能性はトレードオフの関係にあります。ガードレールを外したモデルが誰でも作れるという事実は変わりません。「防御側が使える」ことと「攻撃側が使える」ことは同時に成立します。Hugging Face の事例が示したのは「オープンモデルのほうが安全」ではなく、「クローズドモデルのガードレールがインシデント対応を阻害した」という別の問題です。前者の結論を後者から導くのは飛躍です。

第三に、参加各社の商業的動機を差し引いて読む必要があります。オープンウェイトモデルの普及は、自社インフラでの推論需要を生み、GPU の販売につながります。セキュリティベンダー各社にとっては、新しい防御領域の市場が立ち上がることを意味します。主張の正しさとは別に、誰が何を得るのかは見ておくべきです。

第四に、前述のとおりガバナンスの実体がまだありません。憲章もワークストリームも公開されていない段階では、これは「業界の意思表明」であり、標準ではありません。実務上の判断を OSAIA の存在に依存させるのは、現時点では早すぎます。

実務者が今日からできること

Alliance が標準を出すのを待つ必要はありません。スコープとして挙げられた項目は、すべて今日から自分のシステムに適用できるチェック項目です。

エージェントの権限を最小化する

• エージェントに公開しているツール（関数）を全部書き出す。「便利だから残している」ものを削る
• ファイル書き込み、コマンド実行、ネットワークアクセス、認証情報の読み取りは、それぞれ独立に必要性を問う
• 権限をプロンプトで指定していないか確認する。プロンプトは境界ではありません
• エージェント専用のサービスアカウントを切り、人間のユーザー権限を借りない設計にする。エンタープライズ向けのエージェント統制製品が揃って ID とライフサイクル管理から入っているのも同じ理由です

ツール実行をサンドボックスに入れる

• LLM が生成したコードを実行する経路があるなら、必ず OS レベルの隔離（コンテナ、VM、専用サンドボックス）の中で動かす
• AST 検査やモジュールの deny-list は多層防御の一枚として使い、それを封じ込め境界と呼ばない
• サンドボックスからの外向き通信を既定で拒否し、必要な宛先だけ許可する

ログと監査を設計する

• モデル名とバージョン、渡したコンテキスト、ツール呼び出しと引数、返り値、人間の承認履歴を記録する
• トレースに親子関係を持たせ、1つの依頼がどこまで波及したかを追えるようにする
• ログに認証情報や個人データが混入していないか、保存前に確認する
• 保持期間を決める。EU AI Act の高リスク要件に触れる可能性があるなら、法務と早めに握る

モデルファイルをスキャンする

• 外部から取得するモデル重みは Safetensors のような安全な形式を優先する
• pickle 系形式を読み込む処理が残っていないか、コードベースを検索する
• モデルの取得元と、ダウンロード後のハッシュ検証を運用に組み込む

依存とサプライチェーンを検証する

• エージェントが引く依存（パッケージ、MCP サーバー、スキル定義、プロンプトテンプレート）を棚卸しする
• ツールの description は攻撃経路です。外部由来のツール定義は差分を監視する
• インストールスクリプトの実行を既定で止める。ロックファイルを固定する
• 署名付きの配布物を優先する

検知する

• エージェントのホストで、想定外の子プロセス、想定外の外向き通信、永続化の痕跡を監視する
• 「このツールが乗っ取られたら何が起きるか」を、本番投入前に必ず1回通しで書き出す

まとめ

• 2026年7月27日、NVIDIA が Open Secure AI Alliance（OSAIA）の発足を発表。50社前後の規模で、Linux Foundation、Microsoft、IBM、Red Hat、Hugging Face、Cisco などが inaugural partner として名を連ねる
• スコープは identity / permissions / harnesses / guardrails / logs / evaluation と、モデル形式・マルチモデルスキャン・セキュアコーディングワークフロー。持ち寄られたものとして SPIFFE/SPIRE、Safetensors、Lightwell、MDASH、Grok Build が挙がっている
• 同時公開の NOOA は、エージェントを Python オブジェクトとして表現する研究フレームワーク。Apache 2.0、リポジトリは NVIDIA-NeMo/labs-OO-Agents、タグは v0.0.6 でリサーチプレビュー段階
• NOOA の価値はトレースにある。すべての LLM 呼び出し・コード実行・メソッド呼び出しが既定でトレースされ、親子スパンが保持される
• README は「AST検査と deny-list はガードレールであって封じ込め境界ではない。境界は OS レベルの隔離である」と明記。これは「LLM はセキュリティ境界ではない」の言い換え
• 発端は Hugging Face のインシデント。商用モデルのガードレールがフォレンジックを阻害し、オープンウェイトの GLM 5.2 を自社インフラで動かして17,000件超のイベントを解析した
• ただし憲章・ガバナンス・ワークストリームは未公開。現時点では標準ではなく業界の意思表明として読むべき
• 「オープン＝安全」ではない。NVIDIA も Linux Foundation も悪用リスクを認めており、主張は「クローズドでもリスクは消えない」という比較論

実務者にとっての結論はシンプルです。Alliance の成果物を待つ間も、やることは変わりません。エージェントの権限を絞り、実行を OS レベルで隔離し、何をしたかを追えるログを残す。今回の発表が価値あるものだとすれば、それは新しい何かを教えてくれたからではなく、業界の主要プレイヤーが揃って「そこが急所だ」と認めたことの記録だからです。

参考リンク

• Industry Leaders Unite in Open Secure AI Alliance for AI Safety and Security（NVIDIA公式ブログ）
• Open Models and Open Weights Are Foundational to Secure AI（Linux Foundation公式ブログ）
• Strengthening the open source defense layer: Red Hat joins NVIDIA's Open Secure AI Alliance（Red Hat公式ブログ）
• NVIDIA-NeMo/labs-OO-Agents（NOOA のリポジトリ）
• NVIDIA-labs OO Agents: Native Python Object-Oriented Agents（arXiv 2607.20709）
• Six Agent Harness Capabilities for Higher Model Performance（NVIDIA開発者ブログ）
• Security incident（Hugging Face のインシデント報告）
• Linux Foundation and Industry Leaders Launch Akrites（Linux Foundation プレスリリース）
• NVIDIA Forms 37-Member Open Secure AI Alliance and Open-Sources NOOA Framework（The Hacker News）
• SPIFFE / Safetensors / OpenSSF