AI agents for HR service: the confidentiality problem the service playbook ignores

An employee messages HR at 11pm with a simple question. They want their remaining vacation days, and whether the balance carries into next year. That question is trivial, and an agent should answer it instantly. Salesforce shipped Agentforce HR Service to do exactly that, with an Employee Portal, an HR Service Console, and out-of-the-box HR topics and actions.

Now change one detail. A manager messages the same agent: “how many vacation days does Priya have left, and what’s her salary band?” If the agent answers the second question the way it answered the first, you don’t have a productivity win. You have a data breach with a friendly tone.

That gap is the whole job. An HR service agent is not a customer-service agent pointed at employees. A customer agent serves one external person about their own account. An HR agent serves an entire workforce, and every employee in it must see their own record and no one else’s.

The confidentiality boundary is the architecture. Build it wrong and the agent is faster at leaking than any human ever was.

So the design principle to fix before you write a single topic: an HR agent must run as the employee who is asking, inside that employee’s own permissions, and it must escalate anything sensitive to a human instead of resolving it. Everything below is how to hold that line.

Why HR data breaks the standard agent pattern

Most Agentforce service builds use a dedicated agent user, a service identity with its own scoped permissions, because the customer on the other end has no Salesforce login. That pattern is documented, sensible, and wrong for HR.

The reason is that HR confidentiality is per-employee, not per-object. It isn’t enough to say “the agent can read the Employee object.” Row-level access is the point: this employee reads this employee’s compensation, leave, and performance rows, and no one reads a peer’s. A single service user with broad read access collapses that distinction the moment two different people talk to the same agent.

So for internal HR, prefer the model where the agent runs as the logged-in employee. This is the same design that governs Slack, where the only agent you can deploy is an Employee Agent that runs as the person who invoked it. The agent inherits that employee’s object permissions, field-level security, record sharing, and role hierarchy.

Priya’s agent sees Priya’s rows. Her manager’s agent sees what her manager is already entitled to see in Salesforce, and nothing the role hierarchy doesn’t already grant.

That single choice does most of the security work, because it reuses the access model your org already maintains instead of inventing a second one for the agent to get wrong. We walk through the running-user mechanics in the Agentforce agent user, and for an HR build that post is the prerequisite, not the appendix.

Model the data so “own record” is enforceable

Running as the employee only protects you if the sharing model distinguishes one employee’s data from another. In a lot of orgs the HR objects were built for the HR team, who can see everyone, so the row-level controls that stop peer-to-peer visibility were never needed. An employee-facing agent needs them.

Three controls carry the weight:

Record ownership or sharing keyed to the employee. The employee’s own user record should grant access to their compensation, leave, benefits, and case rows, through ownership, a sharing rule, or a restriction rule. Default org-wide access on sensitive HR objects should be Private.
Field-level security on the fields that must never surface. Salary band, bank details, national ID, disability and accommodation flags, medical leave reason, and investigation notes. FLS is inherited by the agent, so a field the employee can’t read is a field the agent can’t repeat.
A separation between HR staff and everyone else. The HR team’s wide access lives on their permission sets, not on the employee baseline. The agent running as an HR specialist can legitimately see more, which is why the HR Service Console and the Employee Portal are different surfaces with different running users.

The test for this section is blunt. Log in as a normal employee, open the record pages the agent will ground on, and confirm you cannot see a colleague’s protected fields with your own eyes. If you can, the agent will too. Fix the sharing model before you tune a prompt.

Ground on policy, not on people

An HR agent answers two very different kinds of question, and they need two different grounding sources.

The first is policy. “What’s the parental leave policy in Germany?” That answer lives in documents, and it’s the same for everyone, so ground it on a knowledge corpus. Load the handbook, the benefits summaries, and the country-specific policies into a Data Library or a retriever so the agent quotes the current policy instead of improvising. Policy content is safe to share broadly, which makes it the easy half.

The second is the employee’s own data. “How many days do I have left?” That answer lives in records, and it’s different for every person, so it must come through the running-user-scoped record access above, never through the knowledge corpus. Keep the two strictly separate.

The failure mode you’re preventing is a personal balance, or a manager’s note, ending up indexed in a retriever where the wrong person can pull it into an answer. Personal data belongs in records with row-level security, not in a search index.

Connect the HRIS without widening the blast radius

Most HR data of record lives in a system that isn’t Salesforce. Workday, SAP SuccessFactors, or another HRIS holds the authoritative balances and profiles. Salesforce and Workday have announced a joint AI employee-service agent precisely because this integration is the hard part, and a real deployment usually spans both.

Two rules keep the integration from becoming the leak.

Reads should be scoped to the requesting employee at the source. When the agent calls the HRIS for a balance, the call should carry the employee’s identity and return only their record, rather than fetching a broad set and filtering in Salesforce. A wide read that trusts downstream filtering is one misrouted action away from the wrong person’s data. Design the external service or API action around a single-employee contract.

Writes need a higher bar than reads. Updating an address is low-risk and a good candidate for automation. Changing a beneficiary, a bank account, or a tax election is a fraud and error surface, and those should be confirmed and, for the highest-risk changes, routed to a human rather than executed by the agent alone. The idempotency discipline that keeps a retry from double-submitting matters more here than in most builds, because a duplicated payroll change is a real paycheck.

The topics that must always reach a human

Some HR conversations should never be resolved by an agent, no matter how good the model is. Getting this list right is a compliance requirement, not a nicety.

Route these to a person, every time:

Harassment, discrimination, or any grievance, including anything that reads like a whistleblower report.
Medical information, disability accommodations, and leave tied to a health condition.
Investigations, performance-management actions, and terminations.
Anything involving a minor, a legal hold, or a regulator.

The mechanism is topic design plus guardrails. Give these subjects their own topic whose only action is a warm handoff to the right HR specialist, with the context attached. Add a guardrail that blocks the agent from answering substantively even if a user phrases the request as a policy question.

The human-in-the-loop scoping here isn’t about model accuracy. An employee disclosing harassment deserves a person, and the legal exposure of an agent mishandling it dwarfs any deflection savings. Pair the topics with Trust Layer guardrails so a sensitive disclosure is detected and redirected, not logged into a transcript the wrong way.

What to measure, and what not to

The tempting KPI is deflection: how many HR tickets the agent closed without a human. It’s the wrong headline metric for this build.

The metric that matters is zero cross-employee disclosures. One incident where an employee learns a colleague’s salary or leave status from your agent will end the program faster than any adoption number will save it. Instrument for it: audit a sample of transcripts for whether the agent ever surfaced data outside the requesting employee’s entitlement, and treat a single hit as a stop-the-line defect.

Deflection and time-to-answer are fine secondary numbers, and they’ll be good, because the routine questions HR fields are repetitive. This is the same assistive-before-autonomous logic that makes an IT service agent a safer first internal deployment than a customer-facing one: the audience is authenticated, the questions are bounded, and the wins are real. HR just adds a confidentiality constraint that IT mostly doesn’t, and that constraint is the design.

Where I’d start

Stand up the policy agent first. Ground it on the handbook, run it as the employee, let it answer the benefits-and-policy half of the volume, and keep it entirely out of personal records for the first release. It’s useful on day one and it can’t leak, because it isn’t reading anyone’s data.

Then add personal-data topics one at a time, each gated behind a test where you log in as an ordinary employee and try to make the agent tell you something about someone else. When you can’t, ship that topic. When you can, you found the bug before an employee did. That order, safe by construction first, sensitive data earned one topic at a time, is how an HR agent becomes the thing employees trust rather than the thing legal shuts down.

Understanding the basics

Should an HR agent run as the employee or as a service user?

For an employee-facing HR agent, run it as the logged-in employee so it inherits that person’s field-level security, record sharing, and role hierarchy, and can only see their own data. A dedicated service user, common in customer-facing builds where the person has no Salesforce login, is the wrong default for HR because confidentiality is per-employee and a shared identity collapses the row-level distinction between one worker’s data and another’s. HR staff surfaces like the HR Service Console legitimately run with wider access; the employee portal should not.

What is Agentforce HR Service?

Agentforce HR Service is Salesforce’s employee-service offering built on Service Cloud, combining an Employee Portal and an HR Service Console with a set of out-of-the-box HR topics and actions, and it can meet employees inside Slack or the portal. Salesforce and Workday have also announced a joint AI employee-service agent so an agent can act across the CRM and the HRIS. It handles routine questions like leave balances, benefits, and policy, while sensitive matters are meant to route to a human.

How do you stop an HR agent from leaking one employee’s data to another?

Model the HR objects with private org-wide defaults and sharing keyed to the employee, apply field-level security to sensitive fields like salary and medical leave, run the agent as the requesting employee so it inherits those controls, and keep personal data in records rather than in a knowledge retriever. Then verify by logging in as an ordinary employee and confirming you cannot see a colleague’s protected fields, because the agent sees exactly what that user sees. Treat any cross-employee disclosure in transcript audits as a critical defect.

Which HR requests should an agent never handle alone?

Harassment and discrimination complaints, whistleblower reports, medical and disability information, leave tied to a health condition, investigations, performance actions, terminations, and anything involving a minor, a legal hold, or a regulator. These should have dedicated topics whose only action is a warm handoff to the right specialist, plus guardrails that stop the agent from answering substantively even when the request is phrased as a general policy question.

If you’re building an employee-service agent and the confidentiality boundary worries you more than the chat, that’s the right instinct. Talk to us about an HR agent designed running-as-the-employee, with the sharing model and escalation topics that keep it safe, or see how our Agentforce practice scopes agents to least privilege against real orgs.