Before You Trust Agentforce: How to Audit What Your Agent User Can Reach
An Agentforce agent acts through a Salesforce user. Whatever that user's profile, permission sets and sharing allow, the agent can reach. Old, over-broad access that no person ever used becomes a real exposure once an agent can act on it. Here's how to audit it.
Short answer: An Agentforce agent acts through a Salesforce user. Whatever that user's profile, permission sets, permission set groups and sharing allow, the agent can reach through its actions. Old, over-broad access that no person ever used becomes a real exposure once an agent can act on it. To audit it: find the agent's user, list everything it holds, compare that to what the agent's topics and actions actually need, remove the rest, and re-test in a sandbox.
Why an agent turns permission debt into risk
Most orgs carry permission debt: permission sets granted "just for now", profiles cloned from admin, View All / Modify All left on integration users. With people, that debt is mostly latent. An agent changes that. It runs actions, Flows and Apex on behalf of whoever is chatting with it, and it will use any access its user has if an action asks for it.
Step 1: Find the agent user and what it holds
- **Agent user.** Open the agent in Agentforce Studio (or the legacy Agentforce Builder in Setup) and note the user it runs as. Service-style agents typically run as a dedicated Agent User; employee-facing agents run with the signed-in user's access.
- **Profile, permission sets and groups.** On that user record, list the profile, every permission set, and every permission set group. Use "View Summary" on each to see the effective object and system permissions.
- **Object, field and record access.** Check CRUD and field-level security on every object the agent's actions touch, then sharing: role, sharing rules, and any View All / Modify All.
- **What the agent can trigger.** List each action: Flows, Apex classes, prompt templates, and any external callouts through named credentials. An action that runs in system context can bypass the user's own limits.
Step 2: Audit checklist
| Check | Where | What good looks like | |---|---|---| | Agent user identity | Agentforce Studio, user record | One named, dedicated user per agent; not a shared admin or integration user | | Profile | User record | Minimal profile; access comes from permission sets | | Permission sets / groups | User record > Permission Set Assignments | Only the sets the agent's actions need; nothing "temporary" | | System permissions | Permission set summary | No Modify All Data, View All Data, Manage Users, Customize Application | | Object CRUD and FLS | Permission set summary | Only the objects and fields the topics use; sensitive fields hidden | | Sharing | Roles, sharing rules | No View All / Modify All on objects outside the agent's scope | | Flows and Apex | Each agent action | Know which run in system context; restrict inputs | | External callouts | Named / external credentials | Only the endpoints the agent needs, least-scope credentials |
Step 3: Least-privilege plan
Start from the agent's topics and actions, not from the user's current access. For each action, write down the objects, fields and records it needs. Build one permission set for that agent with exactly those, assign it, and remove everything else. Keep agent permissions out of broad permission set groups so a later change for humans doesn't quietly widen the agent.
Step 4: Test before you trust it
In a sandbox, run the agent with realistic prompts, including ones that ask for data it should not return. Confirm it refuses or fails safely. Re-run after removing access to make sure the actions it needs still work.
Step 5: Keep it from drifting
Re-check after every Salesforce release, after any change to the agent's permission sets or groups, and whenever new actions are added. Agentforce is now on by default for many orgs (see our [Agentforce default-on inventory](/insights/agentforce-auto-enabled-what-to-inventory)), so the platform-level inventory and this per-agent audit belong on the same schedule.
FAQ
What permissions does an Agentforce agent user get?
Whatever is assigned to that user: its profile, permission sets and permission set groups, plus sharing. When you create a Service Agent, Salesforce can automatically assign the Agentforce Service Agent User permission set group (which includes Agentforce Service Agent User, Data Cloud User, and Prompt Template User permission sets) along with Agentforce Service Agent Secure Base. Check the permission set assignments on your specific agent user.
Can an agent see fields a user can't?
It sees what its running user can see. Actions that run in system context (some Flows and Apex) can reach beyond that, which is why the action list matters.
How do I remove permission debt before turning on an agent?
Build a dedicated permission set from the agent's actions, assign only that, remove the rest, and test in a sandbox.
Does Salesforce Health Check cover agent permissions?
No. Salesforce's built-in Health Check evaluates org-wide security settings: password policies, session settings, network access, certificates. It does not audit permissions, data quality, flows, or agent-specific access.
How often should I review agent permissions?
After every release and every change to the agent's actions or permissions.
Want a quick read on your org's overall health? Answer three questions in the free health check. It needs no account and no sales call: [Start the free health check →](https://wrenk.ai/free-health-check?utm_source=wrenk_insights&utm_medium=blog&utm_campaign=wrenk-05-permission-debt)