The governance problem that Agent Identity Cards are responding to is real. AI agents are proliferating across enterprise environments faster than the identity infrastructure that would make them auditable, revocable, and trustworthy. A human employee has a directory entry, an access review cycle, a termination workflow. An AI agent, in most enterprise environments today, has a service account credential that nobody owns, a permissions scope that nobody reviewed, and an audit trail that stops at the API call. Salesforce is not wrong that this is a problem. The question worth examining is what kind of solution Agent Identity Cards actually are — and what the design choices reveal about who gets to define the answer.
Agent Identity Cards, introduced as part of the Agentforce platform, are a JSON-based credential format that encodes identity attributes for AI agents operating within the Salesforce ecosystem. Each card carries:
- a unique agent identifier
- an issuing organization reference tied to the Salesforce org model
- a capability declaration specifying what the agent is authorized to do
- a data classification access level
- a human principal association linking the agent to an owning user or service account
- expiration and rotation policy metadata
Cards are issued through Agentforce's Agent Management Console and signed using Salesforce-managed cryptographic keys. Validation runs through Salesforce's existing identity infrastructure.
That signing and validation architecture is where the standards-layer analysis has to begin.
What the Format Encodes — and What It Requires
The schema itself is technically coherent. The attributes Agent Identity Cards encode map reasonably well onto what a governance-first credential format would need: provenance, scope, ownership, and lifecycle. The capability declaration field in particular represents a meaningful advance over the flat permission scopes that characterize most current service account models. Declaring what an agent can do, rather than just what API endpoints it can reach, is the right level of abstraction for governance purposes.
The signing and validation architecture, though, creates a dependency that shapes everything downstream. Because cards are signed with Salesforce-managed keys and validated through Salesforce's identity infrastructure, an external system that wants to trust an Agent Identity Card has two options: integrate with Salesforce's validation layer, or treat the card as opaque. There is no published specification that would allow a non-Salesforce system to independently verify a card's authenticity. There is no schema registry that an external identity provider could implement against. The format is readable — JSON is readable — but the trust model is closed.
The governance problem Agent Identity Cards are solving extends well beyond Salesforce's perimeter. AI agents cross system boundaries. An Agentforce agent that retrieves customer data from Salesforce CRM and writes a summary to a Slack channel and triggers a workflow in ServiceNow is operating across three separate trust domains. Governance infrastructure that works at the Salesforce perimeter and stops there is not enterprise agent governance. It is Salesforce agent governance.
The Historical Record as Lens
Vendor-led credential formats have a complicated history in enterprise identity, and that history is worth using carefully rather than as a rhetorical shortcut.
SAML began as a vendor-led initiative inside OASIS, with significant contributions from Sun Microsystems and IBM. It became a genuine open standard — one that any implementer can build against without a commercial relationship with any of its originators. OAuth 2.0 traveled a similar path through the IETF. SCIM, the System for Cross-domain Identity Management that became RFC 7642 through 7644, is a particularly relevant data point: Salesforce was a founding contributor to SCIM's development. The company has demonstrated, at least once, a willingness to take a format it helped create and hand it to a standards body where it would lose control of the specification's direction.
The cautionary counterexample is Microsoft's Passport initiative in the early 2000s, which proposed to serve as the universal identity layer for the web. The architecture itself held up. What collapsed Passport was the requirement that the entire internet route its identity assertions through Microsoft's infrastructure. The Liberty Alliance formed in direct response, and Passport eventually retreated to being a Microsoft-internal authentication service. The lesson was narrower than "vendor-led identity initiatives fail": they fail when the trust model requires routing through the vendor's infrastructure for assertions that cross the vendor's boundary.
Agent Identity Cards, as currently specified, have a Passport-shaped trust model inside a SCIM-shaped rhetorical frame. The technical architecture makes them governance infrastructure for AI agents that live inside the Salesforce trust perimeter — not governance infrastructure for AI agents broadly.
What Is Absent
Absence is often the more informative signal in a standards-layer analysis.
Salesforce has not submitted Agent Identity Cards to the IETF, where active work on OAuth extensions for agentic contexts is underway. The W3C's Verifiable Credentials working group, which has developed a credential format explicitly designed for portability across trust domains, has received no public contribution from Salesforce on Agent Identity Cards. The OpenID Foundation's ongoing work on identity frameworks for AI systems does not reference the format. These absences are not conclusive — standards body engagement often lags product development by a year or more — but the pattern is notable. A company that had designed Agent Identity Cards as a contribution to open governance infrastructure would have an incentive to engage those bodies early, to shape the emerging standards rather than wait for them to crystallize around a different architecture.
The interoperability gap is also visible in the partner ecosystem documentation. Salesforce's published integration guidance for Agentforce partners describes how partner-built agents can receive and present Agent Identity Cards within the Salesforce ecosystem. It does not describe how an enterprise running a multi-vendor agent environment would establish mutual trust between Agentforce agents and agents credentialed by other systems. The assumption embedded in the documentation is that the enterprise's agent environment is, or will become, primarily Salesforce.
That assumption is not unreasonable as a product bet. Salesforce has a large installed base and a platform strategy that has historically succeeded at expanding the surface area of what "Salesforce" means inside an enterprise. But it is a product bet, not a governance contribution.
The Strategic Logic
None of this requires attributing bad faith to Salesforce. Platform companies move into standards territory because standards territory is where platform leverage lives. Defining the credential format for AI agents is not a neutral technical act — it is a decision about whose infrastructure sits at the root of enterprise agent trust. Salesforce is making that decision in the way platform companies make it: by shipping something that works well inside their ecosystem, establishing adoption, and creating the conditions under which any eventual open standard would have to accommodate their format or displace it.
This is the normal behavior of a company that has built significant enterprise infrastructure and wants to extend that infrastructure into a new domain. It is also the behavior that, historically, produces either a de facto standard or a standards war, depending on whether competitors and customers accept the terms or organize around an alternative.
The enterprise identity community has been here before. The question of who issues the credential is always also the question of who holds the trust relationship. When the answer is a single vendor's managed infrastructure, the governance benefit is real but bounded — bounded by the vendor's ecosystem, the vendor's pricing decisions, the vendor's roadmap, and the vendor's continued existence in its current form. Enterprises that have spent the last decade trying to reduce single-vendor dependencies in their identity architecture are being asked to accept one in the layer that governs their AI agents.
The Verdict
The schema is real work. The problem it addresses is genuine, and the capability declaration model in particular represents a meaningful advance over how most enterprises are currently handling agent permissions. Calling it pure lock-in would miss what it actually contributes.
Calling it a contribution to open governance infrastructure, though, would require evidence that does not yet exist: engagement with standards bodies, a published specification that external implementers can build against without Salesforce tooling, and an interoperability model for multi-vendor agent environments. None of those exist in the current release.
A platform company moved early into a standards vacuum. That is what Agent Identity Cards are. The vacuum itself is real — there is no open, widely adopted credential format for AI agents, and the IETF and W3C work that might produce one is still in early stages. Salesforce is filling that vacuum with something that works, that their customers will adopt, and that will be difficult to displace once it is embedded in enterprise agent workflows. Whether that eventually becomes the foundation of an open standard, as SCIM did, or calcifies into proprietary infrastructure, as Passport did, depends on decisions Salesforce has not yet made — and on whether the enterprise identity community moves quickly enough to make those decisions consequential.
The card exists. The question of who gets to issue it, and on what terms, is still being negotiated. Enterprises deploying Agentforce agents today are participating in that negotiation whether they intend to or not.