ルールとして作成
各ルールは条件(例:amountUsd >= 5000)と効果 — allow、deny、require_approval — および優先度で構成されます。再デプロイは不要で、ルールはランタイムが実行ごとに読み取る、テナントにスコープされたデータです。
Policy-as-Code
出荷前にテストできるルールで、AI エージェントをガバナンスする。
allow、deny、require_approval のルールを一箇所で作成し、あらゆる判断を本番反映前にシミュレートし、すべての変更をゴールデンポリシーテスト群でゲートします。ルールの編集が、エージェントに許可された範囲を静かに変えてしまうことはありません。
deny > require_approval > allow · リリース前にシミュレーション · ゴールデンテストがすべての変更をゲート
Policy Studio
# cortex_policy_rules · priority order · deny > require_approval > allow
rule "high-value-payout" {
priority: 10
when: amountUsd >= 5000
effect: require_approval
}
rule "export-pii" {
priority: 5
when: action == "export" && pii == true
effect: deny
}
simulate ▸ POST /v1/governance/simulate
require_approval
allow
trace ▸ high-value-payout に一致 · 理由: amountUsd >= 5000
governance ▸ リリース前にシミュレーション · ゴールデンテストがすべての変更をゲート
自分で書けるガバナンス
ポリシーは設定であり、コードのデプロイではない。
Cortex のガバナンスは、優先度付きのルール群です。各ルールは条件と、allow・deny・require_approval のいずれかの効果を持ちます。ランタイムは実行のたびに優先度順で評価し、常に最も制限の強い効果が優先されます:deny は require_approval に、require_approval は allow に勝ります。ルールはデータであるため、リスク・コンプライアンス部門が直接作成・変更でき、すべての変更はエージェントに届く前にテストできます。
最も厳格なものが優先
ルールは優先度順に適用され、無効なルールはスキップされ、一致したものの中で最も厳格な効果が優先されます:deny > require_approval > allow。ガバナンスの既定は許可ではなく、常に慎重側です。
リリース前にシミュレーション
任意のコンテキストを稼働中のルール — または未保存の候補セット — に通すと、判定とルール単位のトレースが返るため、保存する前にどのルールがなぜ発火したかを正確に確認できます。
ゲートとしてテスト
ゴールデンポリシーテストは、維持すべき判定を固定します。候補ルールセットに対して実行し、1件でも失敗すればリリースすべきでないと分かります — ガバナンス自体のリグレッションゲートです。
解決する課題
テストされないポリシー変更は、エージェントの権限を静かに書き換える。
ガバナンスが散在する if 文とプロンプト文言の中にあると、善意のルール変更が、すべてのエージェントの権限を静かに広げてしまうことがあります — そして気づくのは監査のときです。Policy-as-Code はルールを明示的なデータにし、リリース前に判断をプレビューでき、ゴールデンケースを1件でも壊す変更は受け付けません。稼働中の判断とシミュレーションは同じエンジンで動くため、テストした内容がそのまま実行されます。
保存前に任意のコンテキストをシミュレーション → 判定とルール単位のトレースdeny > require_approval > allow — 最も厳格な効果が優先ゴールデンテストが1件失敗 → 候補ルールセットはリリースされない
仕組み
作成し、シミュレートし、テストし、出荷する。
純粋な単一エンジン — evaluateRules(rules, context) — が、すべての実行とすべてのシミュレーションを判断します。この共通経路こそが、シミュレーションを信頼できるものにします。プレビューと本番の判断は、同じコードで行われます。
- 01
ルールを作成
条件と効果 — allow、deny、require_approval — を優先度とともに記述します。優先度の小さいものから評価され、無効なルールはスキップされます。ルールはデプロイではなく、テナントにスコープされたデータです。
- 02
リリース前にシミュレーション
稼働中のルール、または未保存の候補セットに対して、コンテキストを /simulate に POST します。効果、一致したルール、理由、ルール単位の完全なトレースが返るため、変更が本番になる前にプレビューできます。
- 03
ゴールデンテストを実行
既知のケースをゴールデンテストとして固定します(コンテキスト → 期待される効果)。候補ルールセットに対して実行し、1件でも失敗すればリグレッションです — リリースしないでください。
- 04
ゲートの下でリリース
候補セットが合格すると、それが稼働ポリシーになります — アイデンティティ、予算、trust ledger と並んで、同じフェイルクローズのランタイム内で実行ごとに評価されます。
ポリシーの位置づけ
ポリシーゲートは、実行における一つの関門。
エンジンの中身
ルール、シミュレーション、テスト、そしてそれらをつなぐトレース。
ルール作成
- allow / deny / require_approval
- 条件＋優先度
- ルール単位で有効・無効
- テナント単位、再デプロイ不要
- SDK から CRUD + deleteRule
評価エンジン
- 純粋関数 evaluateRules(rules, context)
- 優先度順、小さい値から
- deny > require_approval > allow
- 無効なルールはスキップ
- 同じエンジンで本番とシミュレーション
シミュレーション
- POST /simulate { context }
- 稼働ルール、または候補セット
- effect と matchedRule を返す
- ルール単位のトレースと理由
- 未保存の変更をプレビュー
ゴールデンポリシーテスト
- context → expectEffect
- ケースの作成・一覧・削除
- POST /tests/run → passed/total
- 候補セットに対して実行
- リリース前の回帰ゲート
トレースと証跡
- 各ルールの一致・スキップを記録
- 判断の理由
- 一致したルールを特定
- GET /counts → rules, tests
- 監査人が読める出力
ランタイムの下限
- アクションの requiresApproval は引き続き適用
- 高リスクのアクションは別途保留
- ポリシーは厳格化のみ、緩和は不可
- 他のゲートと並んでフェイルクローズ
- 変更操作はコンソール側で管理者限定
主張するのではなく、証明する
同じルール、2つのコンテキスト、2つの誠実な判断。
amountUsd >= 5000 に require_approval のルールを固定して、シミュレートします。$7,400 の支払いは require_approval を返し、一致したルールと理由がトレースに残ります。$100 の支払いは、一致するルールがないため allow を返します。推測は不要です — シミュレーションは、本番をゲートしているのとまったく同じエンジンで動きます。
- { amountUsd: 7400 } をシミュレーション → require_approval
- { amountUsd: 100 } をシミュレーション → allow
- pii: true の export → deny（最も厳格なものが優先）
- すべてのシミュレーションが、一致したルール・理由・ルール単位のトレースを返す
ゴールデンポリシーテスト
POST /v1/governance/tests/run { candidateRules: […] } ▸ 3 / 4 件合格
big-payout-needs-approval
{ amountUsd: 9000 } · 期待値 require_approval
合格small-payout-allowed
{ amountUsd: 100 } · 期待値 allow
合格pii-export-denied
{ action: export, pii: true } · 期待値 deny
合格refund-under-cap-allowed
{ amountUsd: 240 } · 期待値 allow · 実際 deny
不合格tests ▸ 1件失敗 → 候補ルールセットはリリースされない（回帰ゲート）
3効果:allow · require_approval · deny
$7,400シミュレーション → require_approval($5,000 以上のルール)
$100シミュレーション → allow(一致するルールなし)
1ゴールデンテストの失敗がルール変更をブロック
Policy Studio
# cortex_policy_rules · priority order · deny > require_approval > allow
rule "high-value-payout" {
priority: 10
when: amountUsd >= 5000
effect: require_approval
}
rule "export-pii" {
priority: 5
when: action == "export" && pii == true
effect: deny
}
simulate ▸ POST /v1/governance/simulate
require_approval
allow
trace ▸ high-value-payout に一致 · 理由: amountUsd >= 5000
governance ▸ リリース前にシミュレーション · ゴールデンテストがすべての変更をゲート
回帰ゲートとしてのゴールデンテスト
ルール変更を、エージェントに届く前に検証する。
候補となるルールセットを /tests/run に送ると、Cortex は何も保存せずに、すべてのゴールデンケースをそのルールセットで評価します。単純にすべてを拒否する候補は、allow を期待するケースで失敗します — ゲートが、出荷すべきでないと教えてくれるのです。重要な判断を一度固定しておけば、以後の編集がそれを静かに変えることはできません。run エンドポイントは、変更のたびに実行する手動ゲートです。
- candidateRules セットに対してゴールデンテストを実行 — 何も保存されない
- 結果は { total, passed, failed, results[] }
- すべてを拒否する候補は allow のケースで失敗 → リリースしない
- 重要な判断は、今後のあらゆる編集に対して固定される
ランタイムの他の要素と連携
ポリシー単体では強制しない — 強制するのはランタイム。
Policy-as-Code は、アイデンティティ、アクション、オーバーサイト、台帳と同じフェイルクローズ・ランタイムにおける一つのゲートです。各スポークをたどってご確認ください。
Action Fabric
ルールが require_approval を返すと、アクションは承認インボックスに入ります — 管理者が承認するまで pending_approval のままで、自動実行されることはありません。
監督モード
5つの自律モードが、エージェントが単独でどこまで実行できるかを定めます — リスクゲートは下限であり、ポリシーは厳しくはできても緩めることはできません。
Trust Ledger
すべてのポリシー判定は、署名付きでオフライン検証可能なレシートとともに、ハッシュチェーン化された改ざん検知可能な監査証跡に記録されます。
Agent IAM
エージェントは許可リスト化されたモデルとアクションを持つ統制されたアイデンティティです — ポリシーは実行ごとに、アイデンティティはエージェントごとに決めます。
オントロジー
オブジェクト・プロパティ・アクションの権限により、ポリシー条件は単なる生のフィールドではなく、実際の業務上の意味に基づいて評価できます。
Control Tower
ルール数とテスト数の実数が KPI と CSV 行として表示され、ポリシー資産全体の状態を1か所で監視・エクスポートできます。
セキュリティとコンプライアンス
エンタープライズのセキュリティレビューを前提に設計。
既定は拒否の評価、最も制限の強いルールが優先される優先順位、管理者ゲート付きのルール変更、そしてすべての判断に付くルール単位のトレース — 監査人がすでに用いるフレームワークにマッピングされています。
SOC 2ISO 27001ISO 42001HIPAAGDPREU AI ActNIST AI RMFFINRA
ルールは一度書く。証明は、毎回行う。
エージェントのガバナンスを、テスト可能でシミュレート可能なポリシーに落とし込む — ルールの変更が、エージェントに許可された範囲を静かに変えることはなくなります。