Can your Agentforce agent see PHI that your users cannot?

Your compliance officer reviews an Agentforce pilot the way any access change gets reviewed. They pull the profiles and permission sets attached to the objects that hold PHI. They confirm field-level security on the sensitive fields. They check that the people assigned to those permission sets still do the job for which the access was granted. Everything lines up, the sign-off goes through, and the pilot goes live on a Tuesday.

That review was correct. It was also incomplete, because it covered people. An agent is not a person. In most Agentforce configurations, the agent acts within an assigned user or permission-set context of its own. The access that governs what the agent can retrieve belongs to that agent user, not to the employee who typed the question. If nobody scoped that user down to the task, it carries whatever the permission set it was handed happens to include.

The audit checklist we published in April covers the org you already have. This covers what changes the day you switch an agent on, because activation creates surfaces that did not exist when the last access review ran.

The agent is a user nobody reviewed

Least privilege for an agent means the same thing it means for a person. The agent holds the object, field, and record access its task requires and nothing it picked up along the way. In practice, agent users are provisioned quickly during a pilot, often with a permission set cloned from a broader one because that was the fastest path to a working demo. The clone survives into production.

Run the same exercise you would run for a new hire. What is this agent's job? What objects does that job touch? What fields inside those objects does it actually need to read? Then compare that answer to what the agent user can currently reach. In a healthcare org, the gap usually shows up in one direction. A scheduling or intake agent ends up able to retrieve clinical detail it was never meant to see.

HIPAA's minimum necessary standard applies to that retrieval. Every record the agent pulls and surfaces beyond what the task required is a separate instance, and instance count is what drives penalty math. An over-permissioned agent working a queue does that at machine speed for months before anyone reads a log.

Grounding decides what enters the context.

Grounding is the step where the platform enriches a prompt with CRM data in real time so the model answers from your records instead of guessing. Salesforce designed the retrieval path to honor roles, permissions, and field-level security, which is the right architecture. The question that matters for a healthcare org is narrower. Which records is this specific agent permitted to pull into context, and does that set match what the requesting user could open on their own?

When those two sets differ, the output is where the difference becomes visible. A generated summary is a new artifact assembled from records the reader may not have rights to. It renders in a component, it gets copied into a case comment, and it moves. Map the output before activation. Who sees it, where it displays, and whether it can be exported.

The operational cost here is not a single bad summary. It is that a summary is a disclosure, and it happens on every conversation the agent handles.

The transcript is a record you did not plan to keep

Salesforce's own guidance on secure Agentforce implementation is specific about this. Conversation data enrichment in event logs stores full transcripts, which is useful for audit and debugging during development. The guidance is to turn it off in production to protect sensitive data, at which point the logs show that sensitive data is unavailable.

Two obligations collide right there. You need evidence of what the agent did and who it did it for. You also cannot casually retain transcripts of conversations about patients in a store your retention policy never named. Decide which side you are on before the agent starts talking, and document the decision, because a compliance officer asked about it eighteen months later will want to see a choice rather than a default.

This connects to a gap we flagged in the April checklist. Standard event monitoring holds thirty days. HIPAA expects six years of documentation. Adding agent transcripts to a retention model that already falls short does not improve it.

The data your agent reads can carry instructions.

Indirect prompt injection uses content the agent reads as a delivery mechanism. Instructions get embedded in ordinary CRM data, the agent processes that data as part of its context, and it acts on what it reads. This has been demonstrated publicly against Agentforce using malicious instructions planted in CRM-stored records, and Salesforce responded by tightening trusted URL enforcement.

Think about which fields in a healthcare org accept text written by someone outside your workforce. Web-to-case bodies. Inbound email. Intake notes. Case comments from a portal. Those are all inputs an agent may ground on. Constrain what the agent is allowed to do with what it reads, keep its action set narrow, and treat externally writable text fields as untrusted input rather than context.

An agent that follows an injected instruction and moves a record produces an unauthorized disclosure with an audit trail showing your own system did it. That is a harder conversation with a regulator than a stolen laptop.

Where the human checkpoint sits

Agentforce supports both autonomous actions and human-in-the-loop patterns, with approvals and escalation configurable by risk and sensitivity. The design decision is not whether to use guardrails. It is which specific actions on PHI objects require a person to approve before execution, and that list should exist in writing before activation rather than after an incident.

Anything that discloses outside the covered workforce belongs behind a checkpoint. Anything that writes to a clinical field belongs behind a checkpoint. Reading to answer a scheduling question probably does not. Draw the line deliberately, because an autonomous action reversed after the fact is still a disclosure that already happened.

Do this before activation, not after

There is no quiet rollback once an agent has been generating summaries for four months. The transcripts exist. The retrievals happened. Remediation at that point means reconstructing what the agent touched, assessing whether any of it was reportable, and pausing an AI roadmap that leadership has already announced.

The work itself is not large. Scope the agent user, map the grounding set against user access, decide the transcript retention question, constrain the action list, and place the human checkpoints. A team that does that in the two weeks before activation avoids the version of this that shows up as a finding.

Equals11 runs readiness reviews on exactly this scope, and the Agentforce Readiness Score at equals11.ai is the free starting point. It looks at data, process, and governance readiness before any agent goes live.

FAQs

What is an agent user in Salesforce?

It is the user context an agent acts within. Agents are assigned a user or permission-set context, and that assignment determines what the agent can retrieve and change. It is provisioned separately from the employees who interact with the agent, which is why it often escapes a standard access review.

Does Agentforce respect field-level security?

The grounding path is built to honor roles, permissions, and field-level security. The practical risk is not that the platform ignores your access model. It is that the agent user itself was granted more access than its task requires, so the model is being honored against a permission set that was too broad from the start.

Should we store Agentforce conversation transcripts?

Salesforce recommends enabling conversation data in event logs for development and disabling it in production to protect sensitive data. For an org handling PHI, treat this as a documented decision that names where audit evidence comes from instead and how long it is kept.

Who should run this review?

Your Salesforce architect and your compliance officer, in the same conversation. The access model questions and the regulatory questions have the same answers here, and splitting the review across two teams is how the agent user gets approved by people who each assumed the other had checked it. 

Free. See what your agent would actually be able to reach. → Take it at equals11.ai.