At Dreamforce last fall, Salesforce spent considerable stage time on Agentforce's trust architecture — specifically, how agents verify each other's authority before acting on instructions. The announcement landed as expected: enterprise press covered it as a responsible AI story, a governance story, a "Salesforce takes safety seriously" story. The trust layer got a few paragraphs in most write-ups before the piece moved on to the demo reel.
The governance angle matters, but it obscures what Salesforce actually built and why the choice of where to anchor trust is the most consequential architectural decision in the product.
The consensus version of this story is: Salesforce is adding AI agents to its platform and building the trust infrastructure to go with it. That's a topic. The puzzle underneath it is this: why did Salesforce anchor inter-agent trust assertions inside the Einstein Data Cloud layer rather than at the infrastructure level, the network level, or through a dedicated identity service? What does that choice force Salesforce to do? What does it prevent? And what happens to the architecture when Agentforce agents start operating across organizational boundaries — which is, inevitably, where enterprise AI is heading?
Those are the questions this piece exists to answer.
I have no prior published record on Salesforce's platform strategy to score here. I've written about enterprise software consolidation and the general dynamics of platform leverage in cloud markets, but nothing on Salesforce specifically that I can quote and hold to account. So I'll build from the architecture itself.
Agentforce agents operate inside what Salesforce calls a "trust boundary" — a set of permissions, data access controls, and identity assertions that govern what an agent can do and on whose behalf it can act. When one agent needs to invoke another (an orchestrator agent calling a specialized sub-agent, for instance), it presents a trust token. That token isn't issued by an external identity provider, and it isn't validated at the network layer through something like mutual TLS or a service mesh. It's issued and validated by Einstein Data Cloud.
The developer documentation makes this explicit, if you read past the marketing framing. The trust token contains a set of claims about the requesting agent's data access scope — which objects it can read, which records it can modify, which customer relationships it's authorized to represent. Those claims are derived from the data permissions already established in Einstein Data Cloud. The identity assertion is, in effect, a projection of the data access model.
Your agent's identity is a function of your data residency. If your data lives in Einstein Data Cloud, your agents can get properly signed trust assertions. If it doesn't, they can't — at least not through the native trust architecture.
That's the bet. And it's a much larger bet than the product announcement suggested.
To understand why Salesforce made this choice, you have to start with what Einstein Data Cloud actually is in the company's business model, not just what it is technically. Einstein Data Cloud is Salesforce's answer to the data warehouse and customer data platform market — a layer that sits above the transactional CRM and unifies customer data across sources. In Salesforce's fiscal 2025 filings, Data Cloud is reported as part of the broader Platform and Other segment, which grew roughly 11% year-over-year. It's not broken out as a standalone revenue line, which is itself a signal: Data Cloud's value to Salesforce isn't primarily as a separate product to be sold; it's as a gravitational center that makes the rest of the platform stickier.
Salesforce has been explicit about this in earnings calls. In the Q3 FY2025 call, CEO Marc Benioff described Data Cloud as:
"the foundation of everything we're building"
A phrase that sounds like marketing but is actually a precise description of the architectural dependency being constructed. Every major Salesforce product announcement in the last eighteen months has had a Data Cloud dependency somewhere in the fine print. Agentforce is the most consequential instance of this pattern.
The business logic runs as follows: if trust tokens are issued by Einstein Data Cloud, then running agents at enterprise scale requires Einstein Data Cloud. The trust architecture is simultaneously a product bet and a data gravity strategy. The subsidy, in this case, is the architecture itself — Salesforce has made the trust layer free in the sense that it comes with Agentforce, but the cost is that you have to bring your data home.
A distinction gets lost in most coverage of enterprise AI platforms, and it's worth being precise about. There are three places you can anchor identity in a distributed agent system: the infrastructure layer (the network, the service mesh, the compute environment), the application layer (the software that orchestrates agents), or the data layer (the system that holds the records the agents act on). Each choice has a different set of implications.
Infrastructure-layer identity is how most enterprise security teams think about this problem. Mutual TLS, service accounts, zero-trust network architecture — these are all infrastructure-layer approaches. They're portable, they're interoperable, and they're largely indifferent to which application is running on top. The problem, from Salesforce's perspective, is that infrastructure-layer identity gives Salesforce no leverage. If trust is established at the network layer, any agent from any vendor can participate once it clears the perimeter. The platform becomes a commodity runtime.
Application-layer identity is how most SaaS platforms have historically handled authorization. OAuth tokens, API keys, role-based access control — the application manages who can do what. This is closer to what Salesforce could have built: an Agentforce-native identity service that issues tokens based on CRM role assignments. The problem here is that application-layer identity is only as sticky as the application. If a customer migrates to a different CRM or runs a hybrid environment, the identity model migrates with them or breaks.
Data-layer identity is the choice Salesforce made. The claim embedded in this architecture is that the most durable and meaningful identity assertion an agent can carry is one that says: "I have been authorized to act on this data, by the system that holds this data." It's a coherent claim. Data is, after all, what agents are ultimately acting on. If you want to know whether an agent should be trusted to update a customer record, the most relevant fact is whether the system holding that record has authorized the action.
The problem is that this claim only holds cleanly when the data is in one place. And enterprise data is famously not in one place.
I want to stay with a structural comparison here because I think it carries the argument.
In 2011, Amazon Web Services shipped IAM — Identity and Access Management — and made a specific architectural choice that has shaped cloud computing ever since. IAM is resource-centric: permissions attach to resources (S3 buckets, EC2 instances, Lambda functions), and identity assertions are validated by the service that owns the resource. If you want to read from an S3 bucket, the bucket's policy is the authority, not a separate identity service. Structurally, that's the same bet Salesforce is making: identity authority lives with the data, not above it.
IAM worked, and it worked durably, for a specific reason: AWS controls the infrastructure. When IAM says "this role is authorized to access this bucket," the claim is enforced by the same system that runs the bucket. There's no gap between the identity authority and the enforcement point. The architecture is coherent because it's vertically integrated all the way down.
Salesforce doesn't have that. Einstein Data Cloud sits on top of infrastructure Salesforce doesn't own — hyperscaler compute, customer-managed cloud environments, data that lives in Snowflake or Databricks or on-premise systems that feed into Data Cloud through connectors. When a trust token issued by Einstein Data Cloud makes a claim about data access scope, that claim is only as good as the completeness of the data model underneath it. If the customer's Salesforce instance is connected to a Snowflake warehouse that Einstein Data Cloud doesn't fully index, the trust assertion has a gap. The agent thinks it knows what it's authorized to do; the actual data landscape is more complicated.
My read is that Salesforce's architects know this. The bet isn't that Einstein Data Cloud will be complete — it's that it will become complete, because the trust architecture creates an incentive for customers to consolidate data there. Every data source that lives outside Einstein Data Cloud is a source of trust assertion uncertainty. Customers who want clean agent behavior will feel pressure to bring their data into the fold. The architecture is designed to make data consolidation feel like a security decision rather than a vendor lock-in decision.
That's a sophisticated move. It also has a specific failure mode.
The failure mode is cross-organizational agent interactions. Right now, most Agentforce deployments are intra-organizational: agents acting on behalf of one company's users, within one company's data environment. The trust architecture works reasonably well here. Einstein Data Cloud is the authority for one organization's data, and the agents stay inside that boundary.
Enterprise AI is not staying inside that boundary. The next wave of agent use cases is explicitly cross-organizational: a procurement agent at one company negotiating with a sales agent at another, a logistics agent at a manufacturer coordinating with a carrier's scheduling agent, a financial services agent at a bank interacting with a compliance agent at a regulatory body. These interactions require agents to present trust assertions to systems they don't control, operated by organizations that have their own data residency, their own identity authorities, their own trust architectures.
When a Salesforce Agentforce agent walks up to a cross-organizational interaction, it carries a trust token issued by Einstein Data Cloud. The counterparty — which may be running ServiceNow, or Microsoft Copilot, or a custom-built agent framework — has no reason to trust that token. Einstein Data Cloud has no authority over the counterparty's data. The trust assertion is valid inside Salesforce's ecosystem and meaningless outside it.
This is not a hypothetical problem. It's the same problem that enterprise identity has been solving, imperfectly, for thirty years: how do you establish trust between organizations that don't share an identity authority? The answer the industry settled on, eventually, was federation — protocols like SAML and later OIDC that let one organization's identity assertions be validated by another organization's systems, without requiring a shared data layer. The key insight of federation is that you don't need to share data; you need to share a protocol and a set of trust anchors.
Salesforce's current architecture is not federated in this sense. The trust assertions are data-layer assertions, not protocol-layer assertions. There's no published standard for how an external system should validate an Einstein Data Cloud trust token. There's no federation protocol that lets a non-Salesforce agent accept an Agentforce identity claim.
Salesforce knows this is coming. The Agentforce roadmap, as described in developer documentation and partner briefings, includes something called "Agent Network" — a capability for agents to interact across organizational boundaries. The details are sparse, and the timeline is vague. But the existence of the roadmap item is itself a signal that the current architecture has a known gap.
Two paths forward, and they lead to very different places.
The first path is federation: Salesforce publishes a protocol that lets external systems validate Einstein Data Cloud trust assertions, and works with the industry (or imposes on the industry, depending on its leverage) to make that protocol a standard. This preserves the "identity follows data" architecture while extending it across organizational boundaries. It requires Salesforce to give up some control — a federated protocol is, by definition, not proprietary — but it preserves the data gravity strategy because Einstein Data Cloud remains the authoritative source for Salesforce-ecosystem agents.
The second path is network effects: Salesforce doesn't federate; instead, it makes the cross-organizational trust problem go away by making Einstein Data Cloud ubiquitous. If both the buyer's agents and the seller's agents are running on Agentforce, both organizations' data is in Einstein Data Cloud, and the trust architecture works natively. This path requires Salesforce to win the enterprise AI market comprehensively — not just in CRM, but across enough of the enterprise data landscape that cross-organizational interactions are usually Salesforce-to-Salesforce.
The second path is the more aggressive bet, and I think it's the one Salesforce's business model is actually pushing toward. The economics of Einstein Data Cloud as a platform component, rather than a standalone product, only make sense if Data Cloud achieves something close to completeness within the enterprise. Partial adoption creates partial trust assertions, which creates partial agent reliability, which creates customer dissatisfaction. The architecture has a strong internal logic that points toward consolidation.
But the second path has a ceiling. There are large categories of cross-organizational interaction where both parties will not be Salesforce customers — government interactions, regulated industry interactions, international supply chains with fragmented technology landscapes. In those contexts, the "identity follows data" architecture either requires a federation layer or it fails.
The underlying dynamic here is worth naming as a reusable lens, because it shows up well beyond this specific case.
"Identity follows data" is a recognizable pattern in platform strategy: the claim that the system with the most complete view of the relevant data should be the identity authority. It's the logic behind why Google became the identity layer for much of the web (Google knows who you are because Google knows what you read, search, and watch), why Stripe became the payment identity layer for e-commerce (Stripe knows the merchant relationship), and why AWS IAM became the de facto identity layer for cloud infrastructure (AWS knows which resources exist and who provisioned them). In each case, data completeness translated into identity authority, and identity authority translated into platform leverage.
The pattern holds when data completeness is achievable. It breaks when the relevant data is structurally distributed — when no single system can achieve the completeness that would make its identity assertions authoritative. Enterprise customer data is structurally distributed. That's not a temporary condition; it's a feature of how large organizations work. Multiple CRMs, multiple data warehouses, multiple jurisdictions with different data residency requirements, multiple acquired companies with different technology stacks. The "identity follows data" bet requires either consolidating that distribution (hard, slow, expensive) or federating across it (which dilutes the data-layer authority claim).
Salesforce is betting on consolidation. The trust architecture is the forcing function. Whether it's strong enough to overcome thirty years of enterprise data fragmentation is the real question.
Which brings me to the prediction.
By the end of 2027, Salesforce will face a visible, public forcing event around cross-organizational agent trust — a major enterprise deployment, a partnership announcement, or a regulatory interaction that requires Agentforce agents to present identity assertions to non-Salesforce systems. At that point, Salesforce will either publish a formal federation protocol that accepts external identity assertions (effectively acknowledging that "identity follows data" requires a data-agnostic trust layer at the boundary), or it will announce that cross-organizational agent trust requires both parties to be Einstein Data Cloud customers, making Data Cloud a network requirement rather than a platform component.
The first outcome is a meaningful concession — it means the architecture as designed couldn't survive contact with the actual enterprise landscape. The second outcome is an aggressive consolidation play that will work in some markets and fail in others, and will generate significant regulatory attention in Europe, where data residency requirements make Einstein Data Cloud consolidation legally complicated in ways that Salesforce's current architecture doesn't fully account for.
A third outcome, where the architecture holds as-is, seems implausible. The cross-organizational case is coming too fast, and the current trust model has no answer for it that doesn't require either federation or consolidation. One of those two things will happen. The interesting question is which one Salesforce chooses, because the choice will reveal whether the "identity follows data" bet was a genuine architectural conviction or a data gravity strategy dressed up as a security decision.
My lean is toward federation, reluctantly adopted. Salesforce's history in enterprise standards — from SOAP to REST to the various CRM data standards it has participated in over the years — suggests a company that will engage with interoperability when the alternative is being locked out of large markets. The European regulatory environment alone creates enough pressure that a purely proprietary cross-organizational trust model is probably not sustainable. But federation will come late, after the consolidation play has been tried and found insufficient, and the protocol Salesforce publishes will be designed to make Einstein Data Cloud the preferred trust anchor even in a federated world.
That's the bet inside the bet. And it's worth watching closely, because the answer will tell us whether "identity follows data" is a durable principle or a transitional strategy on the way to something more federated and, ultimately, more boring.