Seal

seal

公開レジスター： Retry-Safety Index には、回答を受け取れなかった場合に一度だけ支払うエージェント決済の実装が掲載されています。安全性の検証済み、問題の発見と修正（修正までの時間を含む）、検証を受ける方法を確認できます。各項目には証拠へのリンクがあります。

エージェントがあなたの承認なしで支出する権限を得られます。

Seal は Coherence とは異なります

Seal と EffectFence は、取り消せないアクションが実行中に二度発火するのを防ぎます。資金移動に対するランタイムの強制です。Coherence はランタイムには一切触れず、実行後に記録を読み、エージェントが主張したことを、証明したことと照らし合わせて評価します。防止と証明。 解決する問題も、コードも異なり、重複はありません。

無料： 資金を移動するクライアント、ファシリテーター、SDK、ツールキットを、ご自身のものでも他者のものでもご提出ください。内容を確認し、Retry-Safety Index に無料で判定結果を公開します。調査結果には、その仕組み、ファイルと行番号、失敗するテストが含まれます。修正がリリースされるまでは、名前を公表せずに件数のみを掲載します。評価を申請 →

Seal は MCP サーバー（seal-mcp、stdio、JSON-RPC 2.0）であり、Python ライブラリでもあります。MCP ホストに、取り消せないアクションを 一度だけ実行するための12 個のツールを提供します。seal_propose、seal_execute、seal_paths（ゲートウェイ モードでは、エージェントが使い捨てチケットを保持し、プロバイダーのキーは保持しません）、さらに seal_admit、seal_commit、seal_abort、seal_heartbeat、seal_get、 seal_verify、seal_incident_receipt、seal_expect、seal_obligations があります。

docker run -i ghcr.io/aurumflux20/seal          # or: python -m seal.mcp_server

環境変数がない状態で、イントロスペクション専用モードとして起動します。データベースがなくても initialize と tools/list に応答するため、ホストやレジストリーのプローブはすぐに接続できます。 アクションを実際に受け付けるには、SEAL_DSN に Postgres の DSN を設定します。ゲートウェイモードには SEAL_EXECUTORS=your.module を設定します。

// claude_desktop_config.json
{ "mcpServers": { "seal": { "command": "python", "args": ["-m", "seal.mcp_server"],
                            "env": { "SEAL_DSN": "postgres://..." } } } }

エンジニアではありませんか？ 代わりに docs/PLAIN-ENGLISH.md をお読みください。 専門用語を使わずに同じ内容を説明しており、できないことも含まれています。

他の製品が提供するのはロックです。一度設定したらそのままの支出上限です。 この上限は学習しないため、問題なく決済を一万件完了したエージェントも、今日インストールしたばかりのエージェントと同じ信頼度しか得られません。そして、あなたは何度も「承認」をクリックし続けます。

Seal が提供するのはアンロックです。決済経路が実際に証明してきたこと――プロバイダーが確認した決済や、裏で資金が動いていないことを示すスイープ――を読み取り、その経路が獲得した自律性を算出します。L0 OBSERVED → L5 AUTONOMOUS。 レベルを手入力する人はいません。

████████············  L2 ASSISTED      50 proven · 100% confirmed   [human required]
     fifty settlements — but volume alone is not trust.
████████████········  L3 DELEGATED     50 proven · 100% confirmed   [unattended]
     one clean sweep later: the human stops clicking Approve.
····················  L0 OBSERVED      50 proven · 100% confirmed   [SUSPENDED]
     one charge the gateway never admitted. fifty clean ones don't outweigh it.

SEAL_DSN="..." python3 license_demo.py     # watch a path earn L3 and lose it

0.4.0 以降、ライセンスはダッシュボードに表示されるだけでなく、制御を担います。 獲得した自律性を有効にすると、Gateway(seal, earned_autonomy=True)、または MCP サーバーの場合は SEAL_EARNED_AUTONOMY=1 を設定します。ゲートウェイは、オペレーターが設定した上限を超えない範囲で、経路自身の記録が獲得したレベル（L3 以上）に応じてのみ、その経路が人の介在なしに資金を移動できるようにします。すぐに人の判断に切り替わるのは、次の 3 つの場合です。まだ自律性を獲得していない経路、一時停止（ゲートウェイの裏で資金が移動した場合）、そして保留です。保留は、実行がプロバイダーに到達したものの結果が不明な状態です。プロバイダーに何が起きたかを settle() が問い合わせるまで、経路は停止します。状況が判明すると、保留は自動的に解除されます。人は同じメーカー・チェッカーの手順（tier=LICENCE）で、個々のアクションを引き続き承認できます。デフォルトではオフのため、有効にするまでは何も変わりません。

エージェントが顧客に二重請求しないことを証明できますか？ 3段階の評価を1本のはしごにまとめた、書面のみのサービスです。創設記念の適合性テスト（300ドル） — お客様の実装に一連のテストを実施し、結果をインデックスに公開します（先着3件のみ。 予約） · アテステーションテスト（1,200ドル） — お客様の稼働中エンドポイントに対して、あらゆる曖昧な結果を検証し、署名済みの結果を提示します。所見は5営業日以内に、問題のないテスト結果は24時間以内に署名します （予約） · 固定スコープの 決済経路レビュー（12,000ドル） — 本番環境の決済経路を1つ調査、テストし、7～10日で証明します。お客様が運用する経路で実際の二重実行が確認されなければ、請求は発生しません。まず無料でセルフチェックするには、 hostile-facilitatorを使えば、60秒で結果が分かります。

実績を積むには時間がかかりますが、失うのは一瞬です。それこそが、実績を意味あるものにする唯一の形です。レベルの定義全体については、docs/AUTONOMY-LEVELS.mdをご覧ください。

Sealの曖昧な結果に関する原則 — 「判定できなかった」は終端状態であり、未発生ではない — は、私たちが共同執筆したドラフト版MCPリトライ安全性提案の§4.3に採用されました。テストスイートには、私たちの適合性テストセットが使われています。

その基盤：厳密な一度限りの受付

異なる2台のマシンで動く2つのエージェントが、同時に注文123への請求を決定したとします。プロセス内の冪等性では防げません。ガードは両方のエージェントが参照するストアに置き、勝者をそこでアトミックに決める必要があります。

Sealはその役割を担うレイヤーです。Postgresを1つ、インテントごとに1行、勝者は1つです。

INSERT ... ON CONFLICT DO NOTHING     -- one row, one winner, no check-then-act window

受け付けられたすべてのアクションは、証明書で終わります。インテント＋引数のダイジェスト＋結果のダイジェスト＋前の証明書のハッシュをもとにした、コンテンツアドレス方式のハッシュです。証明書を編集、削除、並べ替えると、それ以降のすべてのハッシュが破損します。DSNを持つ人なら誰でも、ネットワーク接続も私たちへの信頼も必要とせずに検証できます。

SEAL_DSN="..." python3 -m seal verify
# chain VERIFIED — 41 cert(s), every link intact   (exit 0; broken chain → exit 1)

証明

この主張は、敵対的な条件でテストされています。1つのバリアで一斉に解放された1,000個の実スレッドを、1つの共有Postgresに対して実行し、「請求」では測定用カウンターを増加させます。2つの呼び出し元が実行されれば、カウンターが2を示してテストが明確に失敗します。

4回連続で実行した結果は、ACTUAL_EXECUTIONS = 1。敗者は全員、封印済みの証明書を再生するか、実行中に処理を停止するか、ストアに到達できない場合に安全側に失敗しました。封印後に50個の呼び出し元を同時に実行した場合も、全員が再生し、再実行はありませんでした。正直な制限も含む詳しい数値は、STORM-PROOF.mdをご覧ください。

ご自身で実行するには、次のとおりです。

pip install seal-kernel

export SEAL_DSN="host=... dbname=seal"
python3 -m seal verify          # chain check, no network, no trust in us

1,000スレッドのストーム証明を自分で実行するには、リポジトリをクローンしてください（ハーネスはwheelではなくソースに含まれています）。

# Needs Python 3.10+. macOS ships 3.9 with pip 21, which fails an editable
# install with a misleading "setup.py not found" error — use a venv rather
# than debugging that.
git clone https://github.com/aurumflux20/seal && cd seal
python3 -m venv .venv && source .venv/bin/activate
python3 -m pip install -U pip && python3 -m pip install -e .

export SEAL_DSN="host=... dbname=seal"
python3 storm.py --n 1000

私たちのサーバーだけでなく、ご自身のサーバーをテスト

上記のハーネスを一般化した、リポジトリに一切依存しないスタンドアロンファイルです。コピーして、ご自身の書き込みを行うツールに接続し、自分で確かめてください。

python3 range_safety_test.py --n 1000

実際のテストを実行する前に、既知の安全でないターゲットと安全なターゲットの両方に対してテストを実演するため、合格結果に意味があります。このテストの初期バージョンが、修正されるまでの間に私たちを誤らせた3つの方法も含む詳しい説明は、docs/RANGE-SAFETY-TEST.mdをご覧ください。

使用方法

from seal import Seal

seal = Seal(dsn); seal.setup()

adm = seal.admit("charge", {"order_id": "123", "amount": 4900})
if adm.fresh:                     # you won — run the effect, then seal it
    result = stripe_charge(...)
    cert = seal.seal(adm.intent, adm.fence, result)
elif adm.cert is not None:        # already done — here is the receipt
    return adm.cert
else:                             # someone else is mid-flight — stand down
    raise InFlight()

取り消し不能な処理が何も起きる前にエフェクトが失敗した場合は、再試行が正当なものとなるよう、クレームを解放します：seal.fail(adm.intent, adm.fence, reason)。

ホルダーがエフェクトの途中で停止した場合（インテントが未完了のままリースが期限切れになった場合）、次の admit() は新しいクレームを発行しません。期限切れになったからといって、ホルダーがプロバイダーの応答前にクラッシュしたのか、低速なプロバイダー呼び出しの最中なのかはわからないため、再実行すると結果が不明な状態で処理することになります。これはSealが決して行わないと約束している唯一のことです。fresh=False, cert=None, reason="lease expired with no witness…" が返されます。証拠で解決してください（Gateway.register_witness または seal.settle(intent, witness)）。エフェクトが反映されていればレコードを修復し、反映されていなければ解放します。Seal(dsn, blind_reclaim=True) を使うと、構造上冪等なプロバイダー向けに従来の引き継ぎ動作が復元されます。ゲートウェイはプロバイダー呼び出しの間、リースのハートビートを送信するため、Stripeへの呼び出しが遅くてもクレームは失われず、維持されます。

ワールドの確認 — モックではなく、稼働中のStripeで測定

「一度だけ受け付けた」と示す証明書は、こちら側についての主張です。次に確認すべきなのは、Stripe（またはResend、あるいは銀行のWebhook）が実際に記録した内容です。その答えがこちら側の記録と食い違うこともあります。

export SEAL_DSN="host=... dbname=..."
export STRIPE_TEST_KEY="sk_test_..."   # your own test-mode key, Dashboard -> API keys
python3 stripe_demo.py

モックを使わず、実際のStripeテストアカウントで次のことを行います。

1. 2つのエージェントが同じ請求を同時に実行します。 Sealが一方だけを受け付けます。 実際に作成される PaymentIntent は1つだけです。
2. 証拠がStripeに問い合わせます： 「このインテントを持つ請求はいくつありますか？」 Stripeが1つと回答すると、証明書は WORLD_FINAL に昇格します。
3. ゲートウェイを介さずに不正な請求が作成されます — ローカルのフェンスだけでは防げない事象です。証拠が再度問い合わせると、Stripeは2つと回答します。証明書は WORLD_DIVERGED になり、ドメインは凍結され、そのドメインへの追加支出は自動的に拒否されます。

稼働環境での実行から得られた率直な知見が2つあり、どちらも修正済みでテストされています。Stripeの検索インデックスには結果整合性があり、新しい請求が表示されるまでに実際に数秒かかることがあります。そのため証拠は確定的な回答が得られるまでポーリングし、「まだインデックスに登録されていない」空の検索結果を、権威ある不在の記録として扱うことはありません。また、ワールドが台帳と矛盾した後は、その後の不安定な再集計によって証明書がひそかに WORLD_FINAL に格下げされてはなりません。設計上、乖離は維持されます。

コミット前のワールド凍結 — すでに変化した事実に基づいて処理しない

admit() はこれまでも read_set（カートの合計や在庫数など、判断の根拠となるワールドの事実）を受け取り、証明書に保存していました。しかし、これまでは何も確認されていませんでした。古さの保護があると思っていた呼び出し元には、実際には何の保護もありませんでした。これは、その日の早い時間に上位レイヤーで修正されたバグと同じ種類の欠陥です。スキーマにガードはあっても、適用されていませんでした。

from seal.freshness import CallableChecker

fresh = CallableChecker(lambda rs: current_cart_total(rs["order_id"]) == rs["total"])

adm = seal.admit("charge", {"amount": 5000}, key="order-777",
                 read_set={"order_id": "777", "total": 5000}, checker=fresh)
# StaleWorldRead is raised BEFORE a fence is granted if the checker says no —
# nothing runs on facts that already changed. Gateway.propose() takes the
# same read_set/checker kwargs and passes them straight through.

適用するタイミングは意図的に、フェンスの前、つまりエフェクトの実行後ではなく前です。実行後に確認しても、成功を主張することを拒否できるだけです。古い情報に基づいて資金が動くことは止められません。それこそが、この機能で防ごうとしている実際の問題です。この機能はオプトインで、後方互換性があります。このライブラリ全体の他の部分と同様、呼び出し元が read_set と checker の両方を指定した場合にのみ有効になります。適用される箇所に明記している正直な制限として、checkerの呼び出しをadmissionのINSERTとアトミックにすることはできません。そのため、そのわずかな隙間に変更が反映される可能性は残ります。これは、証拠が参照するプロバイダーのインデックスに結果整合性があることと、同じ種類の注意点です。

Clearance — 宣言するものではなく、獲得しなければならない権限

フェンスは、あるアクションが一度実行されたことを証明します。Clearance はその上位のレイヤーで、企業が実際に必要とするものです。つまり、どのツールパスをエージェントが 無人で 実行できるのか、またその根拠は何かということです。

from seal.clearance import Clearance, CLEARED

cl = Clearance(seal)
cl.set_policy("charge", CLEARED)                       # an operator's intent
cl.record_proof("charge", green=True, storm_n=1000, executions=1)  # from CI

cl.status("charge")["effective"]   # CLEARED — but only because both are true

これを単なる切り替えではなくするルールは、CLEARED は宣言するものではなく、獲得するものです。 オペレーターがパスを設定し、かつ十分最近のグリーンなストーム証明が記録されている場合に限り、そのパスは実質的に CLEARED と報告されます。最後の証明がレッドになったり、古くなったりすれば、status() は自動的に HOLD を報告します。誰かが忘れずにダウングレードする必要はありません。REVOKED は常に優先され、自動的に復旧することはありません。また、revoke_all() はすべての既知のパスを要所で停止するスイッチです。range_report() は、集計したイベントとプロバイダーが出典を示した証明書をエクスポートします。セキュリティ質問票や CFO が実際に目を通す成果物です。

Exclusive Authority — エージェントに渡すのはチケットであり、認証情報ではありません

Clearance はポリシーです。エージェントが sk_live 自体をまだ保持しているなら、ポリシーを回避できてしまいます。それは安全策ではなく、単なる提案です。Exclusive Authority は認証情報をエージェントから完全に取り除きます。

from seal.authority import Gateway

gw = Gateway(seal)
gw.register_executor("charge", lambda args: stripe_charge(args))  # secret lives HERE only

prop = gw.propose("charge", {"amount": 4900}, key="order-777")
if prop["status"] == "cleared":
    result = gw.execute(prop["ticket"], {"amount": 4900})  # gateway calls Stripe, not the agent

エージェントが propose() を呼び出すと、チケットが返されます。これは意図が受け付けられ、許可され、予算が割り当てられた証明であり、秘密情報ではありません。プロバイダーが呼び出されるのは execute() のみで、チケットは許可された正確な引数に紐付けられます。execute() に渡した内容が提案された内容と一致しなければ拒否され、チケットは一度しか使えず、有効期限もあります。（初期版では引数を署名に紐付けていなかったため、$1で許可されたチケットを任意の金額に使えてしまう状態でした。これはリリース後ではなく、リリース前に自分たちのビルドを攻撃して発見しました。）

保管モデルを明確に説明します。 ゲートウェイは お客様自身のインフラストラクチャ内で 実行されます。AurumFlux がプロバイダーのシークレットを保持、閲覧、転送することはありません。鍵をエージェントの手から取り上げるソフトウェアを提供するのであり、私たち自身が保管庫になるわけではありません。限界についても率直にお伝えします。同じホスト上でゲートウェイ自身の環境変数を読み取れるプロセスは、依然としてシークレットを盗むことができます。これによりハードルは「保管庫から盗む」まで上がりますが、物理的に不可能になるわけではありません。

Graduated Clearance — 重要な金額に対する作成者・承認者分離

$5 の API 呼び出しなら、二者択一の CLEARED で十分です。しかし、財務部門が $50,000 の支払いに承認を出す際に求めるのはそれではありません。求めるのは職務分掌です。支出を提案した人物が、その記録上、承認者になることはありません。Graduated Clearance は Clearance にしきい値を追加します。

from seal.graduated import GraduatedClearance, APPROVE

gc = GraduatedClearance(seal)
gc.set_thresholds("payout", auto_ceiling=100, dual_ceiling=10_000, required_approvers=2)

# amount 50   -> AUTO, ordinary Clearance applies
# amount 5000 -> DUAL, needs 2 distinct human approvals before it can execute
r = gc.request("payout", 5000, maker="alice", intent=intent)
gc.add_vote(r["id"], "bob", APPROVE)
gc.add_vote(r["id"], "carol", APPROVE)   # now APPROVED — a THIRD person, not alice

ゲートウェイに組み込まれています。しきい値が設定されたパスで Gateway.propose(..., amount=X) を実行すると、承認済みの approval_id が渡されるまでは、チケットの代わりに {"status": "needs_approval", "tier": "DUAL"} が返されます。作成者自身による承認は、ポリシーではなくコードで強制的に禁止されます。また、正当な同時実行の競合が発生しても、同じ承認者が二重にカウントされることはありません。アプリケーションレベルのチェックではなく、(approval, approver) に対する Postgres の UNIQUE 制約で防止しています。一度でも拒否されれば、その承認は終了します。承認によって認められる実行は正確に1回だけで、承認が求められた正確な意図に紐付けられます。承認または拒否と、すべての投票を含む、決定済みの承認はすべて、実行証明と同じハッシュチェーンに追記されます。そのため seal verify では、実際に実行された内容と同様に、ガバナンス上の決定も検証されます。

設計上、後方互換性があります。set_thresholds() が実行されていないパスでは、propose() に金額が渡されても、Graduated Clearance は発動しません。既存の予算のみを使うインテグレーションに影響はありません。

支払いプロバイダーは不要で、請求も発生しません。全体の流れを最初から最後まで実行できます。

python3 approval_demo.py

$200 の購入は自動的に許可され、$12,000 の支出は 別々の 2人の人間が承認するまで拒否されます。申請者が自分の申請を承認しようとしても拒否され、同じ承認者による重複投票も拒否されます。一度でも拒否されれば終了し、$250,000 が自動承認されることはありません。また、revoke を1回実行するだけで、$200 のパスさえ停止します。最後に Range Report が生成されます。このレポートではイベント種別の件数ではなく、承認済みと拒否済みの合計額という金額で承認状況が示されます。

ポータブルなレシート — 建物の外にも持ち出せる証拠

重要な争いには、エージェントを承認したユーザー、それを実行した運用者、支払いを受け取った加盟店という三者が関わります。それぞれが、ほかの二者には読めないデータベースを持っています。seal verify は「この実行は正確に一度だけ行われ、世界によって確認されたか？」に答えますが、その答えを得られるのは DSN を持つ人だけです。つまり、自分の潔白を証明するよう求められている当事者だけです。

ポータブルなレシートとは、その答えをファイルにしたものです。証明書は書き込み時に RFC 8785 canonical JSON に基づいてハッシュ化され、キーが設定されている場合は Ed25519 で署名されます。そのため、相手方はデータベースもネットワークも、私たちのコードも使わずに検証できます。Node の約 30 行のコードで検証する docs/verify-receipt.mjs をご覧ください。

pip install 'seal-kernel[signing]'
python -m seal keygen                     # SEAL_SIGNING_KEY= secret · public key= publish it
python -m seal export --intent <id> > receipt.json
python -m seal verify-receipt receipt.json --pubkey <hex>    # needs NO DSN
node docs/verify-receipt.mjs receipt.json <hex>              # or no Python at all

判定そのものに関する正直な限界：固定したキーによる検証に成功すれば、これらの証明書がキーの保持者によって生成され、改変されていないことは証明できますが、完全性は証明できません（ほかの証明書が存在するかどうかは、ストアとのチェーンチェックが必要です）。キーを固定しない検証で証明できるのは内部整合性のみで、作成者は証明できません。署名はオプトインです。署名なしのストアも従来どおり動作し、v1 証明書は v2 と並行して今後も検証できます。

settle() — 重複排除は決済ではありません

冪等性キーを使うと、同じリクエストを安全に再試行できます。しかし、プロバイダーがすでに処理していた可能性があるタイムアウトの後に何が起きたかは分かりません。その意図は open のまま残り、settle() が導入される前は、将来どこかの呼び出し元が行うかもしれない admit(heal_with=…) に暗黙の解決を委ねるしかありませんでした。今では、これを一つの動詞で実行できます。

gateway.settle(intent)      # uses the path's registered witness
# CONFIRMED_ONE → healed to WORLD_FINAL, budget reservation settled
# ABSENT        → claim released for a clean retry, budget returned
# MULTIPLE      → WORLD_DIVERGED on the chain, domain frozen
# UNKNOWN       → unresolved, loudly — the claim stands, nothing is guessed

義務 — エージェントが実行しなかったことを知らせるアラーム

上記のすべてのガードも、私たちが知るすべてのエージェント安全性ツールも、作為を監視します。二重請求、使いすぎ、矛盾などです。不作為を監視するものはありません。クラッシュした、キーを失った、あるいはひそかに停止したエージェントは、給与の支払いが行われなくなるまで、または 14 日以内に法的に行うべき返金がひそかに実行されなくなるまで、何もすることがないエージェントとまったく同じように見えます。

このリポジトリでは、すでにテストにおいてこの失敗パターンを許容しません（conftest.py：すべてがスキップされた実行は成功ではありません）。義務は同じ考え方を、本番環境の資金に適用します。これは照合スイープの双対です。

reconcile:    provider effects − admitted intents = out-of-band  (did too much)
obligations:  declared duties  − sealed intents   = BREACH       (did too little)

from seal.obligation import Obligations
obs = Obligations(seal); obs.setup()

# at decision time, the agent binds its future self:
obs.expect(action="refund", key="return-123", due_in_sec=14*86400,
           description="statutory refund window for return #123")

# the business heartbeat:
obs.expect_recurring(action="renewal", every_sec=86400, min_count=1)

obs.sweep()   # or: python -m seal obligations   (exit 1 on any open breach)

未達を単なるダッシュボードの行にとどめない仕組み：違反そのものが改ざん検知可能なチェーンに追記されます（削除すると、それ以降のすべてのハッシュが壊れます）。また、obligation_breached はライセンスを停止するイベントです。宣言した作業を実行しない経路は、二重請求をした経路と同じく、獲得した自律性を失います。義務の宣言はエージェントが行えます（MCP 経由の seal_expect）。一方、義務の取り消しは運用者が行う操作であり、エージェント向けツールはありません。エージェントが取り消せる義務は、義務ではないからです。違反しても、意図的に経路を凍結することはありません。凍結された返金経路では、未実施の返金を解決できないからです。利用できる手段は、証拠、アラーム、ライセンスです。

Seal 証明書が主張すること、しないこと

証明書は、そのアクションがこのゲートウェイで正確に一度だけ承認されたことと、記録された結果がその後改変されていないことを証明します。外部の世界で決済が完了したことは証明しません。すべての v1 証明書には、意図的かつ永久に world: "unconfirmed" が含まれます。「これは一度だけ承認した」と「Stripe が資金を受け取った」は別の主張です。この二つを混同することこそ、このツールが防ごうとしているバグの種類です。世界での確認（Stripe または利用するプロバイダーの記録と照合してこのフィールドを更新するプロバイダーアダプター）は次のレイヤーです。証明書スキーマにはすでにこのフィールドが含まれているため、フォーマットが壊れることはありません。

once-kernel、effectfence、coherence との関係

once-kernel は、1 つの プロセスでエフェクトが 2 回実行されなかったことを証明します。effectfence は 1 つの MCP サーバーを保護します。Seal は両者の上位に位置する、プロセス間レイヤーです。エージェントが 1 台のマシンを超えて動くようになったときに使います。無料のプリミティブは、今後もずっと無料のままです （Apache-2.0 / MIT）。

エージェントの PR と CI における主張と証明済みの事実（言ったこと ≠ 示したこと）については、 別プロジェクトの coherence をご覧ください。 このリポジトリには含まれません。パッケージも Git 履歴も異なります。

ライセンス

Business Source License 1.1：内容を読み、実行し、内部で本番環境に使用できます （商用利用を含む）。ただし、ホスト型サービスとして再販売することはできません。 2030-08-12 に Apache-2.0 に切り替わります。

---

mcp-name: io.github.aurumflux20/seal