Agentic Identity and the Double-Counting Trap: Salesforce Usage Costs in 2026

The Paradigm Shift: From User Seats to Autonomous Agents

For decades, enterprise software pricing and security governance have shared a simple, predictable anchor: the human user seat. Whether you were provisioning a Salesforce admin, a sales rep, or a customer support agent, access control, auditing, and license consumption mapped directly to a human login.

Dreamforce shattered that anchor.

With the explosive rollout of Agentforce, AIforce, and cross-platform protocols like HXL, Salesforce is transitioning the enterprise from a user-centric model to an agent-centric operating system. Autonomous agents now query data, execute flows, and communicate across boundaries on behalf of humans.

While this unlocks unprecedented operational velocity, it creates an immediate, high-stakes architecture and financial trap that every enterprise must navigate: The Agentic Identity Crisis and the risk of double-counting usage costs.

---

1. The Anatomy of Agentic Identity

Today it’s simple. You run a report, your profile decides what you see — object, field, row. Done.

Agents break that. An agent pulls data from an external lake over MCP, queries Salesforce, and drops a summary in Slack at 2 a.m. All without you. So who owns that action? Your login? A shared service account? The agent itself? Nobody can answer that cleanly right now. That’s the gap.

What is the agentic twin?

Salesforce’s answer is an agentic twin — a scoped agent-side proxy of identity that travels with the work. Think of it as two modes:

• User-delegated twin: the agent acts as you. Your profile, permission sets, field-level security, and sharing rules flow through each downstream call. The audit trail still points back to you, even across multi-step flows.
• Autonomous system twin: the agent acts as itself. Nightly reconciliation jobs, scheduled enrichment, and cross-object automation run under their own system identity with explicitly granted scope — not a borrowed admin login.

In both modes the twin carries three things: who authorized the action, what that principal is allowed to see, and a trace back to the originating request. That’s what makes least-privilege agents possible instead of one broad service account doing everything. (How Salesforce Engineering describes the model)

Salesforce’s trusted agent platform stacks identity propagation, API enforcement, and data governance as one control plane. Source: Salesforce Engineering.

Two limits matter for the rest of this piece. First, the twin only works cleanly inside Salesforce’s walls. The moment your agent touches Glean, Workato, or a custom MCP server, you’re back to hoping identity survives the trip — that’s exactly where the next section bites. Second, the twin solves authorization, not billing. Every twin action still meters as API calls, Data Cloud usage, and LLM tokens, which is where Section 3 bites.

---

2. The Integration Ripple Effect: Enterprise Search, Agentic Control Planes, and MCP

But this doesn’t stay inside Salesforce. It follows your agents into every connected system:

• Enterprise Search (Glean is the example most of you know): Search indexes everything — Slack, Drive, Salesforce. When your agent queries it to answer a customer, whose permissions apply? Yours? The agent’s? If that answer is fuzzy, the agent will eventually surface an HR doc or a finance sheet to someone who should never see it. That’s not a hypothetical. It’s the default outcome of unscoped agent search.
• Revenue agents that read Salesforce (Gong, Outreach, Clari, Salesloft): Gong’s AI pulls opportunities and activities to score deals and draft call briefs. Outreach agents fetch leads, tasks, and engagement history to pick the next step. Each one acts through its own agent identity — not your Salesforce twin — so Salesforce sees a third-party caller while the permission context lives somewhere else.
• Agentic control planes (Workato, UiPath, Make.com, n8n): These tools chain work across your stack, and each hop can drop the identity thread. The problem is neither side notices. The control plane sees a successful run; Salesforce sees a generic caller. Your field-level security quietly stops applying, and the audit log tells a story that never happened.
• MCP: The Model Context Protocol has to carry identity instead of stripping it. If the context layer masks who the agent acts for, every downstream system is flying blind.

---

3. The Financial Trap: Double-Counting Usage Costs

Perhaps the most painful and immediate impact for IT leaders is the financial structure of agentic operations. The agentic twin keeps permissions intact, but it doesn’t make the work free. Enterprises are walking straight into a double-counting cost trap with three separate meters running on every twin action:

1. The Human License Tax: You’ve already paid for the underlying Salesforce user seats (Enterprise/Unlimited/Einstein tiers) required to maintain the data and user infrastructure. The twin doesn’t replace those seats — a user-delegated twin still assumes a licensed user exists underneath it.

2. The Agent Execution Tax — three meters, one action: Every time a twin spins up, you pay in three places:

   • API usage: Platform API and Connect API calls, Flow and Apex invocations, and MuleSoft-mediated calls. A single “summarize this account” request can fan out into a dozen reads (account, contacts, cases, opportunities) plus writes back. Each hop counts against API limits and, on agentic SKUs, against consumption credits.
   • Data Cloud queries: ingestion, unification, and query credits in Data Cloud / Data 360. Agents are the worst-case workload here: high-cardinality lookups, repeated profile fetches, and vector/hybrid retrieval that a human would run once but an agent retries five times while reasoning. Streaming ingestion for “fresh” agent context adds a standing charge even when no user is active.
   • LLM reasoning: input/output tokens for planning, tool selection, and summarization — billed by Salesforce (Agentforce Flex credits / Einstein request model) or by the external model provider if orchestration lives outside. Multi-turn ReAct loops multiply this fast: the model pays to read the API result, decide the next call, then read that result, on every iteration.

3. The Multi-Hop Penalty (Double-Counting):

   • When an external agent talks to Salesforce, Salesforce bills for the API usage and Data Cloud queries triggered by that call — regardless of which app initiated it.
   • Simultaneously, the LLM provider (or middleware layer orchestrating the agent) bills you for the input/output tokens required to generate and parse that exact same transaction.
   • And the originating app bills its own agent consumption separately. If a twin delegates to another agent across systems (e.g., Salesforce Agentforce handing off to an external enterprise agent), every platform in the chain meters its leg — effectively double- or triple-counting the same work.

Third-party agents fetch Salesforce data on their own meter

This is where Glean, Gong, Outreach, and every other agentic app compound the bill. Each one runs its own agent layer with its own consumption model, and none of them deduct what Salesforce already charged:

• Glean: a Glean agent answering “summarize open Acme renewals” bills you for Glean search/reasoning, then Salesforce bills the underlying Opportunity + Case + Activity API reads (and any Data Cloud lookups), then the model bills the tokens to compose the answer. One question, three meters.
• Gong: Gong’s deal agents and call-brief writers pull opportunity stages, activities, and contact roles on a schedule — per-record enrichment and summarization inside Gong is metered there, while Salesforce meters each API fetch and write-back (score fields, next-step tasks) as platform usage.
• Outreach / Salesloft / Clari: sequencing and forecasting agents continuously sync leads, tasks, and engagement history. Every agent-driven “check Salesforce, then decide the next touch” loop is Outreach consumption plus Salesforce API consumption plus LLM tokens — multiplied by every rep, every sequence, every day.
• The general pattern: any platform whose agents fetch from Salesforce — support copilots, CDPs, data-enrichment agents, custom MCP servers — follows the same shape. The app meters its agent run, Salesforce meters the API/Data Cloud side, and someone meters the tokens. No vendor nets them against each other, so the same customer record gets billed two to three times per agentic touch.

Why the twin doesn’t save you from the bill

Identity propagation and cost deduplication are different problems. The twin answers “is this call allowed and auditable?” — it says nothing about “did we already pay for this data?” So a twin that correctly enforces FLS across five hops still generates five billable events. Worse, well-scoped twins can increase spend: per-user twins defeat shared caches (my twin can’t reuse your twin’s result without a permission check), and least-privilege retries — “denied, try a narrower query” — add LLM turns on top of failed API calls.

Why This Happens

Traditional pricing models assume API calls are deterministic and cheap, while human-driven UI actions drive value. Agentic workflows invert this: they generate massive volumes of programmatic, multi-turn conversational and API overhead. Because vendors price agents as consumption add-ons on top of legacy user seats, enterprises are paying twice: once for the system of record, and again for the autonomous intelligence operating on top of it. The twin makes that spend governable — you can finally attribute it per agent — but governable is not the same as cheap.

---

4. How Enterprises Can Protect Themselves

To avoid security blind spots and runaway cloud bills, IT and architecture leaders must take immediate steps:

Govern the twin, not just the agent

• One twin per purpose: Never use generic admin credentials. Give each agent a dedicated twin — user-delegated where attribution matters, system-scoped where it runs solo — with least-privilege access and a TTL. Inventory twins like service accounts and kill orphans.
• Extend Zero Trust to AI: Treat every twin call through MCP or your control plane as an untrusted transaction requiring tokenized, verifiable identity passing. If a hop can’t forward the twin, it doesn’t get the data.
• Log the twin chain: Record twin ID → delegating user (if any) → downstream calls on every hop, so audit and chargeback survive cross-system handoffs.

Institute FinOps for AI Workflows

• Meter all three taxes separately — per app: Track API calls, Data Cloud credits, and LLM tokens per twin and per connected app (Glean, Gong, Outreach) — not as one blended “agent cost.” You’ll find different agents blow different budgets: Glean Q&A burns search + tokens, Gong enrichment burns API write-backs, Outreach loops burn API + tokens at rep scale.
• Audit token and API multi-hops: Map your twin data pipelines. Cache permission-aware enterprise context, collapse fan-out reads, and cap ReAct iterations so a stuck twin fails fast instead of retrying into a bill.
• Negotiate consumption caps: When purchasing Agentforce or AIforce add-ons, push for predictable tier-based caps per meter rather than uncapped pay-as-you-go consumption that penalizes high-volume agentic automation.

---

Conclusion

Agentic identity — and its twin mechanism — is the foundational pillar of the next era of enterprise software. Getting the twin right keeps your Salesforce instance secure, compliant, and auditable across every hop. But a well-governed twin still consumes: API calls, Data Cloud queries, and LLM tokens meter independently, and multi-hop delegation double-counts by default. Design twin scope and consumption caps together, before you turn the agents loose.

The future is autonomous, but the twin needs both an identity policy and a budget.