AIエージェント展開前にレコードアクセスを監査する

AIエージェントが組織内のすべての給与レコードを読めると気づくのに最も安全なタイミングは、ユーザーがエージェントに尋ねたときではなく、展開する前です。Agentforceエージェントは実行ユーザーのアクセスを継承するため、エージェントを有効にするということは、そのユーザーが閲覧できるすべてを、対話形式かつ機械の速度で露出させると決めることに等しいのです。この手引きでは、まずそのアクセスを監査します。

なぜこの監査は人間よりもエージェントにとって重要なのか

人間が自分のアクセス権の全範囲に行き当たることはめったにありません。担当するレコードを開き、それ以外は無視するからです。しかしエージェントは違います。 質問すれば、到達できる範囲のすべてを取得し、結合し、要約します。エージェントは新たなアクセスを作り出すわけではなく、すでに存在するアクセスを表に出すだけです。誰もが忘れていたアクセスも含めて。

つまり、この監査はAIについてのものではありません。古くからの一つの問いに、新たな切迫感をもって答えるためのものです。すなわち、このユーザーは実際に何を閲覧できるのかということです。

ステップ1 — エージェントの実行IDを特定する

エージェントがどのユーザー（またはユーザー構成）として実行されるのかを正確に把握します。エージェントが読めるものはすべて、そのIDの権限と共有によって定義されます。もし広範な権限を持つ人間のプロファイルを使い回しているなら、それ自体がすでに発見事項その1です。ステップ5を参照してください。

ステップ2 — オブジェクトレベルのアクセスを監査する

そのIDについて、プロファイルと権限セットによるオブジェクト権限を確認します。

CRUD — どのオブジェクトを参照／作成／編集／削除できるか？
項目レベルセキュリティ — どの機密項目が表示されるか？
View All／Modify All — オブジェクトに対するこれら（または「すべてのデータの参照」）は共有モデルを完全に迂回するため、最優先で見つけるべき項目です。

オブジェクトアクセスは入り口です。エージェントがそのオブジェクトを読む業務上の理由がないなら、レコードを気にする前にここで修正します。

ステップ3 — レコードレベルのアクセスを監査する

エージェントが読めるオブジェクトについて、あらゆる共有メカニズムを横断してどのレコードが見えるのかを特定します。

組織の共有設定 — ベースラインは非公開か公開か？公開のOWDは、エージェントがそのオブジェクトのすべてのレコードを見られることを意味します。
ロール階層 — そのIDは階層の上位に位置し、配下の全員のレコードを継承していないか？
共有ルール — どの所有者ベース・条件ベースのルールがそのIDを含んでいるか？
手動共有 — 一回限りの付与はあるか？
暗黙的共有 — 取引先へのアクセスが子レコードを引き込んでいないか。監査で忘れられがちな層です。

得たい成果物は次のとおりです。このエージェントが実際に読めるレコードの集合と、それぞれの背後にあるメカニズムはこれだ、というものです。

ステップ4 — 過度に広範で古いアクセスを探し出す

全体像を手にしたら、本来あるべきでない付与を探します。

非公開にすべきなのに**公開（参照のみ）**になっているOWD。
意図よりはるかに多くを一致させている条件ベースの共有ルール。
過去のプロジェクトで「View All」が有効のまま残っている権限セット。
一時的なはずだった手動共有。

これらはすべて、放っておけばエージェントが露出させてしまうものです。整理しましょう。

ステップ5 — エージェントに最小権限を与える

広範な権限を持つ人間のプロファイルを使い回さないでください。エージェントのタスクに絞った専用の最小権限IDを発行し、その上に属性ベースのポリシーを重ねて細かいルールを適用します。エージェントには必要最小限のアクセスだけを与え、偶然に継承されたものは一切持たせないようにします。

ステップ6 — 変更のたびに再監査する

実効的なアクセスは変化します。新しい共有ルール、ロールの異動、権限セットの微調整があるたびに、エージェントの到達範囲は静かに広がっていきます。共有設定を変更したら監査を再実行し、それとは別に定期的なサイクルでも実施します。「リリース時には正しくスコープされていた」は「今日も正しくスコープされている」ではありません。

数日がかりの監査を一つの問いに変える

ステップ2〜6は難所です。CRUD、項目レベルセキュリティ、そして6つの共有メカニズムにまたがるユーザーの真の実効アクセスを再構築し、さらにそれを最新の状態に保たなければなりません。手作業では数日を要し、間違えやすい作業です。

AgentForceAccessはまさにこのために作られています。エージェントの実行ユーザーが実際に何を閲覧できるかを平易な言葉で尋ねれば、オブジェクト権限、共有ルール、手動共有や暗黙的共有といったあらゆる付与をたどり、そのメカニズムを明示します。展開前も、変更のたびにも、「エージェントは正しくスコープされているはずだ」を「正しくスコープされていると分かっている」へと変えてくれます。

よくある質問

そもそもなぜエージェント展開前にアクセスを監査するのですか？

エージェントは実行ユーザーが到達できるすべてを、要求に応じて瞬時に表に出すからです。多くの組織では誰も覚えていないほど共有が開放されており、監査はエージェントが露出させてしまう潜在的なアクセスを、露出する前に洗い出します。

監査では具体的に何を確認すべきですか？

2つの層です。オブジェクトレベルでは、実行ユーザーのプロファイルと権限セットによるCRUD権限と項目レベルセキュリティ。レコードレベルでは、組織の共有設定、ロール階層、共有ルール、手動共有、暗黙的共有を通じて、どの具体的なレコードを閲覧できるかです。

エージェントに実在の従業員アカウントを使わせるべきですか？

いいえ。広範な権限を持つ人間のプロファイルを使い回すのではなく、エージェントのタスクに絞った専用の最小権限IDを発行してください。エージェントには必要最小限のアクセスだけを与え、偶然に継承されたものは一切持たせないようにします。

どのくらいの頻度で再監査すべきですか？

組織の共有設定、共有ルール、ロール階層、プロファイル、権限セットを変更したときは必ず行い、それとは別に定期的なサイクルでも実施します。実効的なアクセスは時間とともに変化し、エージェントの到達範囲もそれに合わせて変化していきます。