要約

  • 2026年9月5日付のdraft-das-eu-ai-act-execution-enforcement-00は、Sangam Dasによる有効な個人Internet-Draftで、意図されたステータスはInformationalである。IETF標準、作業部会文書、法令適合の認定ではない。
  • 提案は、重大な操作を未発効のCandidate Actとして保持し、外部で決められた機械可読条件を検証し、当該操作だけに結び付く権限を発行して、最初の保護対象効果の直前にFinality Sinkが再検証する。
  • 第35節は、保護の性質が境界を介した効果にだけ成立すると述べる。Finality Sinkと並行する外部APIへの直行経路には、その保護が成立しない。
  • Python参照実装v0.1.0は、効果を書き込むAPIがsink内部に一つだけある局所モデルを示す。製品向けセキュリティや法的適合エンジンの証明ではない。
  • システムとして主張するには、効果面閉鎖レシートが必要だ。全経路、経路と方針の版、迂回可能な権限、例外、無効な権限で効果が出ないことを示す経路別試験を記録する。

認証より前に経路図を読む

草案は計算と権限を分ける。AIが送信、決済、公開、書き込み、作動を準備しても、それだけでは外部効果にならない。操作はCandidate Actとして固定され、主体、対象、目的、受取人、宛先、方針エポック、有効期限、指定sinkなどに結び付けられる。保護実行領域が条件を満たすと操作限定の権限が作られ、sinkがダイジェスト、署名、失効、期限、再利用、所持証明、現在状態を直前に確認する。

重要な区別である。正しく認証されたワークロードでも、生成できるすべての操作を許可されたわけではない。過去の承認は内容変更後の操作を許さない。事後ログは、事前の禁止と同義ではない。

ただし、第35節の図75はそれ以上に重要だ。AI Agentから一方はFinality Sinkへ、もう一方はdirect external APIへ分岐している。草案は後者についてfinality protectionを確立しないと明記する。sinkの検証に欠陥がなくても、迂回した操作は検証対象にならない。

通常のツールルーターだけが保護され、ベンダーSDKの直接資格情報が残っている場合を考えればよい。あるいは、公開APIは承認を求めるが、公開バケットへ直接書き込める場合。データベースproxyは制御されていても、緊急接続文字列が別にある場合。これは実在する障害の報告ではなく、保護単位をコンポーネントではなく効果面に置く理由である。

最小化するのは計算であり、証明ではない

この提案は、全トークン、全read、全packetをsinkへ送れとは言わない。対象は選択された重大な遷移である。読み取りだけの低リスク処理を従来経路に残す考え方は、過度な集中を避ける最小仕様として妥当だ。

一方、保護すると宣言した効果については、同じ効果を生む全経路を含める必要がある。選択するのは結果であって、都合のよいAPIではない。通常queueと非常用送信、アプリ経由のfile releaseとstorage policy、local gatewayと受取側commitは、それぞれ同じ効果へ至る別の道になり得る。

遠隔効果では観測点も問題になる。草案は、ローカルなら検証・権限消費・commitを一つのtransactionにできるが、任意のInternet requestが自動的にatomicになるわけではないとする。受取側sink、idempotency、transactional outbox、状態機械が必要な場合がある。試験はローカルのdenyで終えず、外部で最初に利用可能となる状態まで確認しなければならない。

v0.1.0が示すもの、示さないもの

参照packageはcanonical JSON、SHA-256、Ed25519、proof-of-possession、policy epoch、nonce、SQLiteによる局所消費を実装する。合成された顧客サポート例では、目的をmarketingへ差し替える試行を効果記録前に拒否する。

READMEは前提を隠していない。Non-Effective Stateは、効果記録APIがsink内に一つしかないことで表現される。実環境ではnetwork egress、database commit、payment submission、file export、tool invocationなどを同等に媒介しなければ、finalityの性質は成立しない。

したがって、これは閉じた局所モデルのrunning codeであり、未知の本番網の証明ではない。草案はproduction HSM、TEE attestation、distributed consensus、完全なPKI、formal verification、high availability、side-channel protection、完全なremote atomicity、conformity assessmentを提供しない。単一Python process内の論理分離は、process全体を管理できる者への暗号的隔離でもない。

効果面閉鎖レシート

レシートは製品名ではなく効果から始める。送金指図、public object、commit済み行、送信済みmessage、tool command、actuator stateのどれが、どこで最初に利用可能になるのかを定義する。

次に、gateway、broker、SDK、connection、storage、network egress、cloud control plane、recipient service、batch、migration、break-glass、administrator経路を列挙する。各経路を保護境界、sink identity、routeとpolicyのversion、credential、利用主体に結び付ける。

そのうえで、権限欠落、期限切れ、失効、replay、内容改変、誤ったsink binding、無効なworkload proofを試す。合格条件は警告ではなく、すべての列挙経路で効果が出ないことだ。試験していない経路はunknown、意図的な例外は別権限と責任者を記す。

これはDaniel Kadeの提案であり、IETF、EU、草案著者の要求ではない。また、機械可読制約が法を正しく表すかも判定しない。草案自身が、高リスク分類、禁止行為、人間監督の法的十分性、適合性評価をprotocol外に置く。レシートが証明するのは、宣言された効果に対して宣言された規則を回避できなかった、という限定された事実だけである。

IETFで検討し得る面も狭い。Candidate Act表現、canonicalisation、validation evidence、act-bound authorization、所持証明、sink binding、freshness、revocation、error semanticsであり、各国法の意味ではない。Heng LuのRunning-Code Primacyに照らせば、componentの適合をsystemの不可避性へ拡張してはならない。

Finality Sinkは、到着した無効操作を拒否できる。到着しなかった操作を拒否することはできない。

出典