暗号学的な証明は、私の同意がすでに古くなったずっと後でも有効であり得ます。
それこそが、ニュートンプロトコルを学びながら私がずっと考え続けているプライバシーと制御の問題です。
事前の決済承認は、重要な意思決定を実行の前に前倒しできるため価値があります。アプリケーションは、資金が動く前に、その行為がポリシーに適合しているかを確認でき、署名付きの証明（アテステーション）によって、必要な評価が実際に行われたことを示せます。
しかし、金融の許可は永久ではありません。
ポリシーは変更される可能性があります。
アプリケーションは新しい機能を追加できるかもしれません。
AIエージェントの役割は拡大するかもしれません。
ユーザーは、最初に同意したときに理解していたのと同じ形では、その認可をもはや理解できないかもしれません。
その時点で、私は証明が技術的に有効であり続けるかどうかだけを気にするのではありません。
それに紐づく許可が、今も私の意図を反映しているかどうかが重要です。
行動自体は同じままでも、その意味は変わり得ます
たとえば、狭い範囲のアセット内で1つのバルトをリバランスするように、私はAIエージェントを許可するとします。
最初は、その委任は理解しやすいです。エージェントは、集中を抑え、担保の上限を維持し、取引を承認された取引先へ振り分けられます。
次に、アプリケーションがポリシーを更新します。
新しいアセットのカテゴリが追加されます。
別の実行ルートが利用可能になります。
承認されたリスク範囲が変わる。
古い認可でもシステムの技術的要件は満たしているかもしれません。しかし、私の許可の実際の意味は拡大しています。
私は元の挙動を承認していたかもしれません。
私は、その後のあらゆる解釈について必ずしも承認したわけではありません。
ここが、私が思う $NEWT の会話が、単に「ポリシーチェックが通った」ことを証明するだけよりも深くなるポイントです。
有効なアテステーション（証明）により、その時点で使われたルールに従ってアクションが実行されたことを示せます。
元の同意以降にそのルールに加えられたすべての変更を、私が理解し承諾したことを自動的に示すわけではありません。
ポリシーバージョニングも同意の問題です
Newton Mainnet Beta と VaultKit により、プログラム可能な認可が私にはより具体的に見えてきます。開発者は、重要な制限をフロントエンド内や文章化された委任の中に置きっぱなしにするのではなく、自動化されたアクションを取り締まるための執行可能な条件を定義できます。
それは役に立ちます。
しかし、一度ポリシーがプログラム可能になると、それらのポリシーの変更はユーザーの管理の一部になります。
知りたいのは：
私は最初に、どのポリシーバージョンを承認したのでしょう？
その後、何が変わったのでしょう？
その変更はエージェントの権限を狭めたのか、それとも拡大したのか？
大きな更新には新たな同意が必要ですか？
古い許可は、新しいポリシーのもとで自動的に継続して動作し続けますか？
これらの問いが重要なのは、すべての更新が同じではないからです。
技術的なエラーを修正しても、ユーザーのリスクは変わらないかもしれません。
新しいカウンターパーティが追加されるかもしれません。
データソースを更新しても、同じ委任が保持される可能性があります。
エージェントに別のチェーンをまたいで資本を移動させることは、それを大幅に拡大させ得ます。
強いシステムは、メンテナンスと意味のある許可変更を区別すべきです。
AIエージェントによる静かな拡大は、見落としやすくなります
この点は、自動化されたエージェントが頻繁に行動するほど重要になります。
人間なら、アプリケーションが変わったことに気づいて立ち止まり、確認できます。
エージェントは、システムが今アクティブだと見なしているポリシーのもとで動作し続ける可能性があります。
エージェントの観点では、何も不自然なことは起きませんでした。要求は認可を通過し、取引は現在のルールの範囲内に留まっていました。
私の観点では、コントロールがドリフトしているかもしれません。
エージェントは、新しいポリシーの範囲外で動いているにもかかわらず、完全に準拠し続けることがあり得ます。私が承認したと思っていた境界の外で行動するのです。
それが、居心地の悪い部分です。
自動化は、ユーザーの意図を超えるためにルールを破る必要はありません。
ルールそのものが動くこともあります。
私にとってこれが、同意を「一度のチェックボックス」として扱えない理由です。同意は、スコープ、ポリシーのバージョン、アプリケーションの文脈、そして時間に結び付いたままであるべきです。
署名付きアテステーション（証明）は文脈を保持すべきです
私は、署名付きアテステーション（証明）に価値があると考えます。署名があることで認可判断をより検証しやすくできるからです。
しかし私は、証拠が「これが通ったか？」以上の答えを出せるだけの文脈を保持してほしいです。
私は次のことを知りたい：
どのポリシーバージョンがそのアクションを制御していたか、
そのバージョンが、私が承認したものと違っていたのかどうか、
私の許可に期限切れがあったかどうか、
エージェントの委任が変わったかどうか、
そして、実質的な更新の後にアプリケーションが新たな同意を必要とするかどうか。
その情報のすべてが公開される必要はありません。
その一部はユーザー、アプリケーション、または認可された監査人にのみ属するかもしれません。
ただ、それは存在すべきです。
文脈がなければ、きれいなアテステーションでも、ユーザーがより狭い何かに同意したという事実を隠しつつ、システムが現在のルールに従ったことを証明できます。
同意は曖昧になる前に失効すべきです
すべての自動化されたアクションが、別の手動の署名を必要とするべきだとは思いません。それでは、自動化が提供すると想定される利便性の多くが台無しになります。
しかし私は、許可が際限なくオープンなまま残るべきだとも思いません。
より良いモデルは、次のような「上限付き認可」を使うかもしれません：
1つのバルト（vault）、
1つのアプリケーションが、
1つのポリシーバージョン、または互換性のあるポリシー範囲、
1つで定義されたリスク委任
そして、明確な有効期間が1つあります。
権限を拡大しない限り、小さな更新は中断なしで継続できる可能性があります。
実質的な変更は、レビューを引き起こすべきです。
エージェントが新しいアセット、カウンターパーティ、チェーン、支出権限にアクセスできるようになった場合、私は、古い承認からの黙示的な継承ではなく、新たな同意を求めます。
それは特に、組織の業務フローにとって重要に感じます。
あるポリシーのもとで承認されたファンドの委任は、アプリケーションが設定を更新しただけで、静かに拡大されるべきではありません。監査担当者やリスクチームは、取引が通過したことだけでなく、アクティブなポリシーが本来付与された権限とまだ一致していることを知る必要があります。
私が #Newt で注視しているのは何か
Newtonベースのアプリケーションが、決済前に金融上の権限を執行可能にできるのかに関心があります。
ただし、私はこれらの許可がどのように経年していくかも見ています。
ユーザーはポリシーが変更されたことをいつでも確認できますか？
アプリケーションは、無害な更新と権限の拡大を区別できますか？
アテステーションは、使用されたポリシーの正確なバージョンを特定できますか？
AIエージェントは、その委任が実質的に変わったときに停止したり、更新された許可を求めたりできますか？
センシティブ情報を公開せずに、同意が失効することはあり得ますか？
これらの回答は、プログラム可能な許可が「許可が最初に作られた瞬間」だけでなく、時間の経過とともにユーザーの意図を保護するのかを教えてくれます。
私にとって最も強い認可レイヤーは、単に取引が今日のルールに一致するかを尋ねるだけではありません。
さらに、今日のルールが私が実際に与えた許可とまだ一致しているかどうかも確認します。
その違いは重要です。
証明は暗号学的に正しい状態を維持できます。
ポリシーは技術的には引き続き執行可能なまま残り得ます。
AIエージェントは、完全に準拠し続けられます。
そして、ユーザーの元の同意は、そのまま残され得ます。
それが、@NewtonProtocol のようなアプリケーションが、自動化されたファイナンスが当たり前になる前に防いでほしい「ドリフト」です。
$NEWT @NewtonProtocol #Newt $LAB #Velvet #xau #VANRY #Labs
