Runtime identity secures an agent inside its operating environment. Portable accountability gives outside counterparties a route to the party behind it. Google solved the first problem well. Here's why the second is still open.

The Short Version

Google Agent Identity gives supported agents a first-class cryptographic identity built on SPIFFE, with short-lived credentials and no developer-managed private keys.
It answers the enterprise question well: which agent, running where, may access which resource? Strong attestation, automatic credential rotation and agent-specific audit records are built in.
It does not answer the cross-party question: who stands behind this agent, and what recourse exists if it causes harm? Its identity describes a workload inside a cloud trust domain, not an owner an outsider can check.
Concordium answers that second question. An agent is registered as an on-chain token owned by an identity-verified account, and the Verified by Concordium badge lets it carry that accountability signal while it keeps running on Google Cloud, Ethereum or anywhere else, with no migration.

This is a close look at what Google's identity model secures, and the accountability question it leaves for another layer. It is the third piece in the series, after how agents pay and how they are discovered and rated, and before authorization.

What Google Actually Shipped

In April 2026, Google Cloud made Agent Identity generally available for Agent Runtime, creating a principal type designed specifically for AI agents. Service accounts were built for workloads with predictable permissions. Agents are goal-directed, chain tools, act on behalf of users and make choices at runtime. Giving them shared static credentials would blur which agent performed an action and expand the damage a stolen credential could cause.

Google’s answer is grounded in SPIFFE, the Secure Production Identity Framework for Everyone. On a supported Google Cloud runtime, an agent receives a unique SPIFFE ID derived from the resource where it is hosted, together with automatically managed X.509 credentials. Developers cannot create private keys for an agent identity. Access tokens can also be bound to the agent’s certificate, making a bound token usable only over a mutually authenticated TLS connection using that certificate.

Identity and Access Management (IAM) allow and deny policies can apply directly to an agent. Audit logs can distinguish an agent acting as itself from one acting on behalf of a user. Agent Gateway governs agent-to-agent and agent-to-tool traffic, while Agent Identity Auth Manager handles delegated OAuth credentials without exposing raw user tokens to the agent.

Those components did not all reach the same release stage at once. Agent Identity for Agent Runtime became generally available in April. Auth Manager was still in preview when Google described it in May, and Agent Gateway reached general availability in June.

Alongside this, the A2A protocol gives independent agents a shared way to discover and communicate with one another through Agent Cards. A card can declare security schemes such as OAuth 2.0, OpenID Connect or mutual TLS. A2A defines how authentication information is expressed; authorization remains the responsibility of the infrastructure implementing it. Together, Agent Identity, IAM, Gateway and A2A form a strong enterprise stack for authenticating agents and controlling what they can do.

Identity Derived from Runtime

A Google agent’s SPIFFE ID is mapped to the cloud resource where it runs: the project, region and hosting service. It tells Google Cloud that this is the authenticated agent occupying this position in an organization’s infrastructure. When the deployment disappears, its runtime identity disappears with it.

Inside that environment, this is exactly what an operator wants. The identity is specific, revocable and tied to the agent’s lifecycle. It supports least-privilege access without requiring a long-lived credential.

What it does not establish is who built the agent, who operates it or which human or legal entity should answer for its external commitments. It identifies a workload, not the party behind the workload.

SPIFFE identities can cross trust domains through federation. But federation requires the operators involved to exchange and accept trust information in advance. That is useful between configured organizations; it is not a public accountability signal that any previously unknown counterparty can check. Nor is Google Agent Identity intended to provide one. Its job is to secure and govern workloads within an enterprise environment.

The Question Outside the Perimeter

The distinction becomes important when an agent deals with a party outside its operator’s systems. An agent negotiating a purchase, submitting work or paying an invoice raises a question beyond whether it was validly deployed: if it defrauds a counterparty, exceeds its authority or walks away from an obligation, is there an identifiable party behind it?

Enterprise IAM can record an internal owner and preserve an audit trail, but that information normally remains inside the organization. An outside counterparty cannot inspect the operator’s IAM console, validate its ownership records or determine whether the named owner represents a verified legal party.

Industry guidance is moving toward clearer ownership. Singapore’s Model AI Governance Framework for Agentic AI calls for meaningful human accountability, controls and traceability. NIST’s AI Agent Standards Initiative includes agent identity and authorization among its research priorities. A February 2026 survey published by Strata found that only 23 percent of responding organizations had a formal enterprise-wide strategy for agent identity management.

The missing piece is a portable signal that gives an outside counterparty a route back to a verified person or organization without exposing that party’s personal information to the public.

Two Systems, Two Questions

Neither system replaces the other. Runtime identity without portable accountability can produce agents that are well contained at home but difficult for strangers to assess. A public registry without runtime identity can show who owns a registration while doing little to constrain what the software may access. A production agent acting across organizations may need both.

Where Concordium Fits

The Concordium Agent Registry is built for that second system. An agent is registered as an on-chain token owned by a Concordium account, and because opening an account starts with identity verification, ownership is tied to an identity-backed account without putting the holder's personal details on-chain. A lookup does not prove an agent is honest, safe or authorized for a given transaction. It proves narrower things: that the registration exists, which account owns it, and whether it is active or revoked. That is a real foundation for attribution, but trust still rests on the agent's conduct, its permissions and the context of the transaction.

Two things are worth being precise about. Concordium's identity layer already provides a route to identify an account holder under the network's formal disclosure process, and the natural next step is portable Agent IDP proofs that let an agent present specific owner facts such as age, nationality or role. That integration is on the roadmap. CIS-8004 mirrors the ERC-8004 registration model and works as an additional accountability anchor for agents running on Ethereum or elsewhere, while CIS-8 binds external keys to a Concordium account and the Verified by Concordium badge exposes a checkable association without forcing the agent to move its execution onto Concordium. The systems are complementary rather than automatically compatible, and the registry is queryable through an MCP service, so agent frameworks and AI tools can read and update records with standard tool calls.

What the Registry Proves, and Where It Stops

A registry query confirms four things: that an agent record exists, that it is active, that it has not been revoked, and which identity-backed account owns it. It can also return the record's metadata and external keys. Because the data sits on a public chain, a counterparty can check all of this without any access to the operator's cloud account or internal IAM system.

Active registration is evidence of current status, not good behaviour. It does not prove the agent will perform correctly, that the owner authorized a specific action, or that a counterparty will find an easy legal remedy, and it does not manage permissions, rotate credentials or defend the agent at runtime. What it offers parties outside an organization is a common record they can inspect, which is exactly what an internal audit trail cannot.

One caveat belongs to the whole category, not to Concordium. Any open registry matters only when counterparties actually check it and know how to read what they find, and that habit is still forming. No open agent registry has yet shown usage at the scale its advocates expect, and that is the same market challenge every entrant faces.

Identity Is Only Part of the Answer

Google Agent Identity solves a real problem. It gives each agent a distinct cryptographic identity, ties it to access policies, and keeps a clearer record of what the agent did. Inside Google Cloud, that is a genuine step forward. But authenticating a workload is not the same as establishing who stands behind it. Once an agent deals with outside organizations, a counterparty needs more than proof that it is running where it claims. It needs a route back to the person or organization accountable for putting it to work.

Agents that cross organizational boundaries will need all three: strong runtime controls, clear authorization records, and a portable basis for accountability. Google has made substantial progress on the first two.

You can prove where an agent runs. The open question is who answers for it.

If you are building agents that must be assessed beyond your own perimeter, explore the Concordium Agent Registry.