MicrosoftのAgent Governance ToolkitとRynko Flowの位置づけ

マイクロソフトはついに Agent Governance Toolkit をオープンソース化しました。これは実行時ガバナンスプラットフォームで、OWASP Agentic Top 10 の全10リスクを網羅します。朝のうちにアーキテクチャ、ベンチマーク、OWASP のコンプライアンス関連文書を読んでおり、これはオープンソース／それ以外を問わず、これまで見てきた中で最も徹底したエージェント・ガバナンスフレームワークの一つです。

• 0.012ms のレイテンシでのポリシー評価。

• Ed25519 暗号学的エージェントIDと信頼スコア。

• キルスイッチを備えた4層実行リング。

• 信頼性のための回路ブレーカーとカオスエンジニアリング。

• LangChain、AutoGen、CrewAI、Google ADK などを含む12種以上のフレームワーク対応アダプター。

• 6,100 以上のテスト。MITライセンス。

これはエージェント系エコシステムが必死に必要としていたタイプの基盤で、Microsoft がそれを無料で提供することは、業界全体のスピードアップにつながります。

Rynko で私たちが掲げている賭けについても自信が高まります。なぜなら、このツールキットは、私たちが解決していない、真に難しい課題のセットを解決するからです — そして私たちが解決する特定の課題に余地を残してくれます。

ツールキットが得意とする点

ツールキットは四つのコンポーネントを持っており、それぞれがエージェント系システムを構築するチームが直面する実運用上の懸念に対応しています。

Agent OS はポリシーエンジンです。すべてのエージェント操作は実行前にこれを通ります。エージェントが呼び出せるツール、トークン予算のようなリソース制限、API 呼び出しの上限、コンテンツポリシーなどの機能を定義します。これをサブミリ秒のレイテンシで評価します ― 単一ルールで毎秒 72,000 件、100ルールのポリシーで毎秒 31,000 件。OPA/Rego または Cedar でカスタムポリシーを記述できるため、チームは新しい DSL を学習することなく、既存のポリシーインフラを再利用できる、思慮深い設計選択です。

AgentMesh はアイデンティティとエージェント間の信頼を扱います。すべてのエージェントは Ed25519 暗号認証情報を取得します。0–1000 のスケールでの信頼スコアは、エージェントが何をできるかを決定します。例: 900+ のスコアは検証済みパートナーアクセス、300 未満は読み取り専用。エージェント間の通信は信頼ゲートを通じて暗号化され、A2A、MCP、IATP プロトコルを橋渡しします。信頼スコアモデルは特に緻密に考えられており、例: 新規エージェントはデフォルトで 500 から開始し、適合履歴に基づいて進捗する、というのは新しいチームメンバーを、権限を段階的に拡大しながらオンボードする方法に似ています。

Agent Runtime は実行監督です。エージェントが触れるものを分離するために4つの権限リングを使用します。Saga オーケストレーションは多段階の操作を調整するために使われます。非準拠エージェントを終了させるキルスイッチと、追記専用の監査ログがすべてを記録し、法科学的再現のために利用されます。

Agent SRE は信頼性エンジニアリングを提供します。SLO の適用、エラーベジェット、回路ブレーカーは連鎖的故障を防ぎ、リプレイデバッグとカオスエンジニアリングを可能にします。Azure を大規模に運用するチームに期待される、プロダクションの可観測性パターンを備えています。

All four components work together to answer a fundamental question: is this agent allowed to do what it's trying to do, and is it doing it safely?

This is genuinely hard infrastructure to build correctly. Identity, policy enforcement, execution isolation, and reliability engineering each have deep rabbit holes, and Microsoft has the engineering depth to go down all of them properly.

Flow が補完的な層を加える場所

The toolkit governs agent behavior — permissions, identity, execution boundaries, reliability. Flow governs agent output i.e. the actual data the agent produces when it completes an action.

These are different concerns. The toolkit ensures the agent is authorized and operating safely. Flow ensures the data the agent produces is correct and hasn't been tampered with before reaching the downstream system.

One reasonable question to ask would be: couldn't AgentMesh's trust gates or the Agent OS policy engine handle data validation too? Technically, you could write OPA/Rego policies that inspect payload fields — Rego is expressive enough to check input.payload.amount > 0. But policy engines are designed to return allow/deny decisions, not structured validation errors with field-level messages that an agent can use to self-correct and resubmit. You'd also be mixing authorization concerns with domain-specific business logic in the same policy files. Also, you wouldn't get HMAC-based payload verification or human approval routing. It's a bit like using a firewall for input validation — it can inspect packet contents, but that doesn't make it the right layer for checking whether an invoice total matches its line items.

Think about the OWASP compliance mapping in the toolkit. ASI-05 addresses unexpected code execution through privilege rings and sandboxing. This makes sure that the agent can't run arbitrary code. That's the right control for that risk. But once the agent produces a result through an approved tool call - an invoice, a purchase order, a compliance report - there's a different question to answer: is the data in that result actually correct?

An agent can be fully authorized, properly authenticated, running within its privilege ring, with no circuit breaker tripped. The policy engine approved the action. And the agent still submits "currency": "usd" instead of "USD", calculates a total that's off by a rounding error, or drops a required field. These are domain-specific data quality issues that a behavioral governance layer isn't designed to catch, and honestly shouldn't try to, that would mix concerns and bloat the policy engine with domain logic.

This is what Flow was built for. You define a gate with a schema and business rules specific to your domain, and the agent's output gets validated before it reaches the downstream system. Validation Failures return structured errors which the agent can use to self-correct. Passed validations return a validation_id - an HMAC-SHA256 hash of the validated payload which the downstream system can independently verify.

二つのレイヤーがどのように連携するか

この区別は、従来のシステムにおけるセキュリティの考え方に対応します。認証と認可は、誰がリクエストを行っているか、許可されているかを教えます。入力検証は、彼らが送信しているデータが正しく整形され、正確であるかを伝えます。両方が常に必要でした。エージェント系の世界も同じです。

ツールキットは線の上の行を、Flowは線の下の行を処理します。二者は協奏して、パイプラインを端から端までカバーします。

実践的な例

ツールキットが展開された環境で注文処理エージェントが動作しているとします。ポリシーエンジンはエージェントが注文を提出する権限を持つことを確認します。AgentMesh がその身元を検証しました。ランタイム監督は、エージェントが自分の特権リング内で動作していることを確認しました。

エージェントはこの注文を提出します：

{
  "order_id": "ORD-2847",
  "vendor": "Acme Corp",
  "amount": -500,
  "currency": "usd",
  "line_items": []
}

ツールキットの視点では、すべて問題なく確認されました。エージェントは認可され、認証され、適切な範囲内で動作していました。ポリシーエンジンはそのアクションを承認しました。しかるべき理由で、それは承認されるべきです — ツールキットの任務は挙動の統治を確保することであり、ビジネスデータの検証ではありません。

Flow は、ツールキットが置き去りにしたところから引き継ぎます。適切なスキーマとルールを備えたゲートが3つの問題を検出します：

{
  "success": false,
  "errors": [
    { "field": "amount", "message": "Must be >= 0" },
    { "field": "currency", "message": "Must be one of: USD, EUR, GBP" },
    { "rule": "line_items.length > 0", "message": "Must have at least one line item" }
  ]
}

エージェントは、構造化されたフィードバックを用いて自己修正し、再提出します。成功時には validation_id を取得します。下流のシステムはデータを受け付ける前に ID を検証します。ツールキットは、正しいエージェントが注文を安全に提出したことを確認しました。Flow は、注文自体が正しいことを確認しました。

パフォーマンス — 両レイヤーは基本的に無料

ツールキットのベンチマークが強調する点の一つは、ガバナンスのオーバーヘッドはLLMの待機時間に対して見えない程度であるべきだということです。彼らのポリシー評価は 0.01–0.1ms を追加します。LLM API 呼び出しは 200–3,000ms かかります。私はこの点について、彼らはまさに正しいと考えます — ガバナンスはボトルネックになるべきではなく、その値では決してならないのです。

Flow は評価ごとにより多くの作業を行うため、評価のタイムスケールが異なります — ペイロードの解析、可変配列に対するスキーマ検証、再帰下降パーサを通じた式ベースのビジネスルールの実行。私たちのベンチマークは、エンタープライズ規模のペイロード（21 のスキーマ変数、10 のビジネスルール、1 ペイロードあたり 900 行のアイテム）に対して、サーバーサイド検証が約 50ms であることを示しています。典型的なペイロード（数KB）では、1 桁のミリ秒です。

併せて、両レイヤーは、LLM推論が 500–3,000ms かかったパイプラインに対して、およそ 50–60ms を追加します。行動ガバナンスと出力検証を合わせて実行することで、非常に negligible なコストになります。

大局的な視点

OWASP Agentic Top 10、AWS Agentic AI Security Scoping Matrix、Snapchat の Auton フレームワーク、そして今度は Microsoft のツールキットを経て、業界は私が重要だと考える方向へ収束しています：エージェント・ガバナンスは単一の問題・単一の解決策ではありません。パイプラインの異なる段階で異なるリスクに対処する、専門的に設計されたレイヤーのスタックです。

Microsoft がこのツールキットを公開することは、この分野で活動するすべての人に利益をもたらす形でカテゴリを検証しています。Azure を運用する企業が世界に向けて「エージェント・ガバナンスはインフラストラクチャです。こちらが私たちのリファレンス実装を無料で公開します」と言うとき、それは「エージェント・ガバナンスは必要ですか？」という議論から「まだ追加すべきレイヤーはどれですか？」という議論へと移動させます。

私たちは出力検証を、そのレイヤーの一つと考えています。ツールキットに何かを見逃したからではなく、ドメイン固有のデータ正確性は別個の課題であり、それ自体が専用のツールを要するからです。請求書に正しい通貨コードが含まれているか、注文の合計が行アイテムと一致するか、コンプライアンスレポートに全ての必須項目が含まれているかを確認することは、ポリシー評価の問題ではありません。これはスキーマとビジネスルールの問題であり、必要に応じて人間のレビューをループに組み込むことができます。

それが Flow を作った理由です。エージェント・ガバナンス・ツールキットを展開してパイプラインに出力検証を追加したい場合は、ガバナンス対象のエージェントと下流システムの間に Flow ゲート を配置してみてください。無料プランでは月に500回の検証実行と3つのゲートが提供されます — 実際に2つのレイヤーが協調して機能する様子を確認するのに十分です。

Rynko Flow は AI エージェントの出力を検証するゲートウェイです。 無料でお試し または ドキュメントを読む。