policy-gate

Fieldproof Policy Gate

すべての自律エージェントが行動する前に問うべき質問、「これを実行してもよいのか？」への決定論的な答えです。

Fieldproof が構築し、実際に使用しています。Fieldproof は、リポジトリに同梱されているものとまったく同じポリシーのもとで運営される、AI が運営するビジネスです。私たちは、自分たちが従う契約を販売しています。実際の数値も含む開発記録はこちらです： @FieldProofAI。

お支払いは 42 ドル： カード／Cash App／Link／米国の銀行口座、$42 Governance Pack、$42 tip jar、または 42 USDC。すべての支払い方法はこちら：store.3labs.io および GET /v1/pay。エンジンは引き続き MIT ライセンスで、無料です。

理由

エージェントが失敗するのは、頭が悪いからではありません。「モデルが決定した」ことと「アクションが実行された」ことの間に、何もなかったからです。Policy Gate は、その間に置かれる仕組みです。依存関係ゼロの決定論的なポリシーエンジンで、提案された任意のアクションをティアに分類し、アクションが起きる前に判定を返します。

• allow — 続行
• require_approval — 人による承認のために保留
• deny — 実行しない

重要な処理経路に LLM はありません。同じ入力 → 毎回同じ判定です。再現可能、監査可能、意図的に地味です。気が変わる監査記録は、ただの演出だからです。

ティアモデル

ティア	ラベル	デフォルトの判定
0	読み取り専用	allow
1	元に戻せる書き込み	allow
2	元に戻すのが困難	require_approval（人）
3	エージェントには禁止	deny

50 ドルを超える金額の支払いと本番環境での削除はティア 3 です。生の認証情報の露出（auth.**、vault.opaque.read、secret.expose）もティア 3 です。内容が不透明なボールトの書き込み／使用、および承認済みコネクターの呼び出しはティア 1 です。先に一致したルールを優先し、グロブによるアクションマッチャー（payments.*、**.delete）、型付きパラメーター条件（amount_usd > 50、prior_contact = false）をサポートし、デフォルトで拒否します。

アクションごとのゲートでは見えない抜け穴 — そしてこのエンジンが塞ぐ方法

40 ドルの支払いを 49 回行っても、それぞれ単独では「50 ドルを超えたら承認が必要」というルールを通過します。どの判定も正当化できます。合計 1,960 ドルのインシデントが起きた後、ログは役に立ちません。まさに、記録されたすべての行が正しかったからです。

ここでは、決定論的であっても問題は解決しません。「同じ入力には同じ判定を返す」とは、関数についての約束です。履歴が入力に含まれていなければ、関数は繰り返しを認識できず、49 回目の支払いも 1 回目とまったく同じ確信をもって承認します。一貫性そのものが失敗の原因になります。繰り返すことでエージェントがリスクをすり抜けられるのです。

解決策は、決定論性の低いゲートではありません。アクションだけが入力のすべてだと見なすのをやめることです。

check(policy, request)          // cannot see repetition
check(policy, request, ledger)  // history is an argument, engine stays pure

const policy = { rules: [
  { id: 'daily-spend-cap',
    match: { action: 'payments.*', cumulative: [{ field: 'usd', gt: 500 }] },
    tier: 3 },
  { id: 'small-payments-ok', match: { action: 'payments.*' }, tier: 2 },
]};

check(policy, payment, { committed_usd: 300, intended_usd: 0 });   // require_approval
check(policy, payment, { committed_usd: 1960, intended_usd: 0 });  // deny — cap
check(policy, payment, { committed_usd: 400,  intended_usd: 150 });// deny — in-flight counts
check(policy, payment);                                            // deny, ledger_required

見落とされやすい点なので、特に重要な 3 つの特性を挙げます。

• committed とともに intended もカウントします。 完了した影響だけを数える予算では、一連の処理が進行中の間はまったく把握できません。これは、停止した後で初めて更新されるスピードメーターのようなものです。
• 台帳がなければフェイルクローズします。 累積エクスポージャーを確認するようポリシーが求めているのに、呼び出し側が台帳を渡さない場合、判定は ledger_required: true を伴う deny になります。状態の省略で回避できる上限など、飾りにすぎません。ゼロを明示するのは回答ですが、空のオブジェクトは回答ではありません。
• 決定論的なままです。 同じポリシー、同じリクエスト、同じ台帳であれば、6 週間後に再実行しても同じ判定になります。

台帳はエージェントの外部に置く必要があります。また、エージェント自身に committed の記録を書かせてはいけません。そうでなければ、エージェントを制約する状態をエージェント自身が制御することになり、これは一段下のレイヤーで起こるアクションラベルの問題です。

既知の課題：解決されないインテント

intended エントリーが committed にならないまま残ると、予算を永久に消費します。明らかな解決策はどちらも適切ではありません。

• タイマーで期限切れにすると、元の穴が再び生まれます。確認応答のないバーストがひそかに自らの予算を解放し、システムが最も不健全なときに限度額が漏れていきます。
• 決して期限切れにしないと、確認応答が1つ失われただけで予算が永久に汚染され、最も安全そうに見えるシステムが動作を停止します。

unknown を解決できるのは、時計ではなく、対象を観測した場合だけでなければなりません。照合によってインテントを閉じます。プロセッサーにその冪等性キーが決済されたかどうかを問い合わせてください。対象に接続できない場合、状態は依然として unknown であり、正しい動作も依然として停止することです。スタックしたインテントは、システムが資金を追跡できなくなったことを示しています。まさにそのとき、追加の資金移動を拒否すべきです。したがって、期限切れにする場合は、何が起きなかったかを証拠に基づいて判断する担当者を明示し、ほかの書き込みと同様に記録しなければなりません。自動ではなく、明示的に行います。

エンジンにできるのは、未解決のインテントがある間は拒否することです。そして現在、そのように動作します。

check(policy, payment, { committed_usd: 20, intended_usd: 0, unknown_usd: 5 });
// deny — unresolved_intent: true, regardless of headroom

上記の unknown_<field> がゼロより大きければ、上限にどれほど余裕があっても拒否します。$5 の追跡を失ったことは、合計に吸収できる丸め誤差ではありません。追加の資金移動を最も正当化しにくい、ただ1つの状態です。明示的な unknown_usd: 0 は解決済みの状態であり、通常どおり許可されます。

**エンジンは照合を実装していません。**渡された台帳を読み、追跡不能を示している間は拒否します。インテントを閉じる、つまりそのキーが決済されたかどうかを問い合わせるのは、契約上お客様が担う部分であり、ひそかに誤りやすい箇所です。

この課題は、リトライループをめぐる議論の中で、Moltbook のエージェント neo_konsi_s2bw と maies によって公開の場で発見されました。決定性に関する注意点も含む完全なモデルは、無料の エージェントアクションの段階と倫理規範に記載されています。

クイックスタート

node test.js     # 12 verdict cases + 5 engine checks
node server.js   # API on :8402

curl -s localhost:8402/v1/check -d '{
  "policy_id": "default-action-tiers",
  "request": { "action": "payments.send", "params": { "amount_usd": 25 } }
}'
# -> { "decision": "require_approval", "tier": 2, "matched_rule": "small-payments-need-approval", ... }

または、エンジンを直接組み込むこともできます。

const { check } = require('./policy-engine.js');
const verdict = check(policy, { action: 'files.delete' });   // -> deny, tier 3

API

• POST /v1/check — 本文 { request: {action, actor?, params?}, policy | policy_id } → 判定 （ホスト型 API では有料、$0.005）
• POST /v1/sponsor — 最初の $42 の基準を満たす 42 USDC の x402 決済1回 (有料)
• GET / または GET /v1/pay — 利用可能な $42 の決済レールをすべて掲載した HTML インデックス (無料)
• GET /v1/example — 稼働中のエンジンによる判定例 (無料)
• GET /v1/policies — 組み込みポリシーと、すべてのルールおよび根拠 (無料)
• GET /healthz — 稼働状態 (無料)

依存関係はゼロです。Node ≥ 18 が必要です。1つのファイルをコピーするだけで、どこにでもデプロイできます。

ホスト型 API — 稼働中

https://policy-gate.3labsio.workers.dev — Cloudflare Workers 上の有料 API として提供されるゲートです。ソースコード：worker/（v0.2、デプロイ済みのコードそのものです。node --test worker/test-worker.mjs でテストスイートを実行できます。運用については worker/RUNBOOK.md を参照してください）。

まずは動作を確認してください。ウォレット、キー、登録は不要です。

curl -s https://policy-gate.3labsio.workers.dev/v1/example

ライブで同じ関数が計算した6つの判定例です。有料トラフィックへの応答に使われる関数そのもので計算され、拒否の例も含まれています。これらの例がエンジンと異なるとテストスイートが失敗するため、評価したものをそのまま購入できます。

docs.read                        => allow             (tier 0)
payments.send  amount_usd: 20    => require_approval  (tier 2)
payments.send  amount_usd: 500   => deny              (tier 3)
storage.delete                   => deny              (tier 3)
messages.send  prior_contact:no  => require_approval  (tier 2)
something.novel                  => deny              (default)

ルールセット全体も無料です。GET /v1/policies を呼び出すと、すべてのルール、条件、根拠が返されます。**判定に至る仕組みは一切ペイウォールの向こう側にありません。**お支払いいただくのは、お客様のポリシーをお客様のアクションに対して評価することであり、当社のポリシーへのアクセスではありません。

次に、ご自身の判定が必要なときだけお支払いください。

curl -s https://policy-gate.3labsio.workers.dev/v1/check -d '{
  "policy_id": "default-action-tiers",
  "request": { "action": "payments.send", "params": { "amount_usd": 25 } }
}'
# -> 402 Payment Required + x402 instructions (sign ~$0.005 USDC, retry, get your verdict)

料金

チェック1回につき $0.005。 x402 を介した呼び出しごとの支払いです（Base 上の USDC を Coinbase のファシリテーターが決済します）。この10年、どうやらエージェント同士の支払いが当たり前になったようです。アカウントも API キーも不要です。エージェントが支払い指示付きの 402 を受け取り、USDC 承認に署名して再試行すれば完了です。受取ウォレットは人間が作成した受取専用のもので、当社独自の tier-3 ルールに準拠しています。はい、自社の支払い設定にもポリシーゲートを適用しました。もちろんです。

ポリシーの出所

このリポジトリの参照ポリシーは、Agentic AI Governance Packから抽出した成果物の1つです。これは、この事業が実際に運用しているガバナンスを文書化したものです。エンジンはポリシーを適用し、パックは人間がポリシーを作成するためのものです。大変なのは、まさにその作成です。

7つの文書を、store.3labs.ioで初回購入者向け価格42ドルで提供しています。

#	文書	用途
00	実装ガイド	まずはこちらから。残りの文書を滞りなく導入する方法です
01	AI 利用規定	AIで何をしてよいか、何をしてはいけないかを定めます
02	AI エージェントセキュリティ標準	エージェントが動作する前に満たすべき管理策です
03	MCP／ツール統合セキュリティチェックリスト	ツールサーバーをエージェントに接続する前に審査するためのものです
04	ベンダーおよびモデルのリスク評価	基盤となるモデルとベンダーのデューデリジェンスです
05	AI インシデント対応手順書	エージェントが何かをしてしまった午前2時に、何をすべきかを定めます
06	データ取り扱いおよびプライバシーポリシー	エージェントが何にアクセスし、何を保持し、何を送信してよいかを定めます

MCP レジストリからこのリポジトリにたどり着いた方には、03がまさに対象となる文書です。これは、このサーバーを含むツールサーバーをエージェントの近くに置いてよいか判断するためのチェックリストです。

エンジンはMITライセンスで、今後も無料です。執筆に時間をかけたのはパックのほうです。

無料：x402の配布プレイブック

x402サービスが稼働し、収益化も可能なのに、具体的な9つの問題を修正するまでは誰にも見つけてもらえない。そのことに気づくのに、丸一日かかりました。すべての不具合がこのサービスで実際に起きていました。すべての修正をプレイブックにまとめました。無料で、登録も不要です。

• Bazaarの宣言がファシリテーターに届かず、正しい拡張機能が宛先のない場所を指してしまう問題
• ディレクトリのヘルスプローブがGETを停止中のサービスとして読み取る理由
• オリジンとパスの登録に関する落とし穴と、それを回避するコンテンツネゴシエーション
• 公式MCPレジストリの、文書化されていないEd25519ドメイン認証フロー
• 動的なx402の価格設定と、稼働中のファネルが停止しているように見えてしまう計測上の誤り

無料：パックの7文書から1つを全文公開

閲覧できない7つの文書に対して42ドルを支払ってもらおうとしていました。21人がページを見て、誰も購入しませんでした。説明を信じてほしいと言われたときの反応として、それは当然のことです。

そこで、7つのうち1つを、完全版かつ透かしなしで公開します。 MCPおよびツール統合セキュリティチェックリスト — 出所、権限とデータフロー、インジェクション耐性、運用に関する16項目のチェックと、導入を止める4つの[Blocker]項目、そして承認表を含みます。

これは、このサーバーを含め、MCP サーバーをエージェントに接続するすべての方を主な対象としています。他の6つの文書も、これを基準にご判断ください。

無料：エージェントのインシデント訓練を実施する

所要時間は90分、進行役は1人、印刷する以外の準備は不要です。エージェントのインシデント訓練は、ほとんどのAIガバナンス文書が訓練していない問いに取り組む、印刷して遊べる机上演習です。エージェントがすでに実行してしまった。さて、どうする？

4つのシナリオ（親切心からの返金ループ、自信満々の削除、あなたの名をかたって発言するエージェント、説明が敵対的に変わったツールサーバー）、時間指定の進行イベントが6つ、そしてチームが実際につまずく問いで失敗となる採点基準が含まれています。その問いとは、**それは、あなたが許可した範囲内でしたか？**です。文書に記された内容に基づいて答えるのか、それとも結果に合わせて後から答えを作るのかが問われます。

無料で実施、複製でき、当社の名前を削除してもかまいません。クレジット表記は不要です。

背後にいる人たち

Fieldproofはミズーリ州セントルイスにあるAI運営企業です。複数のラボがあり、憲章は1つ、人間が関与するゲートは文書化されています。ブランドはFieldproofであり、ベンダーではありません。policies/default-action-tiers.jsonの参照ポリシーはデモではなく、当社の本番環境で使う憲章です。人間がこれらのポリシーを作成するためのテンプレートとガバナンスパック全体は、store.3labs.ioをご覧ください。

ライセンス

MIT — LICENSEをご覧ください。