AIセキュリティについて考えれば考えるほど、結局は一つの疑問に立ち返ってしまう
AIの行動を承認するはずのシステムが…できなかったらどうなる？
最初は、答えは明らかだと思った。
認可レイヤーがダウンしたら、AIは何もできないはずだ。
それは最も安全な選択に思える。
結局のところ、あるシステムがその行動が許可されていることを確認できないなら、当てずっぽうで判断すべきではない。特に金融では、不確実性が許可に変わってはいけない。
でも考えれば考えるほど、自信がなくなっていった。
認可サービスが利用できないときに、金庫が本当に対応を必要としているとしたらどうなるでしょうか？
すべてをロックして、問題が自然に解決するのを待つのですか？
それとも、誰かが介入できるようにしますか？
それが、NewtonのVaultKitについて読んでいて私が面白いと感じた問題です。
即時の上書きを許すのではなく、遅延された緊急ルートを使います。例外的なアクションは起こせますが、すぐにはできません。待つ必要があり、その判断はオンチェーンで確認できます。
私はむしろ、その考えが好きです。
即時のバイパスがあると、ポリシーレイヤーが任意のもののように感じられてしまいます。ルールをすぐに回避できるのが常にあるなら、ルールの重みはそれほど大きくなりません。
しかし、緊急アクセスを完全に取り除くのも現実的だとは感じません。
実システムは壊れます。
ネットワークで障害が発生します。
サービスが利用できなくなります。
すべてが通常に戻るのを待つことが、時には選択肢になりません。
だからこそ、遅延された緊急ルートは妥当な折衷案に感じます。
とはいえ、待機期間自体が最も面白い部分だとは思いません。
私が特に注目したのは、信頼の源が変わることでした。
通常の条件では、特権アクションは事前に定義されたポリシーに照らして評価されます。オペレーターが承認し、必要なチェックが行われ、その後に初めてアクションは先へ進むことが許可されます。
緊急時には、それがもはやシステムを守っているわけではありません。
代わりに、所有者の権限、待機期間、そして誰もがオンチェーン上で何が起きたかを見られるという事実に頼ることになります。
それは別種のセキュリティです。
必ずしも弱くなるわけではありません。
それは単に、別の前提に基づいて構築されているだけです。
そして、その区別は重要だと思います。
透明性は価値がありますが、透明性は認可と同じものではありません。
緊急ルートが使われたのを見ても、そのアクションが、通常運用時と同じレベルの検証を受けたことを自動的に意味するわけではありません。
その次に問題になるのがタイミングです。
緊急の遅延は実際にどれくらいにすべきでしょうか？
短くしすぎると、緊急ルートが近道のように見えてしまいます。
長くしすぎると、回復のために設計されていたその仕組み自体を遅らせてしまうかもしれません。
完全に正解があるわけではないと思います。
すべてのプロトコルが、セキュリティと柔軟性の間のどこに身を置きたいのかを決めなければなりません。
私にとって最大の学びは、ニュートンに緊急メカニズムがあるということではありませんでした。
緊急メカニズムが、最終的な信頼が実際にどこにあるのかを明らかにするのだと気づいたことでした。
すべてのコンポーネントが意図どおりに完全に機能しているなら、セキュリティについて語るのは簡単です。
より難しいのは、そうした前提が成り立たなくなったときに何が起こるのかです。
最終決定を下すのは誰ですか？
それでもなお残るのはどんな保護策でしょうか？
そして最終的に、ユーザーには何を信じさせようとしているのでしょうか？
私は、これらの問いはAIのパフォーマンスや自動化そのものと同じくらい注目に値すると考えています。
なぜなら、セキュリティシステムの真の強さは、すべてが完璧に機能しているときにどう振る舞うかで測られるものではないからです。
それは、何かがうまくいかないときにどう振る舞うかで測られます。
