Agentforce Data Governance: Coverage, Gaps, and the Context Layer

---

Atlan’s context layer research maps exactly where Agentforce’s own governance authority stops. Agentforce enforces data governance through the Einstein Trust Layer and Data 360’s Policy-Based Governance: secure data retrieval, attribute-based policy rules, dynamic data masking at query time, and audit logging. Salesforce lists Agentforce as a Covered Service in the Einstein Platform and Agentforce SOC 2 and SOC 3 reports. According to Gartner (2026), 40% of enterprises will demote or decommission AI agents by 2027 over governance gaps discovered only after production incidents. That coverage holds only as far as Data Cloud’s ingested or Zero-Copy-federated footprint. Once data lives in Databricks, Snowflake, Microsoft Purview, or Collibra outside that boundary, Atlan’s context layer is what carries policy enforcement and lineage across the systems Agentforce’s own governance doesn’t reach.

Salesforce’s investment here is substantial. The Einstein Trust Layer grounds prompts through secure data retrieval that respects the executing user’s permissions and field-level security, holds a zero data retention agreement with external model providers, screens for toxicity, and logs agent interactions for audit. One control it does not apply to agents is masking, and Salesforce says so plainly: pattern-based and field-based masking for LLMs is disabled for agents. What Salesforce Agentforce is and how it’s architected matters here, since Data 360’s Policy-Based Governance enforces field, object, and record-level rules across the UI, API, and agent access paths through attribute-based access control, including dynamic data masking applied at query time. Where that coverage runs out, for data an agent needs but Data Cloud hasn’t ingested, is the question this page answers.

• Einstein Trust Layer: secure data retrieval, prompt defense, toxicity detection, audit logging; zero retention with external model providers
• Data 360 Policy-Based Governance: field/object/record-level enforcement, UI to API to agent, plus dynamic data masking at query time
• Execution context: a dedicated Agent User for customers who aren’t logged in, the end user’s own permissions on an authenticated Experience Cloud site
• SOC 2 and SOC 3: Agentforce is a Covered Service in the Einstein Platform and Agentforce reports
• Coverage boundary: only as far as Data Cloud has ingested or federated

---

What is Agentforce data governance?

Agentforce data governance is the combination of Salesforce controls that decide what an AI agent can see, touch, and log inside the Salesforce ecosystem: the Einstein Trust Layer, Data 360’s Policy-Based Governance, and an execution context that varies by agent type.

The Einstein Trust Layer sits closest to the model. It grounds prompts through secure data retrieval scoped to the executing user’s permissions and field-level security, defends against prompt injection through system policies in Prompt Builder, screens for toxicity, and logs interactions for audit. It does not mask data for agents. According to Salesforce Help (2026), pattern-based and field-based masking for large language models is disabled for agents, and a prompt template called through an agent action has masking disabled too (more on why below). The same documentation states that information sent to the model is not retained, viewed, or used for training by the provider once the response comes back. Data 360’s Policy-Based Governance sits one layer down, at the data platform itself, enforcing field, object, and record-level rules the same way whether an agent, an API call, or a human user is asking.

Einstein Trust Layer

Zero data retention with external model providers, toxicity detection, prompt defense, and audit logging apply across Agentforce interactions, not just chat. LLM data masking does not: Salesforce disables it for agents, and the field-level protection that remains is Data 360’s dynamic data masking at query time. Salesforce Engineering (2026) describes the broader stack as unifying governance once enforced in separate silos across Agentforce, Data 360, MuleSoft, and Informatica, Salesforce’s own acknowledgment that the unification is recent.

Data 360 Policy-Based Governance

Policy rules here are what a compliance team would point to first: what makes an AI governance framework enforceable rather than aspirational, covered by real SOC 2 and SOC 3 reports, not a marketing claim. Salesforce documents the model behind it as attribute-based access control, with AI-recommended classification tags marking data as HIPAA, GDPR, or PII, and policies that apply automatically everywhere in Data 360.

This is real, substantial governance investment. It’s not the whole picture; it’s the picture inside one platform’s boundary, and where that boundary sits matters more than whether the investment is genuine.

---

How does Agentforce enforce permissions for agent actions?

Agentforce’s execution context depends on the agent type and on whether the end user is authenticated. According to Salesforce Help (2026), Agentforce Service agents serving unidentified or verified-but-not-logged-in customers run as a dedicated Agent User, the EinsteinServiceAgent User, whose profile, permission sets, field-level security, sharing rules, and org-wide defaults govern what the agent can read and edit. Only an end user authenticated on an Experience Cloud site causes the agent to run under that person’s own permissions. Underneath either path, Data 360’s Policy-Based Governance applies dynamic data masking at query time, obfuscating sensitive fields based on user context or policy rules without altering the stored data, a stronger enforcement point than masking only at the prompt.

Permission-set and attribute-based policy rules

RBAC answers “what can this role do.” ABAC layers in “under what conditions”: data classification, time of day, request context. Combined, they land closer to a zero trust data governance posture than a simple allow-list.

Audit trail and Command Center

Two surfaces, two jobs. The Einstein Trust Layer Audit Trail is the audit control that records agent interactions. Command Center is the observability product: live analytics for latency, escalation frequency, and error rates, real-time alerts, session tracing, deployment status, adoption analytics, and cost tracking. Compliance teams should point at the audit trail, operations teams at Command Center.

Why Salesforce disables data masking for agents

Salesforce publishes this openly, in a dedicated help article and an IMPORTANT callout on the Trust Layer overview: pattern-based and field-based data masking for large language models is disabled for agents, unconditionally. The stated reason is accuracy. Masking “can affect the accuracy and relevance of the agent’s response because the context needed for the response is masked,” and Salesforce’s own example is an agent asked to build a list of similar accounts, where masking the reference account removes the basis for the comparison. That makes the enforcement point Data 360’s dynamic data masking at query time rather than Trust Layer masking at the prompt. It’s the same tension covered in how to handle PII in AI pipelines: policy must enforce access without destroying the data an agent needs to reason correctly.

Agent access is governed well within Salesforce’s own identity boundary. The open question is what happens once that same agent needs a resource outside it, which is exactly where AI agent identity governance and Agentforce’s own model diverge.

---

Agentforce data governance vs. a cross-system context layer: what’s the difference?

Agentforce’s governance and a cross-system context layer aren’t competitors. They operate at different boundaries, and conflating them is exactly what leaves enterprises exposed when data moves between systems.

The clearest evidence that Salesforce itself sees this gap is in its own architecture guidance. The Data 360 interoperability decision guide tells customers to enforce governance at the source, using row-level security and masking policies directly within federated systems, and to make those systems’ security policies match what Salesforce requires. Salesforce is saying, in its own documentation, that federating access does not federate enforcement. The 2026 Salesforce-Databricks partnership is framed around the same problem: “when data lives across multiple platforms, security rules, identities, and permissions have to be recreated for each system.” Zero copy federation into Snowflake, BigQuery, Redshift, and Databricks is real, meaningful progress toward closing it.

A context layer doesn’t replace Agentforce’s runtime governance. It’s the substrate that makes policy and lineage portable to whatever Agentforce, or any other agent runtime, hasn’t ingested yet, the same reasoning behind why AI agents need an enterprise context layer in the first place. An Enterprise Data Graph doesn’t ask which platform an agent happens to be running on before it enforces a policy; that consistency, not raw feature overlap, is the actual difference between the two layers.

---

Where does Agentforce’s data governance stop?

Agentforce’s governance is enforced consistently only within what Data Cloud has ingested or Zero-Copy-federated. Everything past that boundary is a genuine, currently open gap, not a solved problem and not a fabricated one. According to Gartner (2026), 40% of enterprises will demote or decommission autonomous AI agents by 2027 due to governance gaps discovered only after production incidents. Shiva Varma, Senior Director Analyst at Gartner: “Enterprises are treating AI agent governance as binary, either locked down or fully trusted, and that is the root cause of failure.” Separately, Gartner (2025) projects over 40% of agentic AI projects will be canceled by the end of 2027, citing cost, unclear value, and inadequate risk controls.

According to Cybersecurity Insiders (2026), only 8% of tech leaders report having strong AI governance in place today. That gap isn’t unique to Agentforce, and it isn’t closed by Agentforce’s stack either; it lives at the level of the enterprise’s full agent estate, not one platform’s boundary.

Cross-system permission consistency once data lives outside Data Cloud

Zero-Copy federation moves data access across the boundary. It doesn’t automatically move policy enforcement with it, which is why connecting enterprise data sources to LLMs securely has to be treated as a distinct governance problem.

Non-human identity sprawl and why agent identity isn’t human identity

According to the Cloud Security Alliance (2026), non-human identities now outnumber human identities by an average of 45 to 1, a ratio that climbs to 144 to 1 in cloud-native environments. Salesforce governs its own agent identity properly: the Agent User has an Einstein Agent license, an Einstein Agent User profile, its own permission set group, an assigned role for record access, minimal access by default, no interactive login, and attribution in Created By, Last Modified By, and Owner fields. The gap is reach, not rigor. An agent identity governed inside Salesforce is still only governed inside Salesforce, and the same agent reading a warehouse table needs an identity and a policy Salesforce’s user model does not extend to.

EU AI Act Articles 12 and 26 traceability: what Command Center captures vs. what compliance teams need to prove

The EU AI Act requires high-risk AI systems to support automatic event logging for traceability under Article 12, and separately requires deployers to retain those logs for a minimum of six months under Article 26(6), unless other EU or national law sets a longer period. According to AI2sql (2026), compliance teams increasingly expect that trail to be attributable and tamper-evident by design, not just present. Salesforce documents the Einstein Trust Layer Audit Trail for agent interactions and Command Center for observability, both scoped to Agentforce itself. A single trail spanning Agentforce, Databricks, Snowflake, and whatever else an enterprise’s agents touch is the enterprise’s own to assemble, the gap EU AI Act compliance work has to close. Salesforce’s published compliance scope is wider than the SOC 2 report alone. Agentforce is a Covered Service in the Einstein Platform and Agentforce SOC 2 and SOC 3 reports, and Salesforce states it is HIPAA eligible and covered under the Salesforce Business Associate Addendum Restrictions, with ISO 27001, 27017, and 27018 certifications. None of that extends to data an agent reaches outside Salesforce, which is where the adjacent GDPR and HIPAA obligations land back on the enterprise.

Agentforce’s governance is consistently enforced inside Data Cloud’s ingested or federated footprint. Past that line, cross-system permission consistency, non-human identity, and audit-trail traceability are open problems Salesforce is still building toward, not ones it has solved.

This doesn’t mean Agentforce’s governance is weak; it means it’s scoped, and enterprises that treat platform-native governance as if it automatically extends everywhere an agent touches are the ones landing in Gartner’s 40% by 2027. Salesforce’s own architecture guidance says the same thing in its own vocabulary: for federated data, enforce governance at the source through row-level security and masking policies applied directly within the federated system. The responsibility moves with the data.

---

How to close the governance gap beyond Agentforce’s boundary

Closing the gap starts with mapping exactly what Data Cloud has and hasn’t ingested, then extending policy and lineage to the rest, rather than assuming Agentforce’s governance travels with the data.

Before you start:

• Inventory which systems feed Agentforce via Data Cloud ingestion, Zero-Copy federation, or neither
• Identify which agents act with human-invoked permissions versus autonomous, non-human-identity permissions
• Map current audit-log retention against the EU AI Act’s Article 26(6) six-month minimum

Five steps:

1. Map the boundary. Confirm exactly which data Agentforce’s governance actually reaches today, not which data it could theoretically reach.
2. Extend policy context to ingested-but-unfederated systems via a shared context layer, so enforcement doesn’t reset at every platform edge.
3. Resolve cross-system definition drift, “active account” meaning one thing in Data Cloud and another in the warehouse, before an agent acts on it.
4. Close the non-human-identity gap with agent-specific identity and permission lifecycle management, not borrowed human RBAC.
5. Wire audit logs from outside-the-boundary systems into a tamper-evident trail, retained to the EU AI Act’s Article 26(6) six-month minimum, that spans every platform an agent touches.

Three mistakes show up repeatedly once teams start this work:

1. Assuming Zero-Copy federation means governance is fully unified. It moves data. Verify that policy enforcement, not just data access, travels with it.
2. Assuming Trust Layer masking protects agent prompts. Salesforce disables LLM masking for agents and says why: masking removes context the agent needs to answer. Enforce policy through Data 360’s query-time controls instead of relying on masking at the prompt.
3. Applying uniform governance across every agent regardless of risk tier. Gartner’s own guidance warns that uniform governance itself causes failure; tier controls by risk instead.

Salesforce’s own decision guide for federated data points the same way: enforce governance at the source, through row-level security and masking policies inside the federated system, matching what Salesforce requires. Securing the platform correctly and stopping there leaves the rest of the estate ungoverned. Preparing data before agents touch it closes most of this gap before it becomes an incident.

---

How to choose the right governance layer for agents beyond Agentforce

Selecting what closes the gap comes down to reach, identity handling, audit granularity, and semantic consistency, not whether a tool duplicates Agentforce.

Five questions worth asking any vendor in this category:

1. Does this cover systems Data Cloud hasn’t ingested or federated?
2. How does it handle non-human identity lifecycle, distinct from human RBAC?
3. Can it produce EU AI Act-grade audit trails, Article 12 logging plus Article 26 retention, spanning multiple platforms?
4. How does it enforce policy at query time, given that Salesforce disables LLM masking for agents?
5. Does it resolve business-term definitions consistently across every system an agent touches?

Teams evaluating this space are usually also weighing how to secure multi-agent systems and broader AI agent risks and guardrails; this is one part of that larger evaluation, not a separate purchase.

---

How Atlan approaches governance beyond the Agentforce boundary

The investment behind Agentforce’s governance is real and improving fast, but its reach is scoped to what Data Cloud has ingested or federated. Enterprises whose agents, Agentforce included, need to reason over data across Databricks, Snowflake, Microsoft Purview, and Collibra hit a governance seam: permissions, definitions, and audit trails don’t travel with the data once it crosses that boundary. That seam is also where AI agent accuracy problems start, since an agent reasoning over ungoverned data is guessing, not answering.

Atlan’s Enterprise Data Graph gives cross-system lineage and ownership spanning every connector, not just Salesforce-native ones. Policy context enforces access rules at the point an agent queries data, before it reaches the model, as row and column-level policy context rather than IAM alone. Active Ontology resolves what a business term means, “customer,” “active account,” before an agent acts on it, closing the cross-system definition gap Agentforce’s CRM-scoped governance can’t reach alone. A native Atlan MCP server gives Agentforce, or any agent runtime, an external source of governed context Data Cloud alone doesn’t hold, the pattern Salesforce’s own Data 360 MCP Server points toward for its own ecosystem.

Atlan is a Leader in the 2026 Gartner Magic Quadrant for D&A Governance Platforms and the Forrester Wave for Data Governance, Q3 2025, analyst recognition distinct from any category label. General Motors, Workday, Mastercard, Nasdaq, and Virgin Media O2 use Atlan for governed AI context generally; none is a confirmed Agentforce-specific pairing. They’re cited as evidence of Atlan’s track record extending governed context across a full data estate, at the scale scaling AI agents from POC to production requires, not as an Agentforce case study.

---

Real stories from real customers: context governance beyond the CRM boundary

---

Where Agentforce’s governance ends is where the real work starts

Salesforce’s investment in this stack is substantial and genuinely improving. The Einstein Trust Layer, Data 360 Policy-Based Governance, a governed Agent User backed by RBAC and ABAC, and real SOC 2 and SOC 3 coverage are not marketing claims; they’re audited, documented, and getting better every quarter, including through the new Databricks partnership and zero copy federation.

None of that changes where the boundary sits. Enforcement is consistent inside what Data Cloud has ingested or federated. Past that line, permissions, definitions, and audit trails don’t travel automatically, and that’s a currently open gap for every enterprise running agents across more than one platform, not a flaw specific to Agentforce. The multi-cloud context layer question, and the data sovereignty questions that come with it, are exactly what enterprises still have to answer themselves once an agent’s reasoning crosses that line.

The teams that get ahead of Gartner’s 40% figure are the ones treating the boundary as a known, mapped fact rather than an assumption. Context engineering is what makes that boundary explicit instead of discovered after an incident, and making AI agents genuinely context-aware depends on closing it deliberately, not on hoping Data Cloud’s ingestion eventually catches up to every system an agent needs.

---

FAQs about Agentforce data governance

1. What is Agentforce data governance?

Agentforce data governance is the set of Salesforce controls that decide what an AI agent can access, act on, and log: the Einstein Trust Layer (secure data retrieval, prompt defense, toxicity detection, audit logging, and zero data retention with external model providers), Data 360’s Policy-Based Governance (field, object, and record-level enforcement built on attribute-based access control), and an execution context that depends on the agent type and on whether the end user is authenticated.

2. Does Agentforce access data outside Salesforce?

Yes, through Data Cloud ingestion and Zero-Copy federation into platforms like Snowflake and Databricks. Governance enforcement is consistent only as far as that ingested or federated footprint reaches; data an agent needs that Data Cloud hasn’t touched sits outside Agentforce’s own governance model.

3. What is the Einstein Trust Layer?

The Einstein Trust Layer is Salesforce’s governance layer sitting closest to the model. It grounds prompts through secure data retrieval that respects the executing user’s permissions and field-level security, defends against prompt injection through system policies, screens for toxicity, and logs agent interactions for audit. Salesforce holds a zero data retention agreement with external model providers such as OpenAI, so data sent to the model isn’t retained or used to train it. What the Trust Layer does not do for agents is mask data: Salesforce documents that pattern-based and field-based masking for LLMs is disabled for agents.

4. Is Agentforce SOC 2 or HIPAA compliant?

Both. Salesforce states that Agentforce is included as a Covered Service in the Einstein Platform and Agentforce SOC 2 and SOC 3 reports. It also states that Agentforce is HIPAA eligible and covered under the Salesforce Business Associate Addendum Restrictions, and that it holds ISO 27001, 27017, and 27018 certifications. None of that extends compliance obligations to data an agent reaches outside Salesforce.

5. Does data masking work with Agentforce?

Not at the model layer. Salesforce documents that pattern-based and field-based data masking for large language models is disabled for agents, and that when a prompt template is called through an agent action, data masking is disabled. The stated reason is accuracy: masking removes the context the agent needs, so a masked reference record can leave the agent unable to answer. Policy still gets enforced, through Data 360’s Policy-Based Governance and its dynamic data masking at query time, rather than through Trust Layer masking at the prompt.

6. How does Agentforce log or audit agent actions?

Two different surfaces do two different jobs. The Einstein Trust Layer Audit Trail is the audit control, capturing agent interactions for compliance review. Command Center is the observability surface: latency, escalation frequency, error rates, session tracing, deployment status, adoption, and cost. Both operate within Salesforce’s own boundary.

7. Does Agentforce comply with the EU AI Act?

Agentforce’s Command Center captures its own actions, but the EU AI Act’s logging requirement (Article 12) and its six-month minimum retention obligation (Article 26(6)) apply to an enterprise’s full AI agent estate, often spanning more than one platform. Enterprises running agents across Agentforce and other systems need a trail that covers all of them, which Command Center alone was not built to provide.

8. What governance gaps do enterprises hit with Agentforce?

The three recurring gaps are cross-system permission consistency once data lives outside Data Cloud’s footprint, non-human identity management (agents borrow human permissions rather than having their own governed identity lifecycle), and EU AI Act-grade audit trails spanning multiple platforms. All three are addressed by extending a governed context layer past Agentforce’s own boundary, not by anything Agentforce’s native controls cover today.

---

Sources

1. Einstein Trust Layer: Designed for Trust, Salesforce Help (2026)
2. Data Masking Limitations in Agentforce, Salesforce Help (2026)
3. Agentforce Considerations (editions, compliance scope, HIPAA, ISO, agent limits), Salesforce Help (2026)
4. Configure Service Agent Access (Agent User, profile, permission sets, execution context), Salesforce Help (2026)
5. Policy-Based Governance in Data 360, Salesforce Help (2026)
6. Data 360 Interoperability Decision Guide, Salesforce Architects (2026)
7. Agentforce Command Center, Salesforce (2026)
8. Building an Enterprise Agent Platform: Enforcing Governance, Salesforce Engineering (2026)
9. Salesforce and Databricks Build the Shared Foundation for Human and AI Agent Work, Salesforce (2026)
10. Gartner Says Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure, Gartner (2026)
11. Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027, Gartner (2025)
12. The EU AI Act and AI Agent Audit Trails: What August 2026 Means for Database Access, AI2sql (2026)
13. EU AI Act, Article 12 - Record-Keeping
14. EU AI Act, Article 26 - Obligations of Deployers of High-Risk AI Systems
15. AI Governance Forrester 2026 Threats, Cybersecurity Insiders (2026)
16. CSA Whitepaper: Non-Human Identity and Agentic AI Governance, Cloud Security Alliance (2026)