Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

The short version: an agent needs three separate things, and people usually grant only the first. Permission to use the agent, permission for whatever identity runs its actions, and access to the data those actions touch. The second is where the surprises live, because an action that runs in system context ignores the sharing model entirely, and nothing in the interface warns you.

The three layers an agent needsAccess to the agent, the context its actions run in, and the data that context can reach.Who may use the agentA permission set granting access to the agent itself. The layer everyone gets right, because nothingworks until it is done.What the agent's actions run asThe flow's or Apex class's context, not the agent's. System context reaches records the user cannotsee, and nothing in the interface warns you.What that identity can reachObject permissions, field-level security, sharing. Whatever the action can read, the agent canrestate in prose.Who may build and activateSeparate from using. Activation is a production change; if every user can also build, youhave no review step.The gap between layer one and layer two is the whole risk. Write down each action's running context, peraction. Not knowing is not a position.
Three layers, and the gap between the first two is where the surprises live.

The three layers

1. Who may use the agent. A permission set granting access to the agent itself, assigned to the people who should be able to start a conversation. This is the layer everyone gets right, because nothing works until it is done.

2. What the agent’s actions run as. An action backed by a flow or Apex runs with the context that flow or Apex declares, not with the agent’s good intentions. An autolaunched flow in system context, or an Apex class without with sharing, reaches records the person talking to the agent cannot see.

3. What that identity can reach. The ordinary model: object permissions, field-level security, sharing. Whatever the action’s identity can see, the agent can surface, in whatever words it chooses.

The gap between layers one and two is the whole risk. A user with a narrow profile can be given an agent whose actions run in system context, and the agent becomes a way around the access model, not by breaking it, but because nobody checked what the action was running as.

Check the action, not the agent

The practical audit is per action, and it is short:

  • For a flow-backed action: is the flow running in system context or user context? A record-triggered flow’s default differs from an autolaunched flow’s, and an agent action is not the place to leave it to the default. The distinction is in system context vs user context in Flow.
  • For an Apex-backed action: is the class declared with sharing, and does it query in user mode? with sharing covers record sharing only. Field and object permissions need WITH USER_MODE, as in enforcing CRUD and field-level security.
  • For a standard action: read the documentation on what it runs as, and do not assume it matches the others.

Write the answer down per action. “Runs in system context, deliberately, because it must update records the user cannot edit” is a defensible position. Not knowing is not.

Field-level security matters more here than anywhere

An agent answering a question reads many fields at once and restates them in prose. That changes the risk profile of a field that was technically visible and practically ignored, and it is the same breadth problem external agents create, covered in what an outside agent can see in your org.

The fields to check first are the ones nobody opens: cost and margin, internal risk notes, scores and predictions, anything with a compliance flag. If the action’s identity can read them, assume they can be quoted.

The permission set design that holds

Three sets, not one:

  1. Agent user — permission to use the agent, and nothing else. Assign widely.
  2. Agent action data access — the object and field permissions the actions genuinely need, assigned to whichever identity runs them. Keep it minimal and review it when actions change.
  3. Agent builder — permission to create and activate agents, assigned to very few people. Activation is a production change, and treating it as one is the difference between a governed tool and a surprise.

Separating one from three is the part teams skip. If everyone who can use an agent can also build one, you have no review step for something that reads your data and talks to customers.

What to check before activating anything

  1. Every action’s running context, written down.
  2. The data access of whatever identity those actions use, including fields.
  3. Who holds the build-and-activate permission, and whether that list is deliberate.
  4. What is logged when an action runs, and whether it names the person or only the agent.
  5. What happens when a user who has left still has an active conversation — the same question as any integration, and it depends on the identity in layer two.

Frequently asked

Does an agent respect sharing rules? Its actions do, when they run in user context. In system context they do not, and that is a property of the action rather than the agent.

Can I restrict an agent to read-only? By building it only from actions that read. There is no single switch that makes an arbitrary agent read-only, so the control is the action inventory.

Who sees the conversation? Conversation logs are their own data with their own access, and they may contain record data quoted into the transcript. Review who can read them with the same care as the records themselves.

Does the Einstein Trust Layer cover this? It addresses model-side concerns such as masking and retention. It does not decide what an action may touch — that is the permission model, and it is yours.