Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does Salesforce Agentforce Need Access to Sensitive Customer Information?

Less than it is usually given: an Agentforce agent reads whatever its agent user's permission set and field-level security allow, and Salesforce's own training states that data masking for LLMs is currently disabled for agents. Scope the agent user to the fields each task needs, then check what the model reads once a customer record is open.

A customer record passes from a company data store through a narrow field filter toward an abstract viewing node.

Less than it is usually given: an Agentforce agent reads whatever its agent user's permission set and field-level security allow, and Salesforce's own training states that data masking for LLMs is currently disabled for agents. Scope the agent user to the fields each task needs, then check what the model reads once a customer record is open. The question matters because Agentforce agents sit on the system where customer data is most concentrated. A service agent answering a billing question has the whole account record in reach: contact details, date of birth, payment instruments, case history, years of staff notes. Whether the model needs any of that is a separate question from whether the agent user may see it, and the two are usually conflated. Salesforce documents two relevant mechanisms: the permission model, which decides what the agent user can read at object and field level, and the Trust Layer, which lists masking among its features but, per Salesforce's Trailhead module, does not currently apply it for agents. This page works through what decides the agent's view, what the Trust Layer does for agents today, how much of a record a task needs, what the audit trail records, what regulators expect, and what a buyer should verify. The broader pattern, that an agent reaches whatever its identity is allowed to reach, applies here with unusual force.

Key findings

  • Salesforce's developer guide lists masking of sensitive data, such as social security numbers, among the Trust Layer's features (Salesforce, 2026).
  • Salesforce's Trailhead module on the Trust Layer states that data masking for LLMs is currently disabled for agents, so the permission model, not masking, is the operative boundary for Agentforce today (Salesforce Trailhead, 2026).
  • Salesforce's ISVforce guidance states that service agents run as the agent's identity, so custom action code must check end-user authorization itself (Salesforce, 2026).
  • Trade press analysis describes the agent user as starting essentially blank, with the administrator deciding what it can touch, which makes scoping a deliberate act rather than a default (Salesforce Ben, 2026).
  • Peer-reviewed evaluation of web agents found they are prone to inadvertent use of unnecessary sensitive information, a tendency that permission scoping alone does not address (Zharmagambetov et al., 2025).
  • Permissions decide which records and fields an agent may open; a separate control is needed to decide what the model reads inside a record it is entitled to open (How to Secure AI Agents That Access Customer Data).

What decides what an Agentforce agent can read?

An Agentforce agent reads Salesforce data through an agent user, a dedicated user record with its own permission set, and that user's object permissions and field-level security draw the boundary. Trade press analysis of the permission model describes the agent user as starting essentially blank, with the administrator deciding what it can touch (Salesforce Ben, 2026). That is a sound default: the agent needs exactly the objects and fields someone chose to grant it. The trouble is how grants are made in practice.

Consider a single record type: a customer account record in a service console. It carries name, address, email, phone, date of birth, the last four digits of a payment card, a loyalty tier, open and closed cases, and a notes field that staff have used for years. A service agent is built to answer questions about order status and open cases. The quickest way to make it work is to grant the agent user read access to Account and Case and leave field-level security open on both to avoid errors in testing. Nothing in that is wrong by the platform's rules. The agent user is now entitled to the date of birth, the card digits and the notes, none of which the order status task uses.

Salesforce's ISVforce guidance adds a second layer to the boundary. Service agents run as the agent's identity, so a custom action that reaches further into the organization must itself check that the end user is authorized for what the action does (Salesforce, 2026). The agent user's permissions are a ceiling, and custom code must keep one customer's conversation from reaching another customer's data under it. Both layers answer who may read. Neither says what the model reads once a permitted record is open.

Does the Trust Layer mask customer data before the model reads it?

The documentation gives two answers that must be read together. The Agentforce developer guide lists masking of sensitive data, such as social security numbers, among the Trust Layer's features (Salesforce, 2026). The Trailhead module on the Trust Layer states that data masking for LLMs is currently disabled for agents (Salesforce Trailhead, 2026). The first describes the layer's feature set; the second describes its state for agents as of the module's writing.

Dimension Salesforce, per its documentation What a buyer should verify
Masking capability Trust Layer features include masking of sensitive data such as social security numbers Which surfaces masking is active on today
Masking for agents Data masking for LLMs is currently disabled for agents Whether that status has changed since the module was written
Read boundary Agent user permission set and field-level security The fields the agent user can read on each object it touches
Values read inside a permitted record Not described in the pages reviewed What the model receives from each record the agent opens

For Agentforce agents today, then, the permission model is the whole boundary. A buyer who assumes the Trust Layer masks the date of birth and card digits before the model reads them is relying on a feature Salesforce's own training says is disabled for this surface. Whether a later release changes that is a question for current documentation; the pages reviewed say disabled. The same gap appears across platforms, where controls built to decide who may access data are asked to decide what a model should read.

How much of a customer record does a task actually need?

Separate the task from the record. The order status task needs the order identifier, its status and perhaps a shipping date; the open cases task needs case numbers, subjects and statuses. Neither needs the date of birth, address, card digits or notes field. Yet the agent user is entitled to all of it, and when the model is given the account record as context it reads all of it. Data need and data access have come apart, and the gap is filled with values the model did not require.

This is not a hypothetical weakness of models. A peer-reviewed benchmark of autonomous web agents from Meta FAIR, AgentDAM, found that agents are prone to inadvertent use of unnecessary sensitive information, meaning they pick up and use data that was present but not needed for the task (Zharmagambetov et al., 2025). The finding concerns web agents, but the mechanism is general: a model given more than the task requires does not reliably ignore the surplus. Field-level security addresses this only if an administrator has worked out, per task, which fields are needed and restricted the rest, which is rarely how permission sets are built.

OWASP names the downstream risk as sensitive information disclosure, where confidential data reaches a model and can surface in its outputs (OWASP, 2025). For a service agent the output is a chat, and the person in the chat may not be the account holder. The design that closes the gap substitutes consistent tokens for identifiers before the model reads the record, so the agent can work with a customer record without seeing the actual values, and the real value is resolved only when an approved action needs it. Whether Agentforce applies anything comparable at the agent surface is, per the Trailhead module, not the case today.

What does the audit trail show about what the model read?

Salesforce's Trailhead module states that an audit trail tracks a prompt through each step of its journey (Salesforce Trailhead, 2026). For the account record example, the organization can later establish that a prompt was constructed, what grounding was attached, that it went to a model and what came back. A reviewer investigating a complaint has material to work with, more than most applications offer for the people using them.

Two things should be checked rather than assumed. The first is whether the trail records the values the model received or only the steps the prompt passed through. A step log that says "grounding attached from Account" is different from a record of the fields and values that grounding contained, and the pages reviewed describe the former without detailing the latter. The second is timing: an audit trail records what happened after it happened. It supports investigation and remediation of a permission grant that was too broad. It does not stop the model from reading the date of birth during the conversation that prompted the investigation.

The standard a buyer should hold any agent platform to is a record from which a reviewer can reconstruct what the model saw at each step, what it did, and who approved any consequential action, so that access to sensitive data can be audited across the applications an agent touches rather than inferred from outputs. Salesforce's audit trail is a strong start on the prompt's journey. Whether it reaches the values inside the grounding is the question to put to the current documentation.

What do regulators and standards expect of customer data given to an agent?

Where the customer is a consumer of a financial product, the FTC's Safeguards Rule, 16 CFR Part 314, sets standards for safeguarding customer information and requires a written information security program with controls appropriate to the sensitivity of that information (FTC, current). An agent that reads full account records to answer order status questions is a new flow of customer information inside that program, which must account for who has access, why, and what limits it. Broad object access granted for convenience in testing is hard to describe as a control appropriate to the data's sensitivity.

The NIST AI Risk Management Framework takes a complementary view from the AI side. Its Map function asks organizations to identify what data an AI system is exposed to and in what context, and its Measure function asks them to assess the resulting risk with metrics suited to their own environment (NIST, 2023). For Agentforce, mapping means listing, per agent, the objects and fields the agent user can read and the fields each task uses, and treating the difference as exposure to be measured rather than as a convenience to be ignored.

Neither document names Agentforce or prescribes a mechanism. What they share is the expectation that access to customer information is justified by need and controlled accordingly. A permission set granting the whole account record for a task that uses three fields does not meet that expectation on its face. The organization, not the vendor, carries the obligation, and whether a configuration satisfies it is for its counsel and compliance officers to decide.

What does a governed environment change?

A governed environment separates what the agent user may open from what the model reads, so an Agentforce task can run against a customer record without the model receiving the date of birth, card digits or notes field the permission set allows. Permissions remain the boundary Salesforce documents, and Trailhead states that data masking for LLMs is currently disabled for agents (Salesforce Trailhead, 2026). The environment supplies the second control the page says is missing.

This class of control acts on the rendered screen. Sensitive values on the account or contact record are replaced with consistent tokens before any model reads them, and the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action, for example when a change is written back to Salesforce. A named person confirms what is tokenized and approves consequential actions such as record changes and refunds. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

The page's evidence shows why scoping alone is not sufficient. The agent user starts blank and the administrator decides what it can touch, yet evaluated agents remain prone to inadvertent use of unnecessary sensitive information once a record is open (Zharmagambetov et al., 2025). Field-level security decides which fields may be opened; tokenization decides which values the model reads inside them. The exported record answers the test the previous section proposed: the grounding the model received for one agent, one record and one task.

The environment does not alter the permission set, field-level security, the Trust Layer or the model; the permission inventory remains the first step.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design addresses the row the permission model leaves open: what the model reads inside a customer record the agent user is entitled to open. Work runs in a governed environment in the customer's cloud. When an agent opens an account record, a case or a console page, substitution happens at the render layer before any model reads the screen, so identifiers appear to the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change under Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged, so the agent user's permission set remains the organization's decision while the model's view of each record is governed separately.

Deployments are in pilot. For this page's question, a pilot on the reader's own service workflow would show, record by record, which customer values the model received as tokens, which it never needed, and which were resolved for an approved action, giving the organization a record of the model's input to set beside the Trust Layer's audit trail. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on Salesforce's own documentation: the Trust Layer page in the Agentforce developer guide, the Trailhead module on the Trust Layer, and the ISVforce guidance on securing custom actions (all vendor documentation). It also draws on trade press analysis of the Agentforce permission model from Salesforce Ben, the Meta FAIR AgentDAM benchmark published at NeurIPS 2025 (peer-reviewed), the OWASP Top 10 for LLM Applications entry on sensitive information disclosure (industry standard), the FTC Safeguards Rule at 16 CFR Part 314 (regulation), and the NIST AI Risk Management Framework (official guidance). All sources were read as of October 16, 2026.

No hands-on testing of Agentforce, the Trust Layer or any Salesforce org was performed. "Not described in the pages reviewed" concerns the documentation consulted, not a claim that the product lacks the capability. The statement that data masking is currently disabled for agents is quoted from Salesforce's Trailhead module as read on the page's date; Salesforce may change that status, and the page carries its date for that reason. Statements about RedactSure describe its current design, with deployments in pilot. The customer account record and service console examples describe record types and configurations, not any organization; no customer or prospect is described.

Whether a given agent user's permission set, field-level security, custom action design or audit coverage satisfies the Safeguards Rule or any other obligation is a determination for the organization's counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Salesforce documents an agent user that starts blank and reads only what an administrator grants, a Trust Layer whose feature list includes masking of sensitive data, and a Trailhead module stating that data masking for LLMs is currently disabled for agents. Put together, those statements mean that an Agentforce agent today reads whatever its permission set and field-level security allow, in full, and that the only thing standing between the model and a customer's date of birth is whether someone restricted that field for that agent. Permissions decide who may open the record; nothing in the pages reviewed decides what the model reads inside it. The test is to name one agent and one task, pull the grounding the model received for one account record, and ask which of those values the task used and who decided the rest should be there.

Frequently asked questions

Does Agentforce read every field on a customer record?

It reads every field its agent user is permitted to read, and the model receives whatever grounding the agent attaches. Trade press analysis describes the agent user as starting essentially blank, so the fields it can read are the ones an administrator granted, typically at the object level with field-level security left open for convenience. If that is how the agent user was built, the model reads the whole record, including fields the task never uses.

Doesn't the Einstein Trust Layer mask sensitive data?

Salesforce's developer guide lists masking of sensitive data, such as social security numbers, among the Trust Layer's features. Salesforce's Trailhead module states that data masking for LLMs is currently disabled for agents. Both are Salesforce's own statements, and the second governs the agent surface as of the module's writing. A buyer should verify the current status against the documentation for their release rather than rely on the feature list, and should plan on the permission model being the operative boundary.

What is the agent user and why does it matter?

The agent user is the dedicated Salesforce user identity an Agentforce agent runs as, carrying its own permission set and field-level security. It matters because, with masking disabled for agents, its permissions are the entire boundary on what the model can read. Salesforce's ISVforce guidance adds that service agents run as this identity, so custom actions must check end-user authorization themselves rather than inherit it from the person in the conversation.

How do I know how much data a task really needs?

List the topics the agent handles and, for each, the fields its instructions and actions reference. Compare that list with the fields the agent user can read on each object. The difference is surplus the model receives without needing it. Research on autonomous agents has found they are prone to inadvertent use of unnecessary sensitive information, so surplus is not harmless; it is material the model may draw on in ways the task never required.

Does the audit trail show what the model saw?

Salesforce's Trailhead module states that an audit trail tracks a prompt through each step of its journey, which supports investigation of what was constructed, grounded and sent. Whether the trail records the actual field values the model received, as distinct from the steps the prompt passed through, is a detail to confirm against current documentation. The trail is written after the fact, so it supports remediation of an over-broad grant rather than preventing the read.

Does the Safeguards Rule apply to an Agentforce agent?

Where the organization is a financial institution under the FTC's definition and the data is customer information, 16 CFR Part 314 requires a written security program with controls appropriate to the sensitivity of that information. An agent reading account records is a flow of customer information within that program, and the program must account for who has access and why. Whether a specific configuration satisfies the rule is a determination for the organization's counsel, not for a vendor or a research page.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.