CRM、メール、文書につながるエージェントは回答だけでなくデータを変更できます。具体的な仕事に合わせて権限を与えます。「気を付けて」という指示は技術的制限の代わりにはなりません。
最小権限、専用アカウント、重要操作の承認から始めます。道具とデータ取得で境界を守ります。
読み取りと変更を分ける
注文状態の助手は読み取りだけで十分な場合があります。文章支援は送信せず下書きだけを作れます。全面権限で危険操作を避けるよう頼むより検証しやすくなります。
専用アカウントを必要な記録と操作に限定します。共有管理者パスワードは監視と権限取消を難しくします。
プロンプトインジェクションとは
信頼できないメッセージ、文書、ウェブからモデルの動作を変えようとする攻撃です。内部データを無関係な宛先に送れと書かれることがあります。
外部文はデータとして扱い、許可とみなしません。道具の引数、宛先、権限を独立して確認します。フィルターと指示でも完全防御はできません。
承認が役立つ場面
外部送信、削除、財務変更など影響の大きい操作には人の承認が役立ちます。何を実行し、どの情報に触れ、誰に送るか見せます。
詳細のない承認ボタンでは実質的に確認できません。最初の試行は可能な限り安全な下書きで行います。
情報を意識的に扱う
モデルに必要な情報と処理場所を決め、秘密を指示やログに入れず、個人情報の複製を減らし、地域と工程に合う保存期間を決めます。
提供者の条件、アクセス、削除設定を確認します。有名モデルやクラウドを使うだけで全要件を満たすわけではありません。
公開と停止の準備
権限取消、鍵交換、停止を迅速にできるか確認します。誰が何を変えたか履歴で分かるようにし、停止時の手動工程を用意します。
疑わしい文書と範囲外依頼を試し、指示だけでなく権限と道具の検証を改善します。
権限表の例
資源、許可操作、記録範囲、承認を列挙します。サービス説明の閲覧に全 CRM や決済の権限は不要です。
限定閲覧と草案を許可、送信は初期承認、削除禁止などをツール側で強制します。独立アカウントで取消と操作識別を容易にします。
文書は権限ではない
外部文の情報開示や規則無視の要求はデータとして扱い、権限とみなしません。モデル外の仕組みで能力を制限します。
検索文と指示を分け、呼出しを検証します。誘導文書と操作の試行を試験し、公開後も監視します。一つの安全回答だけでは十分ではありません。
データの扱い
各サービスへの送信、保存、権限、期間を確認し、必要な許可データだけ送ります。履歴や通知も機密を含みます。
検索前に役割を適用します。内部文書を渡して非引用を期待するだけでは不十分です。国、契約、データに沿って確認し、世界共通の適合を主張しません。
問題への備え
停止、鍵の取消、人への移管と責任者を定め、最初に止める連携を明確にします。
履歴を保護し、修復後に誤変更、重複送信、過剰権限を確認します。禁止操作も試験し、重大な判断の管理を事業側に残します。
確認すること
- 専用の最小権限を与える。
- 下書き、承認、実行を分ける。
- 外部入力と道具の引数を検証する。
- 取消、履歴、手動工程を準備する。
