Auditing record access before you deploy an AI agent

The safest moment to discover that your AI agent can read every salary record in the org is before you deploy it — not when a user asks it to. Because an Agentforce agent inherits the access of the user it runs as, turning one on is really a decision to expose, conversationally and at machine speed, everything that user can see. This playbook audits that access first.

Why this audit matters more for agents than people

A human rarely bumps into the full extent of their access — they open the records they work on and ignore the rest. An agent doesn’t. Ask it a question and it retrieves, joins and summarizes everything within reach. The agent creates no new access; it surfaces the access already there — including the access everyone forgot about.

So the audit isn’t about the AI. It’s about answering one old question with new urgency: what can this user actually see?

Step 1 — Pin down the agent’s running identity

Determine exactly which user (or user configuration) the agent executes as. Everything the agent can read is defined by that identity’s permissions and shares. If it’s reusing a broad human profile, that’s already finding number one — see Step 5.

Step 2 — Audit object-level access

For that identity, review the object permissions from its profile and permission sets:

• CRUD — which objects can it Read / Create / Edit / Delete?
• Field-level security — which sensitive fields are visible?
• View All / Modify All — any of these on an object (or “View All Data”) bypass the sharing model entirely and are the highest-priority thing to find.

Object access is the gate; if the agent has no business reading an object, fix it here before worrying about records.

Step 3 — Audit record-level access

For the objects it can read, determine which records it sees, across every sharing mechanism:

• Org-wide defaults — is the baseline Private or Public? A Public OWD means the agent sees every record of that object.
• Role hierarchy — does the identity sit high in the hierarchy, inheriting everyone below it?
• Sharing rules — which ownership- and criteria-based rules include it?
• Manual shares — any one-off grants?
• Implicit sharing — access to accounts pulling in child records, the layer audits forget.

The output you want: here is the actual set of records this agent can read, and the mechanism behind each.

Step 4 — Hunt for over-broad and stale access

With the picture in hand, look for the grants that shouldn’t be there:

• A Public Read OWD that should be Private.
• Criteria-based sharing rules matching far more than intended.
• Permission sets with “View All” left on from a past project.
• Manual shares that were meant to be temporary.

Every one of these is something the agent would otherwise expose. Prune them.

Step 5 — Give the agent least privilege

Don’t reuse a broad human profile. Provision a dedicated, least-privilege identity scoped to the agent’s task, and layer attribute-based policies on top for fine-grained rules. The agent should have the minimum access required — nothing inherited by accident.

Step 6 — Re-audit on every change

Effective access drifts: a new sharing rule, a role move, a permission-set tweak, and the agent’s reach quietly expands. Re-run the audit after any sharing change, and on a regular cadence regardless. “Scoped correctly at launch” is not “scoped correctly today.”

Turning a multi-day audit into a question

Steps 2–6 are the hard part: reconstructing a user’s true effective access across CRUD, field-level security, and six sharing mechanisms — then keeping it current. By hand, that’s days of work and easy to get wrong.

AgentForceAccess is built for exactly this. Ask, in plain English, what the agent’s running user can actually see, and it traces every grant — object permission, sharing rule, manual or implicit share — and cites the mechanism. It turns “we think the agent is scoped right” into “we know it is,” before you deploy and after every change.

Frequently asked questions

Why audit access before deploying an agent at all?

Because the agent will surface everything its running user can reach, instantly and on request. Most orgs have more open sharing than anyone remembers, so the audit finds the latent access the agent would otherwise expose — before it does.

What should the audit actually cover?

Two layers. Object level: the running user's CRUD permissions and field-level security from their profile and permission sets. Record level: which specific records they can see via org-wide defaults, role hierarchy, sharing rules, manual shares and implicit sharing.

Should the agent use a real employee's account?

No. Provision a dedicated, least-privilege identity scoped to the agent's task, rather than reusing a broad human profile. The agent should have the minimum access it needs and nothing inherited by accident.

How often should we re-audit?

After any change to org-wide defaults, sharing rules, role hierarchy, profiles or permission sets — and on a regular cadence regardless. Effective access drifts over time, and the agent's reach drifts with it.