💬 In plain words: A user needs two separate grants before an agent is useful to them. One lets them use the agent at all. The other lets the agent reach data. They fail in completely different ways. 📌 Example: A Meridian rep is granted every object the agent touches, but not Agent Access. The agent simply does not appear for them. Nothing is wrong with the data model. 🎬 Real-Life Example: The Agent Nobody Could Find The Old/Bad Way: An admin built an agent, activated it, tested it in preview, and told the team it was live. Nobody could see it — including the admin, outside preview. Why this fails: Agent Access is a separate grant inside a permission set. Building an agent does not grant you the right to use it. Preview bypasses this, which is exactly why the gap goes unnoticed. The New/Good Way: 1. In the permission set, find the Agent Access section. 2. Add the specific agent to the enabled list. 3. 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
• Employee Agent: the logged-in user. Service Agent: its own dedicated user.
• Field-level security is enforced normally. Sharing rules are enforced normally.
• Apex actions inherit this through with sharing and USER_MODE queries.
• The failure mode is silent. There is no error, no exception, no 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, screenshot the refusal.
At volume: permission creep across a build is real. Audit and remove 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 the 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.
• I keep the screenshots, because a demonstration beats a description in every interview I have had.
• 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 on that field, for the user the agent is running as.
• A missing field does not throw. The merge field resolves to blank.
• The model then writes fluently around the gap, so the answer looks complete.
• This is the most under-tested behaviour in the whole product.
• The fix is to test 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 the public. Its user's access is effectively public reach.
• Modify All Data means any conversation is one prompt away from any record in the org.
• The correct path is one permission set granting exactly the objects the actions touch.
• If that feels slow, the real problem is that nobody listed what the actions actually need.