07 — Boundaries by design
No. 07
安全設計
Boundaries by design
自律して動くAIに、自社のコードを任せる。そう聞いて最初に浮かぶのは、「何をしでかすか分からないのではないか」という問いでしょう。
Athenaraの答えは、AIの行儀のよさに期待しないこと。できることの範囲を、仕組みの側であらかじめ狭めてあります。AIがどう判断しても越えられない境界が、六つあります。
第一条読み取り専用
調査のためにAIへコードを見せると聞けば、次に気になるのは見せたコードに何かされないかでしょう。設定が書き換わる、修正のつもりの変更が紛れ込む、誰が入れたか分からない差分が残る。どれも起きてから気づくと、原因を追うだけで手間がかかります。
対象のコードは読み取り専用で参照し、書き換えません。運用上の約束ではなく、調査の環境にコードを渡すときの渡し方で決まっています。AIがどう判断しても、書き込む手段がそもそも与えられていません。
読める場所、書ける場所
| 場所 | Read | Write |
|---|---|---|
| 対象のソースコード | ○ | — |
| 過去の調査で残した資料積み上げた知識と作業の記録 | ○ | — |
| ほかの調査の作業場所並んで進む別の問い | ○ | — |
| いま進めている調査の作業場所 | ○ | ○ |
| Athenara自身の記録と設定調査の結果や方針を管理する台帳 | — | — |
試験のために書いた小さなプログラムや観測の記録は、すべてその調査の作業場所に置かれます。AIが想定外の動きをしても、変えられるのは自分の作業場所の中身まで。コードにも記録にも跡は残りません。
GitHubに渡すのは、読み取りの権限だけ
コードの受け渡しは、社内サーバーへ人が手動でリポジトリを置くか、GitHub連携で自動的に取得させるかの二通り。GitHub連携は必須ではありません。
連携を使う場合も、求めるのはリポジトリの内容を読む権限と、更新があったことの通知だけです。コードを書き換える権限、変更を送り返す権限は求めません。仮にAthenaraの側で何かが起きても、GitHub上のリポジトリを変える手段は持っていません。
取得に使う鍵は、コードを取ってくるその瞬間にだけ使い、設定ファイルやデータベース、ログには残しません。手動で置いたリポジトリについても、接続先や認証の設定をAthenaraの都合で書き換えることはありません。
コードの持ち主は、人のまま
調べている途中で、コードは入れ替わらない
コードが更新されても、進行中の調査が見ているコードを途中で差し替えることはありません。更新は調査の区切りで取り込み、どの調査がどの版のコードを調べたかが記録に残ります。報告がいつの時点のコードについての話かで迷うこともありません。
直すのは、これまでどおり開発チーム
Athenaraは問題を見つけ、再現手順と証拠を添えて報告します。修正のコードは書きません。直し方を決め、レビューを通し、リリースするのは、いつもの開発の流れのまま。変更履歴に、誰が入れたか分からない修正が混ざることもありません。
直った後の確認は、任せられる
修正が取り込まれれば、同じ条件で試し直して直ったかを記録します。手を動かすのは人、確かめ直すのはAthenara。役割の線が、はじめから引かれています。
直したあと、同じ条件での試し直し
第二条本番非接続
Athenaraの調査は、コードを読むだけでは終わりません。怪しいと思えば実際にリクエストを送り、画面を操作し、攻撃者が試しそうなことを試します。確かめる力があるということは、使い方を誤れば壊す力もあるということです。
たとえば「この画面から、他人の注文を取り消せてしまわないか」を確かめるとします。本番で試せば、確かめること自体が顧客の注文を消しかねません。攻撃に近い試験は、本番に向けた瞬間に事故の種になります。
Athenaraが試すのは、隔離した環境の中で起動したプロダクトの複製だけです。起動の方法は、導入時に設定へ書いたものを使います。本番のデータベースや稼働中のサービスには、最初から道がありません。「本番に負荷をかけない」「本番データに触れない」という社内ルールを、担当者の注意ではなく構造で守れます。
第三条到達先を絞った隔離コンテナ
すべての確認は、その調査のためだけに起動した隔離コンテナの中で行います。一つの箱で、通信の行き先、できる操作、書き込める場所の三つを絞り、対象のサービス以外には届きません。
調査のために書いたコードが想定外の動きをしても、影響はその箱の中で止まります。
INetwork
通信の行き先
調査用の専用ネットワークにつなぎ、対象のサービス以外への道を持たせません。コードを読むだけの調査には、ネットワークそのものを与えません。
試験のための通信が、社内の別の機材や社外へ漏れ出すことはありません。
IIAuthority
できる操作
管理者ではない一般の利用者として動かし、特別な操作の権限はすべて外します。途中で権限を引き上げることも、道具を後から入れることもできません。
調査の中で何を実行しても、箱の外の仕組みには手をかけられません。
IIIWrites
書き込める場所
環境の土台は書き換え不可にし、書き込めるのはその調査の作業場所と一時的な置き場だけにします。
調査の跡は決まった場所にしか残らず、何が残ったかを後から特定できます。
Athenaraの本体も、対象のサービスと同じネットワークには加わりません。両方につながるのは、調査の環境とサービスのあいだを取り次ぐ専用の中継役だけ。調査の側から、Athenaraの管理機能や記録へ手を伸ばす道はありません。
第四条調査ごとに破棄
Athenaraは数カ月単位で調べ続け、そのあいだに行う確認は数えきれないほど。一つの環境で続けていけば、環境は少しずつ汚れ、何が残っているのか誰にも分からなくなっていきます。
一つの問いに、一つの環境。調査は一つの隔離環境で完結し、終われば破棄します。次の調査は、また新しい環境から。
捨てるのは場所、残すのは分かったこと
環境を捨てても、調べた結果まで消えるわけではありません。何が分かり、どんな証拠で裏づけられ、どこまで確かめてどこが未確認か。後の判断に要るものは、調査の終わりに知識として記録へ移してから環境を捨てます。記録に移されなかったもの、試験のための使い捨てのプログラムや途中の下書きは、社内のどこにも溜まりません。
前の結論をあえて持ち込まずに確かめ直す調査もあります。過去の判断を渡さず、開いた問いと対象の範囲だけを渡して、新しい環境で一から確かめます。誤った結論がそのまま引き継がれていないかを、ときどき点検できます。
捨てることで、起きなくなること
前の調査の名残が、次の結果に混ざる
使い回した環境には、前の試験で作ったデータや設定が残ります。問題が起きたのが今回の条件のせいなのか、前の名残のせいなのか、区別がつかなくなります。毎回新しい環境なら、報告の条件はその調査の中で完結します。
誰も管理していない環境が、社内に残る
試験のために立てた環境が片付けられず、いつの間にか棚卸しの対象外になる。検証の現場でよく起きることです。調査の環境は捨てる前提で作られているため、居座る場所を持ちません。
第五条勝手に増えない
調査を担うAIが、自分の判断で調査役を増やすことはできません。ほかの調査の作業場所も、読めるだけで書き換えられません。権限は、はじめから設計で縛っています。
AIに任せる範囲が、あとから勝手に広がることはありません。どこまで任せているかを、導入時に決めた境界のまま説明できます。
第六条データは社外に出ない
推論に使うAIモデル、ソースコード、検証の結果、見つかった問題。そのすべてが社内の1台のマシンの上にあり、外部のAIサービスには接続しません。
クラウド型のAIレビューは、コードを外に送ったうえで「送った先で適切に扱われる」ことを契約で確かめます。Athenaraにあるのは、送らない約束ではなく送る先のない構成です。推論のためにコードを外へ渡す経路がそもそもなく、守るべき約束の数が最初から少なく済みます。
それでも外と通信する場面
機械が外と通信する場面は、次の三つに限られます。どれも、ソースコードや検証結果、見つかった問題を送るものではありません。
- 導入時と、AIモデルを入れ替えるとき
- 公開されているAIモデルを配布元から取得。受け取るだけで、こちらから送るものはありません。
- GitHub連携を使う場合
- 対象のリポジトリの取得と、更新通知の受信。手動でリポジトリを置く運用なら、この通信は発生しません。
- 依存ライブラリの既知の脆弱性を調べるとき
- 使っているライブラリの名前と版を、公開の脆弱性データベースと照合。ソースコードそのものは送りません。
規程と契約の話を、社内で閉じる
コードを社外に渡す前提では、規程や契約の確認は「渡してよいか」「渡した先でどう扱われるか」から始まります。提供先の管理体制まで確かめる必要があり、そこで合意できなければ手段そのものが使えません。Athenaraでは、「コードを社外のAIに見せてよいか」という判断そのものが不要になります。
これは特定の規格や認証への適合を示すものではありません。自社の規程や顧客との契約に照らしてどう位置づけるかは、上の仕組みを材料に、それぞれの会社でご判断ください。