Agent Identity & the Agent Registry

Before you start: this is a billed cloud service (and partly Preview)

• Cost and account. A Google Cloud project with billing enabled and the Agent Platform governance features available to your org. Some pieces here interact with VPC Service Controls and org-level policy — you may need elevated permissions.
• Preview features. Several capabilities in this lab (agent-identity use in VPC-SC rules, parts of the registry/gateway) were Preview at the time of writing. Treat the exact fields and flows as current-as-of-authoring and verify against the docs — this area is moving fast.
• Authored against the docs, not executed live. Config and commands are written against the official docs and checked, not run during authoring.
• Hybrid: console + config. Identity is largely automatic; the registry, gateway, and catalog are console- and policy-driven.

About this series

This is Part 9 of the eleven-part Gemini Enterprise Agent Platform series. Lab 8 screened what the agent says. This lab governs who the agent is and what it may reach: a verifiable identity, a place in the enterprise registry, an egress policy, and a way to publish and discover agents across the organization (and the wider agentic web). It's the enterprise side of the open discovery and trust ideas from the ARD lab.

What you'll build

You'll take your deployed agent and make it a governed citizen of the enterprise:

1. Identity — confirm the verifiable identity Google Cloud issues your agent and see how it's used in access rules.
2. Registry — register the agent so it gets a globally unique, namespaced URN and can be discovered and governed.
3. Egress policy — restrict, via Agent Gateway, which agents and MCP servers it's allowed to reach.
4. Publish & discover — publish an `ai-catalog.json` so registries can index your agents, and discover others the same way.
5. Pin tools and specifications so a registered agent's dependencies don't drift underneath it.

By the end the agent isn't just running — it's identifiable, governable, and discoverable.

Why this matters (the 5-minute business case)

Read this before handing the lab to your team.

Once you have more than a couple of agents, the hard problems stop being "can it answer?" and become "who is this agent, what is it allowed to touch, and can we trust it?" Those are identity, authorization, and governance questions — the same ones we solved for users and services years ago, now arriving for agents. This lab is how you answer them at scale.

Three reasons this is a leadership-level concern:

1. Identity is the foundation of every other control. An agent with a verifiable identity (here, a SPIFFE ID and short-lived X.509 certificate issued on deploy) can be named in access policies, audited, and trusted by other systems. Without identity, "what is this agent allowed to do?" has no subject — every other guardrail is built on sand.
2. Egress control is how you contain blast radius. An agent that can reach anything is a liability the first time it's compromised or misled. Setting an egress policy — allow/deny on which agents and MCP servers it may call — is the network-level version of least privilege, and it's enforced centrally rather than hoped for in code.
3. A registry makes a fleet governable instead of a sprawl. A namespaced URN per agent, a catalog you can publish and others can discover, and the ability to pin the tools and specs an agent depends on — that's the difference between an inventory you can reason about and a pile of undocumented bots. It's also how agents find and trust each other across teams and organizations (the enterprise realization of ARD).

The honest caveats:

• This is governance plumbing, not a feature users see. Its value shows up as incidents that don't happen and audits you pass. Invest accordingly — and don't skip it because no demo depends on it.
• Preview means moving parts. Field names and flows here will change. Pin to documented versions and re-check before you rely on it in production.
• Identity enables control; it isn't control by itself. A verifiable identity only helps if you actually write the egress and access policies that reference it. Issuing certs and then granting everything is theater.

A framing for a non-technical stakeholder: "This gives every agent a verifiable ID, a registered place in our catalog, and rules about what it's allowed to reach — so we know who each agent is, can control its access, and can trust agents that find each other. It's identity and access management, for agents."

Concepts you'll use (2-minute primer)

• Agent Identity — on deploy, Google Cloud assigns the agent a SPIFFE identity and an X.509 certificate (short-lived — about 24 hours — and auto-rotated). This is the agent's verifiable "who."
• Agent Registry — the enterprise catalog of agentic resources (agents, skills, MCP servers, tools). It assigns globally unique namespaced URNs, supports discovery, and enforces governance.
• Agent Gateway — where egress policies live: allow/deny rules on traffic going to agents and MCP servers.
• `ai-catalog.json` — a catalog file published at a well-known path under your org's domain that describes your available agentic resources. Registries crawl it to index the "agentic web" (this is the ARD spec).
• Pinning — fixing the exact tools and specifications a registered agent depends on, so they don't change underneath it.

One sentence: identity says who the agent is, the registry gives it a name and makes it discoverable, the gateway controls what it can reach, and the catalog lets the whole thing federate.

Prerequisites

Step 1 — Confirm the agent's identity

You mostly get this for free. When you deployed to Agent Engine, Google Cloud issued the agent a SPIFFE identity and a short-lived X.509 certificate (≈24-hour validity, rotated automatically). That identity is what lets you name the agent in access rules rather than handing it broad, static credentials.

In the console, find your deployed agent and locate its identity. Then use it where access is decided — for example, VPC Service Controls can reference agent identities in ingress and egress rules (Preview), so you allow this agent to reach a protected resource without opening the perimeter to everything.

The point: the agent has a real, verifiable "who" — short-lived by design, so a leaked credential expires fast.

Step 2 — Register the agent (get a URN)

Register the agent in the Agent Registry so it becomes a governed, discoverable resource. Registration assigns a globally unique, namespaced URN — a stable identifier other agents and policies can reference no matter where the agent moves.

In the registry (console), register your deployed agent and record its URN. From here the agent is part of the enterprise inventory: it can be searched for, governed by policy, and referenced by other agents — instead of being an undocumented endpoint only its author knows about.

Step 3 — Set an egress policy (what it may reach)

Use Agent Gateway to constrain the agent's egress — the agents and MCP servers it's allowed to call. Default-deny and allow only what it needs:

# egress-policy.yaml (illustrative shape — verify field names against the docs)
egress:
  default: DENY
  allow:
    # the Acme orders MCP server this agent legitimately uses
    - urn: "urn:acme:mcp:orders-server"
    # a peer agent it may delegate to over A2A
    - urn: "urn:acme:agent:returns-specialist"

This is least privilege at the network layer: even if the agent is talked into trying to reach somewhere it shouldn't, the gateway refuses. Pair it with the least-privilege tools from Lab 4 and the content screening from Lab 8 and you've contained the agent on three axes — what it can do, what it can reach, and what it can say.

Step 4 — Publish and discover (the agentic web)

Discovery across teams and organizations works through a published catalog. You expose an `ai-catalog.json` at a well-known path under your domain; registries crawl it and index your resources — they're search engines for the agentic web. This is the ARD spec in practice.

{
  "version": "1.0",
  "organization": "acme.example.com",
  "resources": [
    {
      "type": "agent",
      "urn": "urn:acme:agent:orders-assistant",
      "name": "Acme Orders Assistant",
      "description": "Answers customer questions about Acme orders.",
      "endpoint": "https://agents.acme.example.com/orders-assistant",
      "protocols": ["a2a"]
    }
  ]
}

Publish that, and other teams (or partners) can discover your orders assistant and verify it's really yours. To consume agents the same way, point your discovery flow at a registry and resolve resources by URN. This is what turns isolated agents into a network that can find and trust each other — the enterprise counterpart to the open trust model in the ARD lab.

Step 5 — Pin tools and specifications

A registered agent depends on tools and specs (an MCP server's tool schema, an OpenAPI contract). If those change underneath it, behavior drifts silently. The registry lets you pin the exact versions an agent relies on, so a dependency can't change without a deliberate update. Treat it like a lockfile for your agent's external dependencies.

Cost & cleanup

• Unregister the agent and remove any test entries from the registry.
• Remove the egress policy and any test catalog (ai-catalog.json) you published.
• Identity certs are short-lived and auto-expire; deleting the underlying Agent Engine instance (Lab 2) removes the agent entirely.
• Confirm in Billing → Reports that nothing is still accruing.

If a lab created it and you're done, delete it today.

Verified against

• Agent Identity (SPIFFE/X.509), Agent Registry (namespaced URNs, publish/discover, pinning), Agent Gateway (egress policy), and the ARD / `ai-catalog.json` spec, June 2026.
• Several features were Preview; field names, policy shapes, and flows vary and will change. The egress-policy.yaml and ai-catalog.json here are illustrative — verify exact schemas against the current docs before relying on them.

What's next

Your agent now has identity, a registered name, an egress policy, and a place in the catalog. The last operational piece is seeing and affording it in production:

• Lab 10 — Observability, tracing & cost: trace what deployed agents do across steps, build dashboards and alerts, and control spend.
• Cross-links: the ARD lab (the open discovery/trust spec this implements) and the A2A lab (how registered, identified agents actually talk). Identity + egress here, plus tools (Lab 4) and safety (Lab 8), are the governance backbone of a production agent.