Agentforce: Which User the Agent Runs As

💬 In plain words: An agent can only do what its user can do. Field-level security applies, sharing rules apply, and there is no override. The only question is which user, and that is decided by the agent type.

📌 Example: A Meridian rep asks the Employee Agent about a meter on an account they cannot see. The agent says it cannot find it. The meter exists — the rep just has no access.

Concept

• This is the single most useful fact in Agentforce, and the most commonly got wrong.
• Employee Agent: Runs as the logged-in user.
• Service Agent: Runs as its own dedicated user (default_agent_user).
• Field-level security (FLS) is enforced normally. Sharing rules are enforced normally.
• Apex actions inherit this through with sharing and WITH USER_MODE queries.
• The failure mode is silent. There is no error, no exception, and no error banner.
• The agent simply says it cannot help, in a perfectly polite sentence.
• That silence is why people debug the prompt for hours before checking permissions.
• It also means an Employee Agent is genuinely safe to give broad instructions to, because the ceiling is the human's own access.

Agent asks for a record └─ Runs as USER ├─ Employee agent → the logged-in person └─ Service agent → default_agent_user ├─ Object + field access? no → silent 'cannot find' ├─ FLS on the field? no → silent blank └─ Sharing on the record? no → silent 'cannot find'

🧠 Silent, not broken. "I could not find that record" almost always means "somebody cannot see that record."

🧭 360 Card — Which User the Agent Runs As

Rule: When an agent cannot find something, check permissions before you touch anything else.

Gain: You solve in minutes what most people spend a day on.

Price: Testing properly means creating restricted users and logging in as them. That is real effort.

Limits: No override exists. There is no "run as system" mode for an agent.

Mirror — assuming a service account: You will look for a user that does not exist on an employee agent.

Later: This is also your security demo. Log in as a restricted user, ask for a forbidden record, and screenshot the refusal.

At volume: Permission creep across a build is real. Audit and remove extra grants at the end, and keep a record of every grant and why.

⚠ INTERVIEW TRAP: Do not claim the agent respects security "because we told it not to share data". Security comes from the user context, not prompt instructions. An interviewer will push on exactly this.

Core Q&A

Q: How do you prove an agent respects your security model?

🎯 Say this first: By test, not by statement. Log in as a restricted user, ask for a record they cannot see, and screenshot the refusal.

A: Describe the layers, then demonstrate them.

• The agent runs within a user's permissions, so field-level security and sharing apply exactly as they do everywhere else.
• For an employee agent, that user is the person chatting, which means the test is the real execution path, not a stand-in.
• I create a user without access to a given record, log in as them, and ask the agent about it.
• Then I do the same for a field, by removing read access and watching the answer degrade gracefully.
• I keep the screenshots, because a demonstration beats a description every time.
• I also keep a log of every permission I added during the build and why, then remove anything speculative at the end.

Follow-ups (Scenario-Based)

Q1: The agent returns an answer that is missing one field, with no error. What happened?

A1: Field-level security (FLS) on that field, for the user the agent is running as.

• A missing field due to FLS does not throw an exception. The merge field simply resolves to blank.
• The model then writes fluently around the gap, so the answer looks complete to the end user.
• This is the most under-tested behaviour in the whole product.
• The fix is to test explicitly as a restricted user during the build, not after go-live.

Q2: Someone suggests giving the Service Agent user Modify All Data to save time. Your response?

A2: Refuse, and explain the blast radius rather than quoting policy.

• A Service Agent is reachable by external customers or the public. Its user's access is effectively public reach.
• Modify All Data means any conversation is one prompt injection away from reading or modifying any record in the org.
• The correct path is a focused permission set granting access to exactly the objects and fields the actions touch.
• If that feels slow, the real problem is that nobody documented what the actions actually need to execute.