Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Update a Customer's Address in Salesforce Without Seeing the Rest of the Record?
No, because the agent reads the rendered account page and the model receives whatever that page shows, including fields the address task never needed. Ask what the agent receives from the rendered screen, whether those values are replaced with tokens before it reads them, and which named person approves the save.
For a service team, a billing address is one field on one record, and correcting it is the smallest task it can hand an agent. The page the field sits on is a different size. A customer account record draws the customer's name, the contacts attached to the account, the open cases and the recent activity, because a record page exists to show the record rather than the one field a task names. An agent working the update reads that page, and the model receives what the page draws. Salesforce's own documentation says the masking that might narrow this is off: "Data masking for LLMs is currently disabled for agents" (Salesforce Trailhead, 2026). The answer therefore turns on the screen rather than on the field. A team that wants the change to stay inside the field has to decide what the model is shown before the run starts. Does Salesforce Agentforce Need Access to Sensitive Customer Information? works the Agentforce side of that question, and the record page is where this one is decided.
Key findings
- For an address update to stay inside the field, the values on the rendered account page would have to be replaced with consistent tokens before any model reads it, so the run works on ADDR_014 and the rest of the record renders as labels (What Is Render-Layer Tokenization?).
- It would also require a named person approving the save and a record of what the model received on each page, which is the half of the control that makes the change reviewable (What Should an AI Agent Security Review Cover?).
- Trailhead documents masking and an audit trail that "tracks a prompt through each step of its journey", and names no control that rewrites the rendered record page before the model reads it (Salesforce Trailhead, 2026).
- Salesforce Trailhead states that "Data masking for LLMs is currently disabled for agents", so the masking a buyer might assume protects an Agentforce run is not on for the agent working the record (Salesforce Trailhead, 2026).
- The ISVforce guide recommends that a custom action "always have the agent prompt the user for confirmation before proceeding", a check on the write that leaves the read untouched (Salesforce, Custom actions, 2026).
- Agentforce session tracing records "every step of an Agentforce agent interaction: turns, messages, LLM calls, actions, metric scores, and feedback", so a run's messages and model calls can be exported by the team that owns it (Salesforce, Session tracing, 2026).
What does an agent read when it opens a customer account record?
Take a record type rather than a named account: a customer account page in a CRM, with a billing address field that a service team wants corrected. The agent finds the account, confirms the page belongs to the customer named in the request, and types the new address; each of those steps reads the page. None of the 86 AI security and data protection products reviewed describes reversible tokenization of what an agent reads on a screen, so the account fields the address task did not need arrive as rendered text (How Many AI Security Products Control What an AI Agent Sees?).
What the page draws is the record's content for the identity that opened it: the account's name and owner, the contacts attached to it, the cases that reference it and the activity trail. What Is Render-Layer Tokenization? states the point: every established layer of the enterprise security stack finishes its work before a page renders, so an agent that reads the rendered page is what those layers cannot see.
The model does not receive the field. It receives the page on every step, and a run that ends with one address corrected has still read the account, the contacts and the cases. An agent that observes screenshots decides from what it sees (Who Controls What an AI Agent Sees in a Hosted or Sandboxed Browser?). An account screen built for a person carries more than the task needs, which is the finding of Is It Safe to Let an AI Agent Work Collections Accounts? on a collections queue.
Which control decides what the model receives on that page?
A record page's contents are the product of three decisions: which records the agent may open, which fields the identity may see, and what the page draws once those two are settled. The third is the one the model meets.
Authorization is the first layer. Okta describes Cross App Access as an identity protocol that "centralizes authorization in the identity provider", extended to MCP servers (Okta, 2026). It decides which application an agent may reach, not which of an account's fields the application draws once the agent is inside.
Permissions are the second layer. Salesforce Ben describes the agent user as a narrow identity: the user "starts essentially blank, and you decide what it can touch" (Salesforce Ben, 2026). That limits which records the agent can open rather than which values a page shows once one opens.
The third layer is the render. A value is either drawn on the page as itself or drawn as a substitute, and the model receives whichever one was drawn. How Can AI Agents Work With Customer Records Without Seeing the Actual Data? describes the substitution: a sensitive value is replaced with a surrogate that has no exploitable meaning on its own, while the real value stays in a separate store. A step that rewrites the rendered record page before the model reads it is not described in the pages reviewed.
What do the vendors themselves say?
Salesforce's Trailhead page for the Agentforce Trust Layer states that "Data masking for LLMs is currently disabled for agents", and that "an audit trail tracks a prompt through each step of its journey" (Salesforce Trailhead, 2026). The feature exists, and for agents it is off; the trail follows the prompt, not the page.
The ISVforce guide recommends that a custom action "always have the agent prompt the user for confirmation before proceeding" (Salesforce, Custom actions, 2026). A confirmation gates the write, and it arrives after the model has read the page.
The session tracing page records "every step of an Agentforce agent interaction: turns, messages, LLM calls, actions, metric scores, and feedback" (Salesforce, Session tracing, 2026). That is the closest thing to a record of what the model received, it is marked Beta, and a buyer should confirm the export and its retention.
| Dimension | Salesforce, per its documentation | What a buyer should verify |
|---|---|---|
| What the record page shows the model | None of the three pages names it | Which fields the rendered record draws for the agent |
| Masking for LLMs | "Data masking for LLMs is currently disabled for agents" | Whether it is enabled for the agent's identity, and what it covers |
| Approval of the action | A custom action can require "the agent prompt the user for confirmation" | Who approves, and whether the approver sees the page |
| Record of the run | "turns, messages, LLM calls, actions, metric scores, and feedback" | Whether the export is available and how long it is kept |
Who approves the address change, and what does that leave open?
An approval is the control most teams reach for first, and Salesforce gives it a documented shape: a custom action can require the agent to prompt the user for confirmation before proceeding (Salesforce, Custom actions, 2026). That shape governs the write and leaves the read alone, because the model has already read the page before it proposes the action (Does Salesforce Agentforce Need Human Approval Before Taking Action?).
Two things follow. The approver needs the page as well, since a person who cannot see the record cannot tell whether the account is the right one, and the approval has to name the field and the value.
The address is not a neutral field in every account. FINRA's rulebook requires a member to record the "customer's name and residence" for each account (FINRA, 2026). The customer identification rule requires a bank to obtain an address before opening an account and to keep the records for five years after it closes (eCFR, 2026). An address change in a CRM that feeds either process is a change to identifying information, which is why the approval carries more weight than a click.
What the approval leaves open is the read. The SEC's release describes Regulation S-P as requiring an incident response program for unauthorized access to customer information, with notice to affected individuals generally within 30 days (SEC, 2024), and a run in which a model read a record it did not need is an access to scope. That is the limit of the approval layer: it decides whether the change happens and who answered for it, not what the model read on the way to the button.
What does a governed environment change?
A governed environment is a control class that acts where the screen is rendered, before any model reads it. Values named by policy are replaced with consistent tokens for the whole run: the address renders as ADDR_014, the customer's name as ACCT_014, and the model works on those labels. Real values resolve only at an approved destination, at the moment of an approved action. A named person approves the address change, and a record of every page and every approval exports to the organization's own monitoring.
On the account record the difference is specific. The page still draws the contacts, the cases and the activity, and those fields follow the same policy as the address: the values it names arrive as labels, and the values it does not name are a decision the policy made rather than a side effect of opening the record. The agent confirms the customer by label and types the new address as a token.
The record is the second change. The environment writes what the model received page by page, with the name of the person who approved the change, so a reviewer can answer an incident question without reconstructing a transcript.
The scope is the rendered page. A record updated through the platform's API, a data load, or an export that leaves the system carries no page for the environment to govern, and a team that needs those routes covered has a different control to design.
What the record shows
The team that owns customer data controls an address change at three points: what the model receives from the rendered page, who approves the save, and what record the run leaves. On the record described here the page draws the account, the contacts and the activity, and the model receives what the page draws, so one corrected field arrives with everything else. The vendor pages describe masking that is disabled for agents, a confirmation that gates the write and a tracing export marked Beta, and each of those is a control at one of the three points rather than at the render. That team should test the question on its own system with one account: open the record with an agent attached, correct one address with test values, then read the run's trace and list every field the model was given against the three the task needed.
Methodology and limitations
This page rests on Salesforce's developer guide and Trailhead documentation, one trade account of Agentforce permissions, the SEC's release on Regulation S-P, FINRA Rule 4512, the eCFR's customer identification rule and existing RedactSure research pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor and regulatory pages were read as of October 22, 2026, and each Sources line carries the date for its page.
No product on this page was tested for this page. The products are described from their public documentation, and where a behavior is not described in the pages reviewed it means the pages in Sources. The Salesforce pages describe masking, a confirmation prompt and tracing; none was run against an account for this page, and vendor features change, so a release after this page's date is unreviewed until the test above is repeated. The example is a record type, not an organization. Determinations about what a regulation requires belong to counsel, assessors and the organization's own compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Can an AI agent update a customer's address in Salesforce without seeing the rest of the record?
No, not on the record page as it renders. The agent opens the account, confirms the customer and types the address, and each step reads a page that draws more than the field. Salesforce's Trailhead states that "Data masking for LLMs is currently disabled for agents", so the page's values are the model's values (Salesforce Trailhead, 2026). The answer changes where the page renders tokens and a person approves the save.
What does the model receive when the agent opens the account?
Whatever the page draws for the identity that opened it. On a customer account that is the customer's name, the contacts, the open cases and the activity trail, with the address field among them. The model does not receive the field alone. Session tracing records the turns, messages and model calls of a run, where those values would sit (Salesforce, Session tracing, 2026). Read that trace after a test run and count the fields the task never needed.
Does a permission setting keep the rest of the record out of the model?
Only for the records and fields the identity cannot open. Salesforce Ben describes the agent user as one that "starts essentially blank, and you decide what it can touch" (Salesforce Ben, 2026), which narrows reach: a user that cannot open an account cannot read its page. For an account the agent has to open, the page renders the fields that identity may see. Whether those values are replaced before it reads them is a question for a test on one account.
Do confirmations and narrow permissions change the answer?
No. Both are worth having, and neither changes what the model read. A custom action can require that the agent prompt the user for confirmation before proceeding (Salesforce, Custom actions, 2026), and that gate opens after the page has been read and the value proposed. A narrow agent user limits which records the agent can reach, and the accounts it must reach still render their pages. The answer turns on the values drawn on the page.
What record of the agent's work exists after the run?
Agentforce session tracing records "every step of an Agentforce agent interaction: turns, messages, LLM calls, actions, metric scores, and feedback" (Salesforce, Session tracing, 2026), and Trailhead describes an audit trail that "tracks a prompt through each step of its journey" (Salesforce Trailhead, 2026). Messages and model calls are where a record page's values would appear. The tracing page is marked Beta, so confirm availability and retention with the account team. A record of what the model received is the one a reviewer needs.
What should a security team ask for in writing before an agent updates addresses?
Four answers: what the model receives from a rendered screen at each step; whether the values a policy names are replaced before it reads them; who approves the save and whether that person sees the page; and what record of the pages and approvals can be exported. Ask per workflow, because a permission that covers one record type says nothing about another's. Treat an answer the documentation does not support as open until a test confirms it.
How RedactSure Keeps the Rest of the Account Off the Address Change
An agent that corrects one address still reads a page carrying the customer's contacts, cases and activity, and the pages reviewed leave the render alone. Salesforce's own Trailhead page says masking for LLMs "is currently disabled for agents".
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the page draws the address, the contacts and the cases into the model's context, and the run keeps them. Inside, it draws ADDR_014 and ACCT_014, a named person approves the change against a page that shows the record's shape, and the real address resolves once at the save, with every page and approval in the record.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A one-field edit still pulls a whole record page into the model's context. Bring one record your team updates and see, with test values, what the model reads and who approves the save. Book a demo