Data Access & Permissions Considerations

Security by Default REDA AI operates within Salesforce's security model. Record sharing is always enforced — an agent can never reach a record the user it runs as could not already see. Field-level and object-level permissions are enforced too, by default, on every channel. The one exception is deliberate and administrator-controlled: an unattended API agent can be set to bypass field and object permissions (never sharing) — see API Channel.

Salesforce Security Model in REDA AI

All data access through REDA AI agents is governed by Salesforce's comprehensive security model:

Field-Level Security (FLS) — Agents can't read/write fields the user doesn't have access to
Object-Level Permissions — Agents can't query or create records on objects the user can't access
Record Sharing — Agents can only access records explicitly shared to the user
Role Hierarchy — Managers can see subordinates' records according to role hierarchy rules
Public Groups & Teams — Sharing via groups and teams is respected

REDA AI does not bypass record sharing. On every channel, an agent reaches only records the running user could already reach.

There is one deliberate exception, and it applies to object and field permissions only: an agent whose Execution Context is System and whose Channel is API reads fields the running user cannot. Both conditions are required, the combination cannot even be saved on other channels, and sharing is never widened — an elevated agent sees more columns on records it could already reach, never a new record. Everywhere else the agent operates exactly as the logged-in user. See Data Security.

Permission Sets for REDA AI

REDA AI includes several permission sets to control who can access agents:

Permission Set	Use Case	Access Level
REDAAI_Admin	Admins who configure and manage agents	Can create, edit, delete agents; configure all settings
REDAAI_User	Standard users who use agents (Internal channel)	Can chat with agents; respects their Salesforce permissions
REDAAI_Community_User	Portal users accessing agents via Community channel	Can chat with agents; respects portal user permissions
REDAAI_External_Guest_User	Website visitors using External Widget channel	Can chat with agents; respects guest user profile permissions

Assign the appropriate permission set to users based on their role. Users without a permission set cannot interact with agents.

How Security Works by Channel

Internal Channel

Users are authenticated via Salesforce login. The agent operates as the logged-in user:

User's FLS applies — Agent can only access fields the user can read/write
User's object permissions apply — Agent can only work with objects the user can access
User's sharing rules apply — Agent can only see/modify records shared to the user
Example: A support agent used by a customer support rep can only access Case and Contact records shared to that rep

Community Channel

Portal users access agents through a portal experience. Security is based on portal user profile:

Portal user's FLS applies
Portal user's object permissions apply
Portal users typically see only their own records (account, cases, contacts)
Org-wide defaults and portal user profile restrict data visibility

External Widget Channel

Website visitors use agents without Salesforce authentication. Security is based on the Guest User profile configured in the Site:

Guest User profile FLS applies — Severely restricted for external users
Guest User profile object permissions apply — Usually very limited
Guest users can typically only access published data, publicly shared records
Be conservative: Only assign tools that make sense for unauthenticated guests

API Channel

An API-channel agent is triggered by another system rather than by a person, so it runs unattended as an integration or automation user — not as whoever started the process. Everything above still applies: that user's record sharing, object permissions and field-level security all govern what the agent can do — unless you set Execution Context to System on the agent, which is possible only on this channel and elevates object and field access (never sharing). If you do, the integration user's field permissions stop being the limit, so decide that deliberately.

This creates a practical problem that the other channels do not have. Because a REDA AI agent decides what to look at from context, you cannot always list in advance every object and field it might touch — so the integration user's permissions are hard to get exactly right, and the agent works in testing and then fails on a record nobody anticipated.

Execution Context

Execution Context on the Agent Definition record addresses this. It has two values:

User (the default) — the agent's tools enforce the running user's object and field permissions, exactly as on every other channel.
System — the agent's tools stop enforcing object and field permissions. This only takes effect on the API channel; set it on an agent on any other channel and it is ignored.

System does not widen which records the agent can see. This is the point most often misunderstood, and it is worth being precise about. Record-level sharing — covered in Record Sharing Example below — is always enforced, under both values. System changes only which fields and objects the agent may read or write on records it could already reach. An agent cannot use it to reach a record that was hidden from it.

Three controls bound it:

Control	What it means
API channel only	Ignored on every other channel. Internal agents run as the signed-in person, where their own permissions are the correct boundary; community and external-widget agents run as a guest, where bypassing permissions would be unsafe.
Administrator-only	A field on the Agent Definition record, editable through the REDAAI Admin permission set. The agent cannot enable it for itself, and no instruction written into a prompt can change it.
Every elevated call is logged	Each time a tool runs with permissions bypassed, an entry is written to the incident log naming the tool, the target object and the user it ran as — so "what did this agent do with elevated access?" is always answerable.

Leave Execution Context as User unless you are running an unattended API agent that is failing on permissions. It is not a performance setting, and there is no benefit to enabling it speculatively. When you do use it, the safer pattern is still to grant the integration user the access it needs and keep Execution Context on User — reach for System when that list genuinely cannot be pinned down in advance.

FLS in Action

Field-Level Security example:

Scenario: Salary Field

Your agent is configured with Account.AnnualRevenue as a context field. An HR representative has FLS read access to the field. A sales rep does NOT have FLS access to the field (company policy — sales shouldn't see revenue).

When the HR rep opens an account, the agent sees AnnualRevenue in context. When the sales rep opens the same account, the agent does NOT see AnnualRevenue (FLS prevents it). Both users see different data based on their FLS permissions.

Sharing rules example:

Scenario: Case Records

A support agent is deployed for support reps to use. Rep A has been assigned to Cases 001, 002, 003. Rep A opens Case 001 and chats with the agent. The agent can query and modify Case 001 because Rep A has access.

Rep A tries to ask the agent about Case 099 (assigned to Rep B). The agent cannot access Case 099 because Rep A doesn't have sharing access to it. If Rep A tries to use tools to query it, they get a permission error.

External Widget agents are accessed by unauthenticated website visitors. Security is critical here:

Configure a Restrictive Guest User Profile — The profile should have minimal permissions
Review FLS Carefully — Only expose fields that are safe for public view (no confidential data)
Limit Tool Assignments — External widget agents should typically have no write tools (no create_record, update_record)
Test Thoroughly — Use an incognito browser to simulate guest access and verify data is properly restricted

Example: A website visitor chatting with an External Widget Support Agent should be able to:

Search knowledge base articles (read-only)
Submit a support case (create_record restricted to their own case)
Check case status (soql_query limited to their own cases)

They should NOT be able to:

See other customers' support cases
Access employee data
Modify pricing or configuration data

Best Practices for Secure Agent Deployment

Principle of Least Privilege

Assign the minimum necessary permissions and tools. External widget agents should be most restrictive, internal agents somewhat permissive, and admin agents most open.

Review FLS Before Deploying — Before adding a field as a context field, verify that all users who will use the agent should have access to that field. Don't accidentally expose sensitive data.

Carefully Assign Write Tools — Tools like create_record, update_record, delete_record, send_email should be restricted to agents where these actions are appropriate. External widgets rarely need write tools.

Test as Different Users — Test your agents logged in as:

A standard user with basic permissions
A user with restricted permissions (no access to certain objects)
A guest user (for external widgets)

Verify that each user sees only the data they're authorized to see.

Monitor Tool Execution — Review logs to see which tools agents are calling and which users are using them. Identify and address any suspicious patterns.

Common Security Concerns & Solutions

Concern	Solution
Agent might expose confidential fields	Use FLS to prevent access. Verify FLS on sensitive fields (Salary, SSN, etc.)
External users might access internal data	Use a restrictive Guest User profile for external widget agents. Test thoroughly.
Users might accidentally create/update wrong records	Action tools show confirmation cards. Use guardrail prompts to prevent misuse.
Agents might bypass sharing rules	Impossible — REDA AI operates within sharing rules. Agents can't access records the user can't see.
Agents might query sensitive data	Use prompts and guardrails to restrict agent behavior. Test query results.

Connect selected agents through MCP

MCP connects an approved AI assistant to selected active Internal agents. Each person signs in with their Salesforce identity. The host receives agent entry points; individual REDA tool and prompt definitions are not exposed as separate MCP tools. Configure a Salesforce Site, an External Client App, both REDA AI User and REDA AI MCP User assignments, and agent opt-in. See the administrator setup guide and user guide. Interaction data can reach the connected host and configured AI providers as well as Salesforce. Review the intended data and agreements; this is not a promise that data never leaves Salesforce.

Frequently Asked Questions

No. REDA AI operates as the logged-in user. If the user can't see a record, the agent can't either. This is enforced at the data layer.

The field is not returned. If it's configured as a context field, it's omitted from the context. If the agent queries it via a tool, it's excluded from the results. No error is shown to the user — the agent simply doesn't see the field.

Only if you explicitly assign the create_record tool and the Guest User profile has create permissions on that object. This is rarely recommended. For most external widgets, use read-only tools or very restricted create permissions.

Don't assign the delete_record tool to the agent. If the tool isn't assigned, the agent can't call it. Alternatively, use the Guest User profile or FLS to prevent delete operations at the data layer.

Next Steps

Review internal channel setup for deploying agents to your team, or explore external widget deployment for customer-facing agents.

← Previous: Community Agent

Next: Messaging Channel Integration →