External Agent User Boundary: an Agentforce Architecture Guide

What is External Agent User Boundary in Agentforce architecture?

In Agentforce architecture, run external-facing agents as one dedicated Agent User whose permission set is the entire trust boundary. This guide explains the design decisions, controls, and implementation checks needed to apply the pattern in production.

External-facing agents answer to people you do not control, through channels where prompts are untrusted input. The Agent User they execute as determines exactly what an attacker, or a confused customer, can reach through the conversation. Unlike an internal employee, an external user has no accountability, no training, and no limit on attempts.

When the Agent User's permission set is the whole boundary, least privilege stops being a guideline and becomes a configuration fact. One careless grant turns a scoped support agent into a path to data or actions it was never meant to touch. The Einstein Trust Layer filters prompts and masks data, but it cannot compensate for permissions the agent should never have had.

Treat the permission set as the boundary

• Give each external-facing agent one dedicated Agent User, never shared with other agents or human users.
• Grant only the object, field, and Apex access the agent's topics and actions actually require.
• Scope record access with sharing rules and restriction rules, not object permissions alone.
• Assume every external prompt is adversarial and design permissions so abuse cannot exceed the intended scope.

Lock down and audit the Agent User

1. Create a dedicated Agent User per external agent with no console login and no delegated access.
2. Build its permission set from the agent's actions, then remove anything the actions do not invoke.
3. Test with red-team prompts that try to read, change, or exfiltrate data outside the intended scope.
4. Audit the permission set on every change, alert on grants added outside the review process, and re-verify after each release.