Google Cloud’s Agent Registry can now provide a shared view across projects, but that does not make it a unified permission system for agent execution. Google’s October 30 release notes list cross-project management boundaries as Preview, describing centralized discovery, search, and governance of agents, MCP servers, and tools from a management project.
As of November 3, the documentation supports a distinction: the feature centralizes registry administration and visibility. Permission for agents to communicate with registered services follows a separate authorization path. Understanding that separation matters before treating the catalog as an operational control plane.
What the management project centralizes
According to Google’s boundary documentation, a boundary is defined on a Resource Manager folder or organization. Without a tag filter, it includes child projects; optional tag filters can partition membership.
Member projects continue hosting their compute workloads. The management project centralizes registry administration, metadata, API configuration, billing, and quota for boundary operations. Google’s setup guide says creating the agent-management capability enables the Agent Registry API on the management project, where administrators must grant the relevant roles.
A shared view still has location limits
Queries from the management project return auto-discovered resources from member projects in the queried location, alongside qualifying resources registered directly in the management project. They do not aggregate resources across different locations. A cross-project result therefore should not be read as an inventory covering every location.
Discovery coverage depends on deployment and registration
Google’s data-model documentation lists supported automatic-discovery paths, including specified Agent Runtime, GKE, and Cloud Run deployments. That support is conditional on the documented products and configurations; it is not evidence that every deployment on those platforms will appear.
Remote components, unsupported runtimes, and agents lacking the documented protocol support require manual registration. Where registration happens also affects visibility: manually registered Service and Binding resources in member projects remain local. Google says those resources must be created in the management project for boundary-wide visibility.
Other resource types retain narrower scope. Custom standalone skills, skill revisions, publishers, and AI applications are project-scoped and are not aggregated from member projects. The central catalog therefore has documented exclusions even when project membership is configured correctly.
Registry access does not authorize agent communication
The roles and permissions documentation says a viewer on the management project can discover and search agents and MCP servers across its attached boundaries without viewer access on each member project. This expands discovery access through the management project.
Registry roles govern discovery and registry management. Google separately documents Agent Gateway and IAP egress policies as the authorization path for agent communication with registered services, endpoints, and MCP servers. Finding an endpoint in the registry does not itself grant permission to use it.
Metadata permissions also deserve attention. Google warns that editor and admin roles can change registry metadata and should be restricted to trusted administrators, rather than agents. For related coverage of authority during execution, see our examination of ServiceNow’s AI Passport.
The service perimeter needs separate interpretation
Google says VPC Service Controls restrictions apply to registry interactions in the management project, while discovery can include resources in member projects outside that service perimeter. Teams should therefore avoid assuming that catalog visibility and workload perimeter membership describe the same boundary.
What teams should verify before relying on the catalog
Our editorial recommendation is to map folder and tag membership, queried locations, supported discovery configurations, manual-registration placement, and management-project IAM. Review communication authorization separately. These are proposed checks, not tests performed for this article. Our Google Cloud migration-agent coverage examines another boundary: who owns proposed changes and cutover.
The evidence remains vendor documentation. No account configuration or API behavior was tested, and Preview availability was not checked for a specific organization. The reviewed sources establish neither discovery completeness, refresh delay, reliability, practical scale, typical cost, nor improved security outcomes.