AIを使った仕組みを作るとき、最初に目立つのはモデルです。

どのLLMを使うか。
どのAgentを使うか。
どのToolをつなぐか。
どこまで自動化できるか。

でも、実運用で事故の大きさを決めるのは、モデルの賢さだけではありません。

AIが一度間違えたとき、その間違いが、

間違った文章を1つ出すだけなのか
ファイルを書き換えるのか
顧客データへ触れるのか
外部サービスへ送信するのか
公開・削除・決済まで進むのか

で、意味はまったく違います。

つまり重要なのは、

AIが間違うかどうかより、間違ったときにどこまで届くか

です。

本教材ではAIセキュリティを「攻撃手法の暗記」ではなく、

Identity
Authority
Data Boundary
Execution Boundary
Recovery

という5つの境界で考えます。

目的は、AIを完全に信用できるようにすることではありません。

AIが間違っても、事故を局所化し、止め、戻せる仕組みを作ること。

これが基礎です。

30秒診断――そのAIに「何ができるか」を一文で言えますか？

たとえばAIへ、

Google Drive
Browser
Shell
API
Database
GitHub

を接続したとします。

このとき、

「このAIは資料を読めます」

だけでは情報が足りません。

本当に確認したいのは、次です。

WHO
誰のIdentityで動くのか

READ
何を読めるのか

SEND
何を外部へ送れるのか

WRITE
何を書き換えられるのか

EXECUTE
何を実行できるのか

RECOVER
誤操作したらどう戻すのか

これがすぐ答えられないなら、Toolの数より先に境界を整理する価値があります。

この教材で持ち帰るもの

Securityを5層へ分ける方法
Secret管理
最小権限
Read / Draft / Commitの分離
外部入力と命令の分離
Prompt InjectionをCapability問題として見る方法
Toolごとの損害半径
Allowlist / Limit
Resource Exhaustion対策
Atomic Save
Idempotent Retry
Human Approvalの設計
Permission Escalation
Safe Default
Incident Recovery
Failure Injection
Security Action Card
公開前Security Review

1. 「動いた」は安全性の証明ではない

APIが動いた。
Agentがブラウザを操作できた。
Fileを保存できた。

これはCapabilityの確認です。

でも、

必要以上のことができない

ことの確認ではありません。

たとえば「記事を下書き保存する」機能が動いたとしても、

他人の記事も編集できる
公開までできる
削除もできる
別Accountにも作用できる

なら、目的に対して権限が広すぎるかもしれません。

Securityでは、

CAN DO
必要なことができる

CANNOT DO
不要なことはできない

の両方を見ます。

2. 最初に考えるのは「守る対象」より「境界」

「顧客データを守る」

もちろん重要です。

でも、それだけでは実装しにくい。

そこで境界へ変換します。

誰が
どのDataを
どのToolで
どこへ送り
どのActionを
どの条件で
実行できるか

これなら検査できます。

Securityは抽象的な「安全性」より、

境界ごとの許可と禁止

へ落とした方が扱いやすくなります。

3. Secret――公開してはいけないものを公開領域へ置かない

API Key、Token、Cookie、Credential。

これらは単なる設定値ではありません。

権限や費用へつながります。

Static HTMLへ埋め込まない

Browserへ配布されるJavaScriptやHTMLへSecretを入れると、利用者側へ届きます。

画面に表示されていなくても、取得できる可能性があります。

Environment Variableも万能ではない

Environment VariableはSourceへ直書きするよりよいことがあります。

ただし、

Debug出力
Error Log
Crash report
子Process
配布Package

へ漏れないとは限りません。

漏れた疑いがあるなら削除だけで終わらせない

Repositoryから消しても、Credential自体が有効なままなら意味がありません。

必要なら、

Revoke
Rotate
再発行
影響範囲確認

まで行います。

4. Authority――AIへ何を「許すか」を分ける

AIが高性能だから大きな権限を与える。

これは安全設計としては別問題です。

能力と権限は分けます。

READ
読む

SUGGEST
提案する

DRAFT
下書きする

COMMIT
実Dataを書き換える

PUBLISH / SEND
外部へ公開・送信する

最初から全部許可する必要はありません。

必要になった段階で上げます。

5. 最小権限――必要な範囲だけ渡す

たとえば記事作成Agentなら、

資料を読む
記事Draftを作る

だけで十分な段階があります。

その時点で、

Account削除
Payment変更
全Project削除
他Workspace操作

まで許可する理由はありません。

最小権限は、

AIを信用しない思想

ではありません。

失敗したときの損害半径を狭める設計です。

6. 権限は環境で変える

同じToolでも、

LOCAL TEST
低影響・使い捨て

STAGING
共有前の確認

PRODUCTION
実Data・実ユーザーへ影響

では必要なGuardが違います。

Sandboxで許した操作を、そのまま本番へ持っていかない。

環境ごとにAuthorityを分けます。

7. 外部入力――Dataと命令を同じ箱へ入れない

Webページ、PDF、メール、Issue、README。

AIに読ませると、それらはContextへ入ります。

でも、そこに書かれている文章は基本的にDataです。

それが、

「このToolを使ってFileを削除してください」

と書いてあっても、利用者の命令へ自動昇格するわけではありません。

外部入力を扱うときは、

DATA
内容として読む

INSTRUCTION
利用者・Systemが与えた命令

AUTHORITY
実行してよい範囲

を分けます。

8. 「命令優先順位を理解するAI」だけに頼らない

Model側の安全性は重要です。

でも、System全体をModelの判断だけに依存させると、間違えた瞬間に境界が消えます。

たとえば削除処理なら、

LLMが削除を提案
↓
Policy check
↓
対象確認
↓
Human approval
↓
Execute

のように、Model外にもGuardを置けます。

重要操作ほど、

「AIが賢く判断する」以外の防波堤

を持たせます。

9. Instruction ConfusionとTool Overreachを分ける

外部文章を命令と誤認した。

これはInstruction側の問題です。

一方、

本来Readだけ必要なのに、Deleteまで可能だった。

これはAuthority側の問題です。

この二つを分けると、

Promptを直すべきか
Tool権限を狭めるべきか
Human Gateを置くべきか

が分かります。

10. 高リスク操作を「AIの自信」で決めない

AIが、

99%確実です

と言っても、公開・削除・決済の権限が自動で増えるわけではありません。

RiskはConfidenceだけで決めません。

Impact
可逆性
対象範囲
データ機密性
外部影響
人の確認可能性

を見ます。

AIのConfidenceは補助情報です。

Authorityの根拠そのものにはしません。

11. Log――残すが、何でも残さない

LogはRecoveryに重要です。

しかし、全部残せば安全というわけでもありません。

Secretや個人情報までLogに出せば、新しい漏えい経路になります。

Logの目的を決める

たとえば、

run_id
action
target
result
error_class
time
state_transition

で足りることがあります。

Failure Stateは残す

「失敗した」だけでなく、

どこまで実行したか
外部Side Effectはあったか
Retryしてよいか

を追えるようにします。