Govern discovery with Agent Registry

Learning objective

Use Agent Registry for governed discovery, ownership, and inventory without treating a registry entry as permission to call a runtime service.

Core idea

Treat Agent Registry as a map, not a key. It tells you what components exist, where they run, what they claim to do, and who is accountable for them. A runtime identity and applicable access policies determine whether a request may proceed.

Keep four questions separate:

Agent Registry is a centralized catalog and unified inventory. Registration makes a component visible to permitted registry consumers. It does not give an agent credentials, grant access to the destination, or authorize a particular operation.

How governed registration works

Agent Registry catalogs agents, Model Context Protocol (MCP) servers, endpoints, and standalone skills. An administrator manually registers an agent, MCP server, or endpoint through a writable Service; consumers query its read-only Agent, McpServer, or Endpoint projection. Standalone skills use versioned resources. Supported Google Cloud runtimes can register agents and MCP servers automatically. The Agent Registry data model defines these resource types and registration paths.

A governed operating process has five parts:

1. Ingest. Use automatic registration for supported components in the same project. Manually register external components, unsupported runtimes, and cross-project components that belong in a central inventory.
2. Assign ownership. Make one team accountable for each entry’s description, capability claims, environment, review status, and retirement. If the registry record cannot hold all required ownership data, link it to an authoritative catalog by its stable identifier.
3. Control changes. Separate readers from maintainers. The Viewer role supports discovery, while Editor and Admin roles can change registered services and metadata. Google warns against granting these mutation roles directly to agents because altered endpoints and tool annotations can cause harmful behavior. See Agent Registry roles and permissions.
4. Discover. Developers and orchestrators can list entries or search agent metadata, Agent2Agent (A2A) skills, and MCP tools. Search answers “which catalog entries match?” It does not answer “which calls are allowed?” See Search for agents, tools, and skills.
5. Reconcile. Update changed endpoints and capabilities, investigate stale records, and remove retired manual registrations. Deleting a manual Service removes its agent from search; it does not delete the separately hosted runtime. To remove an automatically registered agent, delete it from its Google Cloud runtime. See Manage agents.

Registration and runtime authorization

Catalog access and runtime access are different authorization decisions:

An agent identifier is a stable logical name used for inventory and lookup. An agent principal is a verifiable runtime identity used in policy. Google Cloud explicitly states that agent identifiers differ from agent identities: secure, policy-governed communication uses the agent principal.

For traffic governed by Agent Gateway, a registered destination still requires an access policy that grants the agent principal the required egress permission. The gateway denies egress unless an IAM policy explicitly allows it. After the gateway permits the route, the target can still deny the operation. See the Agent Gateway overview.

Do not mistake a registry binding for an authorization grant either. A binding can associate a source agent and target with an auth provider so the orchestrator can resolve credentials. Those credentials must still have permission at the destination. The authentication guide requires both Registry Viewer access and the IAM permissions needed by the underlying service.

Key distinctions and trade-offs

Automatic versus manual registration: Automatic registration improves freshness and reduces onboarding work, but it covers supported resources in a project. Manual registration extends coverage to external and cross-project components, but owners must prevent stale metadata.

Open discovery versus narrow discovery: Broad read access encourages reuse. Narrower access limits exposure of internal capability and endpoint metadata. In either case, discovery access remains separate from runtime permission.

Dynamic selection versus deterministic allowlists: Searching the registry at runtime lets an orchestrator adapt as capabilities change. A fixed set of reviewed identifiers is easier to test and reason about for high-risk actions. Use discovery to propose candidates, then require policy checks before use.

Architecture / decision scenario

A retail company operates a purchasing agent. It needs a supplier-catalog MCP server for read-only searches and a purchase-order API that can commit funds. The platform team registers both destinations in a central governance project. Each stable identifier links to an owning team in the company’s catalog. Only platform administrators can change entries.

The purchasing agent searches the registry and discovers both destinations. That result is candidate configuration, not authorization. The agent has an Agent Identity. Agent Gateway policy permits it to reach the catalog server but does not permit the purchase-order endpoint. The catalog server separately checks the caller’s read permission.

A developer later registers a plausible test purchase-order endpoint. It appears in search, but the production agent still cannot call it: no gateway policy permits the route, and the endpoint requires operation-level permission. The owner removes the misleading record to restore trustworthy discovery.

Search returns every registered destination, but the agent reaches only the one that gateway policy permits.

Common exam traps

• Choosing Agent Registry as the component that authenticates every runtime request or authorizes a business operation.
• Assuming that “registered,” “discoverable,” “bound,” or “has a valid Agent Card” means “approved to invoke.”
• Using a logical agent identifier as though it were the agent’s authenticated principal.
• Giving an agent Editor or Admin access so it can enroll or modify its own dependencies.
• Treating automatic registration as a complete cross-project inventory.
• Assuming that deleting a manual registration stops or deletes the underlying runtime.

What to remember

• Treat Agent Registry as a governed map of capabilities, not an access key.
• Assign an accountable owner and lifecycle process to every inventory entry.
• Separate registry read and mutation permissions with least privilege.
• Use discovery results as candidates; use runtime identity and policies to authorize calls.
• Keep catalog records synchronized with deployed components and retirement.

Knowledge check

References

• Google Cloud, Agent Registry overview
• Google Cloud, Agent Registry data model
• Google Cloud, Agent Registry key concepts
• Google Cloud, Search for agents, tools, and skills
• Google Cloud, Agent Registry roles and permissions
• Google Cloud, Manage agents
• Google Cloud, Agent Gateway overview
• Google Cloud, Authenticate to tools and resources