AI Agents
Verifying AI agents across the org boundary: Web Bot Auth, passports, and delegated identity
Your Agentforce agent-user model answers what an agent can do inside your org. It says nothing about whether an inbound agent is who it claims, or whether your outbound agent can prove who it is. Here's the stack filling that gap, Web Bot Auth, agent passports, verifiable credentials, and delegation tokens, and why it's shipping ahead of the standard.
Two things are happening to your web properties at once. External AI agents are starting to arrive at them, on the pricing page, the Experience Cloud portal, the checkout. And your own agents are starting to leave, calling APIs, other companies’ agents, and payment rails you don’t control.
Both raise the same question, and your Salesforce permission model doesn’t answer it. When an Agentforce agent runs as a scoped user, that identity governs what it can see and do inside your org. It says nothing about whether the agent knocking on your login page is really OpenAI’s, or whether the agent you sent to a partner can prove it’s yours.
Cross-organizational agent identity is a different layer, and it’s being built right now in the open, ahead of any ratified standard. The vendors solving it are not Salesforce. They’re Cloudflare, the card networks, the IETF, and the W3C. If you run agents or serve them, this is the layer you design toward.
Internal identity answers a different question
Start by separating two things that both get called “agent identity,” because conflating them is why teams reach for the wrong tool.
Inside your org, an agent has a running user, a permission set, and the CRUD, field-level, and sharing rules that identity inherits. That model decides whether the agent can update a case or read a field. It is the right control for what happens after a request is trusted.
None of it establishes trust across a boundary. When your agent calls an agent you don’t own through the A2A protocol, reaches an MCP server a developer wired in, or searches the live web, it’s a party in someone else’s system, and their permission model has no idea who it is.
The reverse is worse. An anonymous agent hitting your inbound lead agent arrives with no verified identity at all, which is exactly the surface prompt injection rides in on.
The gap is authentication, not authorization. Who is this agent, and can it prove it, before your rules about what it may do even apply.
Web Bot Auth: proving an agent on the way in
The furthest-along piece solves the inbound half. Web Bot Auth lets an agent cryptographically sign its HTTP requests so a website can verify the agent’s operator without any prior relationship. It’s built on RFC 9421, the already-ratified standard for HTTP Message Signatures, with an Ed25519 key per agent.
The flow is public-key cryptography applied to a request. The agent operator generates an Ed25519 key pair and publishes the public key at a discoverable location. Each outbound request carries three headers:
Signature-Agentpoints to the domain hosting the operator’s key directory, for exampleoperator.openai.com.Signature-Inputdefines what’s being signed and when the signature expires.Signaturecarries the Ed25519 signature itself.
The verifying site fetches the public keys from a JSON Web Key Set at /.well-known/http-message-signatures-directory on the Signature-Agent domain, matches the request’s keyid to the right key, and checks the signature. That directory is itself served over HTTPS and signed, so the key list can’t be forged in transit. No account, no shared secret, no allowlist of IP ranges that breaks the first time the operator adds a data center.
That last point is why this exists. Bot verification used to mean maintaining lists of user-agent strings and IP blocks, both trivially spoofed and constantly stale. A signature the site can verify against a published key replaces the whole fragile arrangement.
Web Bot Auth is in production ahead of its own ratification. As of the second half of 2026, the IETF working group has individual drafts and no single adopted document, while Cloudflare, AWS WAF, Akamai, HUMAN, and Vercel already verify its signatures to decide which agents reach a site.
The card networks moved early too. Cloudflare’s work with Visa, Mastercard, and American Express folds Web Bot Auth into how a payment agent is authenticated before it transacts.
The outbound half: passports, credentials, and delegation
Signing a request proves which operator sent an agent. It doesn’t say what that agent is allowed to do, or on whose behalf. Three overlapping efforts cover the rest, and they’re less settled than Web Bot Auth.
Agent passports extend the same publish-and-verify pattern from the request to the agent’s identity. One proposal serves a signed JSON document at /.well-known/agent-passport.json, keyed to Ed25519 over DNS, stating a business-issued identity and authority for an agent, with an open-source reference verifier. The shape mirrors Web Bot Auth deliberately: a well-known file, a signature, a verifier that needs no prior contract.
Verifiable credentials come at it from the W3C side. The DID and Verifiable Credential standards let an agent hold cryptographically signed claims, its operator and its permitted capabilities, and present them to a verifier with no centralized identity provider in the loop.
A W3C community group is now working specifically on agent identity, aimed at cross-organizational trust without pre-existing bilateral agreements. That “no prior agreement” property is the whole point, because the agentic web is too many-to-many for per-pair contracts.
Delegation tokens answer the “on whose behalf” question, and here a known standard already does real work. OAuth 2.0 Token Exchange (RFC 8693) lets one party swap a token for a narrower-scoped one while recording who’s acting for whom. The actor_token and the nested act claim carry the delegation chain.
So a request that started with a human, passed to an orchestrating agent, and handed to a subagent still carries proof of the whole chain and the consent behind it. When one of your agents delegates to another across a boundary, that chain is what a careful verifier wants to see.
The four patterns settling into practice map onto this cleanly: an agent acting as a user with explicit consent, an agent with its own standing identity, one agent delegating to others, and scoped impersonation where the agent acts as the user within narrow scopes. Which one you’re in decides which mechanisms you need.
What this means for a Salesforce shop today
None of this is a shipped Agentforce feature, and pretending otherwise would be the fabrication this field is full of. The Einstein Trust Layer governs what happens to data inside a Salesforce-mediated model call. It is not a cross-org agent-identity system, and the standards above are being built outside Salesforce’s stack. Treat what comes next as design posture, not a config screen.
On the inbound side, treat agent traffic as its own class. Your public-facing Salesforce properties, an Experience Cloud site, Messaging for Web, a lead agent on the pricing page, sit behind infrastructure that increasingly can verify Web Bot Auth signatures.
The decision to make deliberately is what a verified agent gets that an unverified one doesn’t: full access, a rate-limited lane, or a challenge. An unverified agent is not automatically hostile, but it’s unproven, and an agent that submits a form or drives a conversation deserves a different default than an anonymous human.
On the outbound side, the question is whether your agents can prove themselves when they leave. Today an Agentforce agent reaching an external system authenticates with whatever that integration uses: a Named Credential, an API key, an OAuth token. As partners and payment rails start expecting signed agent identity and a verifiable delegation chain, “we call your API with a service account” becomes the weaker position.
The teams that move fastest here already know which of their agents act autonomously and which act for a specific person. That distinction is precisely what a delegation token has to encode.
The near-term move is not to implement Web Bot Auth in Apex. It’s to inventory your agent boundaries, decide your posture on both sides of each one, and design toward standards that are already shipping in production even though the RFC won’t land until 2027.
The agentic web is being wired for identity right now. A Salesforce estate that knows which of its agents are talking to whom, and on whose authority, is the one that plugs into it rather than scrambles when a partner asks for a signature it can’t produce.
Understanding the basics
What is Web Bot Auth?
Web Bot Auth is an emerging protocol that lets an AI agent cryptographically sign its HTTP requests so a website can verify which operator sent it, with no prior relationship. It’s built on RFC 9421 (HTTP Message Signatures) with an Ed25519 key per agent, using three headers: Signature-Agent, Signature-Input, and Signature. Verifiers fetch the public keys from a JSON Web Key Set at /.well-known/http-message-signatures-directory and check the signature. Cloudflare, AWS WAF, and others verify it in production, though its IETF standardization is not final.
How is cross-org agent identity different from the Agentforce agent user?
The Agentforce agent user is internal authorization: it decides what an agent can see and do inside your org, through permission sets, field-level security, and sharing. Cross-org identity is authentication across a boundary: proving who an agent is when it leaves your org or arrives at someone else’s. The internal model can’t establish that trust, which is why Web Bot Auth, verifiable credentials, and delegation tokens exist.
Does Salesforce or the Einstein Trust Layer verify external agents?
No. The Einstein Trust Layer governs data handling inside a Salesforce-mediated model call, such as masking, grounding, and retention. It does not verify the identity of external agents reaching your web properties, or issue a verifiable identity to your outbound agents. Those functions are open web standards built outside Salesforce’s stack, and you design toward them at the infrastructure and integration layer.
What is OAuth 2.0 Token Exchange used for with agents?
RFC 8693 (OAuth 2.0 Token Exchange) lets one party swap a token for a narrower-scoped one while recording the delegation. The actor_token parameter and the nested act claim capture who is acting on whose behalf, so a multi-hop chain from a human to an orchestrating agent to a subagent keeps proof of the whole chain. It’s the established way to express “this agent is acting for that user, within these scopes” across services.
Mapping where your agents cross an organizational boundary, and deciding what a verified agent gets on the way in and what your agents have to prove on the way out, before a partner or a payment rail asks for it? Talk to us. Designing the identity and trust boundaries around an agent estate is exactly the work we do.
