What Customer Data Can Salesforce Agentforce Access?

What you can decide after checking the facts

A better-informed decision starts with what is known, what still needs checking, and who will take the next step. The following are practical objectives to consider for this particular issue:

• Map objects and fields accessed.
• Review sharing rules and permission sets.
• Test anonymous and authenticated flows.
• Capture a permission evidence record.

Why the evidence matters

US-TechLaw is an independent technology-law research and consulting platform. This page uses the applicable official rules and product-provider documentation as reference points, rather than relying on broad claims about what every AI system or business must do. Where company-specific contracts or settings would change the conclusion, they are identified as facts to verify instead of assumed. The research is informational and does not replace qualified advice for a particular situation.

How to raise your specific question

Describe the decision or problem in a few sentences, identify the product or system involved, and state what result you need to understand. Do not send privileged documents, complete customer files, credentials, or sensitive operational records in an initial email. The scope, appropriate expertise, and any secure exchange of additional documents should be determined separately before detailed review.

Questions worth preparing:

• Which Agentforce product and Salesforce edition are in use?
• Is this a customer-facing service agent or employee agent?

Questions, documents and safeguards to review

Does Agentforce use an agent account or the customer’s login?

Agentforce is not a single access pattern for every Salesforce implementation. Some employee-facing agents operate in the context of the signed-in user, while certain customer-facing service agents use a dedicated agent user for actions and record access. Salesforce states that user permissions, field-level security, and sharing settings determine what the agent can reach. The first step is therefore to identify the agent type, channel, identity, and Salesforce organization rather than assume all data is available to it. (Salesforce agent-user permission best practices)

Which customer records may it read?

List the Salesforce objects and fields used by the planned conversation. An agent may need to read a case status but not a customer's confidential notes, or update a support ticket without changing account ownership. Check object permissions, field-level security, record sharing, and relevant action configuration. If the workflow uses flows or Apex, record which operations they perform and the authority required to invoke them. A phrase such as “customer service access” is too broad to verify. The evidence must show exactly what this particular agent can retrieve or modify in representative sessions. (Salesforce agent-user permission best practices)

Which fields and objects can it change?

Customer conversations may be anonymous, identified without a site login, or fully authenticated. Salesforce explains that an Agentforce Service agent may run under an agent user's permissions in the first two situations and under the logged-in user's context in the latter. The distinction is material: knowing a customer's contact identifier does not necessarily restrict the database access available to the agent's operating identity. Test each supported session type separately. Record what authentication was actually established, what record was requested, and whether the response was allowed. (Salesforce Service Agent access by session type)

How do guest and signed-in sessions differ?

For customer-facing service agents, Salesforce recommends least-privilege access for the dedicated agent user. Create a permission inventory showing objects, fields, record-sharing rules, and action permissions. Identify broad organization-wide defaults and inherited access that might permit the agent to expose records beyond the customer at the other end of the chat. If the organization relies on filters or verified identity variables, test whether those controls block a request for another customer's record. A successful generic demo is not adequate evidence of customer-level isolation. (Salesforce agent-user permission best practices)

What should permission sets allow?

Actions matter as much as knowledge retrieval. An agent can sometimes update records through configured workflows even when its visible response seems harmless. Catalogue each action's input fields, output, authority, and downstream effect. Ask which changes require explicit user confirmation or staff review. For a customer-support agent, changing an address and closing a complaint should not necessarily have the same safeguards. Store a test record that demonstrates the configured permission and the actual effect in a non-production environment. Review Salesforce guidance for the agent type and edition being used. (Salesforce Service Agent access by session type)

How can sharing rules expose unexpected data?

Sharing rules can produce surprises when records are visible through roles or group membership. Test multiple users and multiple customers, not just the administrator who built the agent. Include an unknown visitor, a verified customer, an employee with limited access, and a support manager where relevant. Look for unexpected fields in generated answers, not only for direct record downloads. A response can reveal restricted information through a summary. These checks should be conducted in a controlled test environment with non-sensitive data before the system handles genuine customer interactions.

What should be tested before connecting a customer channel?

Keep evidence of the agent identity, assigned permission sets, sharing configuration, enabled actions, user-session type, and a small set of accepted and rejected test requests. Protect this record because it may reveal internal permission design. If a customer reports exposure of another person's data, preserve the relevant session and logs while limiting continued access. Determine whether the cause was an overly broad agent user, missing identity verification, an action filter, or a response that quoted information improperly. The corrective control depends on that root cause.

What records prove the permissions are working?

A safe go-live decision should identify which customer information the agent actually needs and how access is enforced. Review new flows, permission changes, additional channels, and external integrations before deployment changes. Re-test after Salesforce features or agent configurations materially change. The resulting decision is a statement about an identified Salesforce organization and a defined agent workflow, not a universal assurance about Agentforce. When personal data is involved, assess applicable privacy obligations and customer notices alongside the technical permission work.

Example: how the decision changes with the facts

Illustrative scenario, not a client case or statement of actual results.

A customer-service Agentforce bot answers order questions in an anonymous chat. Its Salesforce agent user can access a broad set of contact records, even though visitors should see only their own information. A responsible test would ask for another customer's details using controlled accounts and inspect whether filters, permissions, and identity verification prevent disclosure. A later logged-in session might operate under a different access context, so both cases should be tested separately. The lesson is not that Agentforce necessarily discloses customer data; it is that effective permissions depend on the configured agent type and user context.

Decision and evidence table

Documents and facts to prepare

For a reliable review, identify the specific system or agreement, the date and version of its relevant terms, the business decision being made, the people affected, and the records available to support the answer. The most helpful starting material for this topic is: Agent identity × CRM object permissions matrix and exposure scenario tests. A request for information should remain proportionate; sensitive records should be exchanged only through an appropriate authorized process.

Frequently asked questions

Can an anonymous visitor see Salesforce data?

That depends on the configured agent user, sharing rules, verification controls, and actions.

Will the same permissions apply after sign-in?

Not always. Salesforce describes different access contexts for various user-session types.

What evidence should admins keep?

The agent type, user identity, permission sets, sharing rules, action definitions, and accepted/rejected tests.

What to check before acting

Before acting, write down the decision your team needs to make: Help crm teams identify which customer records a salesforce agentforce agent can read or change. List the relevant documents and settings, the facts still missing, and the person who will confirm each point. Review the decision again if the agreement, software features, workflow, or governing requirements change. Seek qualified professional advice when the specific legal question or regulated activity requires it.

Practical guides for AI-agent business decisions

Continue with the specific business problem and compare the applicable requirements with related guidance.

• Can an AI Agent Read or Update Your Customer Records?

Related business and technology guides

• Explore Enterprise AI Products
• Related research and practical support
• How Do You Control What Copilot Studio Agents Can Do?
• Can You Put Customer Information Into Claude?