Salesforce announced Agentforce 2.0 at its Dreamforce conference in late 2025 with a capability that received less attention than it deserved. A primary agent — the orchestrating AI that a company deploys to handle, say, customer service or sales pipeline management — can now spawn sub-agents, hand them scoped authorization tokens, and direct them to act within the customer's data environment on its behalf. The primary agent decides what the sub-agent can see, what it can modify, and how long its authorization lasts. The sub-agent executes. The primary agent reports back.
The demos were impressive. Salesforce showed a service agent spawning a billing sub-agent to process a refund while simultaneously spinning up a logistics sub-agent to reroute a shipment, all within a single customer interaction, all without a human touching the workflow. The audience understood it as automation: more tasks completed, fewer humans in the loop, faster resolution times. That understanding is accurate. It is also, I think, the least interesting thing about what Salesforce built.
Here is the question I kept returning to while reading through the Agentforce 2.0 documentation: when the primary agent hands an authorization token to a sub-agent, who authorized that handoff?
The answer, structurally, is: the primary agent did. And the primary agent was authorized by the enterprise administrator who configured it. But that administrator made decisions about what the primary agent could do. They did not, in any meaningful sense, make decisions about what the sub-agents it might later spawn could do. Those decisions were delegated. And the access model that governs the whole system — the permissions framework, the role assignments, the data scoping rules — was built for a world where a human sat at the root of every authorization decision.
That world is gone. The question is whether anyone has built the infrastructure to replace it.
The Obvious Read, and Why It's Incomplete
The consensus narrative on Agentforce 2.0 runs roughly like this: Salesforce is deepening its AI moat by making its platform capable of more autonomous, more complex workflows. The more an enterprise relies on Salesforce agents to run its operations, the harder it becomes to leave. Switching costs compound. The platform becomes stickier. This is a reasonable read of the competitive dynamics, and I don't think it's wrong.
It's just not where the structural weight of the announcement sits.
The automation is the output. The authorization architecture is the mechanism. And the authorization architecture that Agentforce 2.0 requires is categorically different from anything a single-agent system was designed to provide — not a version upgrade, not an incremental extension, but a different kind of problem that the existing access model cannot solve.
The difference becomes visible once you understand what single-agent authorization actually assumes.
When an enterprise deploys a single AI agent — any agent, on any platform — the authorization model works roughly like this: a human administrator defines a set of permissions (what data the agent can read, what actions it can take, what systems it can touch). The agent operates within those permissions. If the agent tries to do something outside its defined scope, the system refuses. The human is the root of the authorization tree. The agent is a leaf. The access model is designed to enforce the distance between them.
This model has real limitations, but it has one enormous structural virtue: the chain of accountability is short and visible. A human made a decision. A machine executed within it. If something goes wrong, you can trace the action back to the authorization decision that permitted it, and from there to the human who made that decision.
Multi-agent delegation breaks this structure. Not because the technology is malicious or poorly designed, but because of what delegation inherently does to a chain of accountability.
When Agent A authorizes Agent B, the chain now has three nodes: the human administrator, Agent A, and Agent B. The human authorized Agent A. Agent A authorized Agent B. But the human's authorization decision — the permissions they configured — was made with Agent A in mind, not Agent B. The human did not decide what Agent B could do. Agent A did. The access model, which was built to enforce the human's decisions, is now being asked to enforce a decision the human never made.
Add a third tier — Agent B spawning Agent C — and the problem compounds. The human is now four steps removed from the action being taken on their data. The access model was built for one step.
What the Business Model Forces
I want to be careful here, because this is where the argument gets more inferential and I should say so.
Salesforce's business model creates a specific pressure that makes this architectural problem worse, not better. The company earns revenue by expanding the footprint of its platform within enterprise accounts — more seats, more clouds, more integrations, more workflows running through Salesforce infrastructure. The value proposition of Agentforce 2.0 is precisely that it can reach across more of a customer's operational surface: a single orchestrating agent coordinating sub-agents that touch CRM data, ERP data, customer communication channels, billing systems, logistics platforms. The breadth of that reach is the product.
But breadth and authorization integrity are in tension. The more systems a multi-agent workflow touches, the more delegation steps it requires, and the more delegation steps it requires, the further the chain extends from the human authorization decisions at its root. Salesforce's incentive is to make agents capable of doing more. The authorization architecture's job is to ensure that "more" stays within the boundaries a human actually intended. Those two things pull in opposite directions.
This is not a criticism of Salesforce specifically. Any platform building multi-agent capabilities faces the same structural tension. The point is that the tension is structural, not incidental, and that Salesforce's particular business model — platform expansion through workflow breadth — puts maximum pressure on exactly the part of the system that is hardest to build.
There is also a second pressure, specific to Salesforce's enterprise customer base. The companies that buy Salesforce at scale — large financial services firms, healthcare systems, government agencies, defense contractors — operate in regulated environments where data access is not just a technical question but a legal and compliance question. When a human employee accesses a customer record, there is an audit trail. There is a role assignment. There is a policy that governs what that employee can do with what they see. Regulators and auditors can inspect that chain.
When an agent accesses a customer record on behalf of another agent that was authorized by a third agent that was originally configured by an administrator who has since left the company, the audit trail becomes a research project. The compliance question becomes: who, exactly, authorized this action? And the honest answer, under the current architecture, is: it depends on how you define "authorized."
My read is that Salesforce understands this problem. The question is whether they have built the infrastructure to solve it, or whether they have built the capability and are leaving the infrastructure problem for later.
A Digression That Earns Its Place
In 2007, a web developer named Blaine Cook, then working at Twitter, helped design a protocol called OAuth. The problem it solved was specific and practical: users wanted to let third-party applications access their Twitter data without giving those applications their passwords. OAuth created a mechanism for delegated authorization — a user could grant an application a scoped access token, the application could use that token to act on the user's behalf, and the user could revoke the token at any time without changing their password.
It was a clean solution to a clean problem. The user was the principal. The application was the agent. The token was the bounded authorization. The chain had two links.
OAuth became the dominant authorization standard for the web. It was extended, refined, and eventually standardized as OAuth 2.0. Hundreds of thousands of applications use it. It works extremely well for the problem it was designed to solve.
The problem it was not designed to solve is machine-to-machine delegation. When an application uses an OAuth token to act on a user's behalf, the "user" at the root of the grant is a real person who made a real decision. When a machine uses an OAuth token to act on another machine's behalf, the "user" becomes notional. The token still says a user authorized this. But the user authorized the first application, which authorized the second application, which is now making API calls that the user never specifically contemplated.
This is not a hypothetical problem. It is the current state of most enterprise software integrations. Service accounts, machine-to-machine tokens, and automated workflows routinely operate under OAuth grants that were originally issued to a human user who may no longer work at the company, may not remember making the authorization, or may have authorized something much narrower than what the downstream chain eventually required.
The security industry has spent the last decade building tooling to address this: privileged access management systems, secrets managers, service mesh identity frameworks, zero-trust architectures. None of these fully solve the problem, but they represent the industry's accumulated recognition that the original OAuth model — human at the root, machine at the leaf — does not hold at enterprise scale.
Agentforce 2.0 sits at a different layer of abstraction, but the underlying structure is the same. The access model was designed for a world where a human sat at the root of every authorization decision. Multi-agent delegation removes that assumption, and the existing infrastructure was not built to compensate.
The reason this detour matters is the timeline it implies. The web industry encountered the machine-to-machine delegation problem around 2012, when mobile applications and microservices began to proliferate. It took roughly a decade for the tooling to mature to the point where enterprises could manage it with reasonable confidence. Agentforce 2.0 is introducing the same structural problem at the AI agent layer in 2025. The tooling does not yet exist. The standards are not yet written. The regulatory frameworks have not yet caught up.
That gap is where the interesting things will happen.
The Trust Chain Overhang
Let me state the framework precisely, because the precision is the point.
A single-agent authorization model has what I'd call a flat trust chain: one human decision, one machine action, one audit step. The access model was built to enforce this structure. It knows who the principal is, what the agent is permitted to do, and can refuse anything outside that scope.
A multi-agent authorization model produces what I'll call a trust chain overhang: the portion of the delegation chain that extends beyond the visibility of the access model that authorized the first step.
The access model can see Agent A's permissions. It cannot necessarily see what Agent A has authorized Agent B to do — especially if Agent B is operating in a different system context, under a different token, or within a sub-workflow the original access model was not designed to inspect.
The overhang is not a bug in any individual system. It is a structural consequence of delegation. Every time an agent authorizes another agent, the overhang grows by one step. The human principal at the root of the chain becomes one step more removed from the actions being taken on their behalf. The access model's enforcement boundary stays where it was — at the first delegation step — while the actual chain of action extends further and further beyond it.
This matters for three reasons.
First, auditability. In a regulated environment, the question "who authorized this action?" needs a human answer. Trust chain overhang makes that answer progressively harder to construct. You can trace the action back to the sub-agent. You can trace the sub-agent's authorization back to the primary agent. You can trace the primary agent's configuration back to an administrator. But the administrator's configuration decision was made without knowledge of the sub-agent's existence. The authorization chain is technically traceable but practically incoherent as an accountability structure.
Second, revocation. In a flat trust chain, revoking an agent's access is straightforward: you change the permissions, the agent can no longer act. In a multi-agent chain, revoking the primary agent's access does not automatically revoke the sub-agents it has already authorized, particularly if those sub-agents are operating asynchronously or have cached their tokens. The overhang persists after the root authorization has been withdrawn.
Third, scope creep. The primary agent's permissions were defined by a human who understood a specific use case. The sub-agents it spawns may interpret those permissions in ways the human never intended, particularly if the sub-agents are themselves AI systems making probabilistic decisions about what falls within their authorized scope. The access model enforces the letter of the permission. It cannot enforce the human's intent behind it.
I want to be honest about where this framework is speculative. The trust chain overhang is a structural description of a problem that is real and documented in adjacent contexts — enterprise API security, microservices authorization, federated identity management. Whether Agentforce 2.0 specifically produces this problem at scale depends on implementation details I cannot fully assess from public documentation. Salesforce may have built guardrails I haven't seen. The architecture may constrain sub-agent authorization in ways that limit the overhang. I'm reasoning from the structural logic of delegation, not from a complete audit of the system.
That said, the structural logic is not ambiguous. Delegation chains produce trust chain overhang. Overhang outpaces access models. And Salesforce has built a product whose value proposition depends on extending delegation chains as far as possible across enterprise data environments.
What I Think Happens Next
Here is the prediction, stated plainly enough to be scored later.
By the end of 2027, Salesforce will have launched a dedicated authorization layer for multi-agent workflows — a system that makes every delegation step in an Agentforce chain auditable, revocable, and traceable back to a named human principal. They will call it something like an Agent Trust Registry or a Delegation Governance Console. It will be marketed as a compliance product, because the buyers who will pay for it are in regulated industries where auditability is a procurement requirement, not a nice-to-have.
The federal and SLED market is where this pressure will be most acute. Government agencies operating under FedRAMP, FISMA, and sector-specific data handling requirements cannot deploy AI agents that produce trust chain overhang without a mechanism for resolving it into a human-accountable audit trail. The current Agentforce architecture does not provide that mechanism. Salesforce knows this. The question is whether they build it internally, acquire a company that has built it, or wait for a regulatory event to force the issue.
My read is that they build it, because the alternative is watching their most lucrative enterprise segment — large regulated institutions — either delay Agentforce adoption or impose their own access controls that reduce the platform's operational breadth. Neither outcome serves Salesforce's expansion model.
The deeper implication, which extends beyond Salesforce, is that trust chain overhang is not a problem any single platform can solve unilaterally. The moment an Agentforce sub-agent touches a system that runs on a different platform — a ServiceNow workflow, a Workday record, a government data system — the delegation chain crosses a boundary that no single access model governs. The long-term solution is probably a cross-platform delegation standard: something like OAuth for agent-to-agent authorization, with explicit mechanisms for human principal anchoring, chain-length limits, and revocation propagation.
That standard does not exist yet. The industry has not agreed that it needs one. The regulatory pressure to create it has not yet materialized in a form that forces action.
It will. The question is whether the forcing event is a compliance audit, a data breach, or a regulatory ruling — and whether the industry builds the infrastructure proactively or reactively.
I've gotten this kind of timeline wrong before, usually by underestimating how long enterprises take to encounter problems that are structurally obvious in advance. The trust chain overhang problem may not become a visible enterprise crisis for several years, even as it accumulates quietly in production deployments. But the structural logic does not change with the timeline. Delegation chains produce overhang. Overhang outpaces access models. The access models will have to be rebuilt.
Salesforce built the chain. Now someone has to design for it.