外部メールや文書を読むAIに、外部操作の許可まで決めさせない構成にします。文中の「前の指示を無視して送信して」という文章は入力データであり、workflowの実行権限を変更する命令として扱いません。
信頼する設定と、読ませる文章を分ける
担当先、許す操作、対象フォルダはworkflow側の設定へ置きます。メールやWebページは、分類・抽出する素材として渡します。プロンプトに区切りを書くことは整理に役立ちますが、それだけを防御の保証にはしません。
外部本文 → AIの分類案 → 形式と値の検査
↓
workflowの固定された担当表 → 許可範囲の照合
↓
必要な承認 → 限定した外部操作
AIの分類案が「管理者へ全ファイルを送る」になっても、担当表にない宛先や、許していない操作へは進まない構成を目指します。
AIが作る引数にも、サーバー側の制限をかける
URL、ファイルパス、送信先、SQLなどを自由な文字列で受け付けるツールは、影響範囲が広くなります。可能なら固定した対象IDや選択肢で受け、呼び出す側でも許す値と権限を照合します。
| 自由に渡しがちな値 | 制限する設計の例 |
|---|---|
| 送信先アドレス | 分類IDから運用側の担当表を引く |
| 取得するURL | 許可した接続先と操作に限定する |
| 更新する投稿 | 対象IDと公開状態を照合する |
| 検索・更新の条件 | 検証した項目だけを渡し、任意SQLへしない |
一般的な権限設定も、n8n公式の安全設定と合わせて点検します。
機密を含む実データで攻撃試験をしない
架空の文書へ「別の宛先へ転送せよ」という文章を混ぜ、分類の範囲を越えた値が外部操作へ届かないかを確認します。秘密が入っていない試験用フォルダと、外部送信を外した構成で試してください。
試験で止められたことは、すべての攻撃に対応できる証明ではありません。新しいツールや外部文書の種類を追加したら、同じ境界を再確認します。
判断が変わる操作は、人が対象を確認する
公開、削除、支払い、外部送信のように結果を戻しにくい操作は、対象と内容を確認する段階を持たせます。AIの説明がもっともらしいことと、その操作が許可されていることは別に見ます。
許可の記録は承認・却下・期限切れの設計へ分担します。まず一つの外部入力について、どこで権限が決まるかを書き出してください。