Trusted identity
The agent acts as the user. Or it is a demo.
The first week is in the org, reading what already exists. The user authenticates once. Each hop exchanges for a narrower token. A shared service account is not trusted identity. The honest no: if the work is a software factory with a named delivery date, we are the wrong partner.
Certified Partner since 2010 · MVP Hall of Fame · 200+ agents in production · UAE and US desks
On-behalf-of
One sign-in. A narrower token at every hop.
01
User authenticates
The identity provider issues the first token. The channel is Slack, a portal, or Salesforce.
02
Gateway exchanges
OAuth on-behalf-of. The next audience is narrower than the last.
03
Agent and tools
Agentforce and MCP see the user. Sharing rules still apply.
04
Next hop identity
If the next system needs another IdP, that is a second exchange, not a shared key.
Mermaid source
flowchart LR
U[User] --> C[Channel]
C --> G[Flex Gateway]
G --> A[Agentforce]
G --> M[MCP]
U -. authenticates .-> I[Identity provider]
I -. OBO token .-> GThe split
User mode, connected app, or another identity.
Questions
What we actually say.
- Can we run Agentforce as a connected app in production?
- You can. You will not be able to prove the agent acted as the user. We will not sign write-back that way.
- What if the next hop is a different identity provider?
- Exchange again for that audience. Do not reuse the first token. CIBA and multi-IdP are the next hop, not a reason to skip the gateway.
Next
What to read next.
The brief · one email
Show us what the agent authenticates as today.
We will mark the hops with a shared key, and the ones that should not exist.