Finding an enterprise’s AI agents is not the same as governing them. On October 30, 2026, Google Cloud introduced cross-project management boundaries for Agent Registry in preview. A central management project can discover and search supported agents, Model Context Protocol (MCP) servers and tools distributed across member projects. For technology leaders, this is an opportunity to build an inventory with explicit ownership—but it is not proof that every agent is safe, registered or authorized to act.
The key design decision is the boundary itself: which projects belong in the catalog, who can change membership, and what a central viewer is permitted to learn. A registry can reduce discovery gaps only if the organization’s project taxonomy, access policies and onboarding procedures remain reliable.
What changed on October 30—and what is still preview
Agent Registry’s single-project capabilities reached general availability earlier in 2026. The October 30 update specifically adds cross-project management boundaries in preview, according to Google’s release notes. Google documents a management project that aggregates supported agents and MCP servers from member projects within a Resource Manager boundary. A boundary may cover an organization or folder, or use Resource Manager tags to partition membership, such as production versus development.
This is a discovery and governance topology, not a claim that one project automatically receives execution rights in all others. Google distinguishes the management project from member projects where teams build and run workloads. Its documentation also makes clear that the preview is subject to pre-general-availability terms. Buyers should validate their exact regional, IAM and resource coverage before treating the feature as a production control.
The inventory problem is larger than a list of agent names
An agent entry is useful only when it answers operational questions. Who owns it? Which workload identity does it use? Which endpoints and tools can it reach? Which data classes can it process? Is it deployed, retired, experimental or awaiting approval? Where are the logs and emergency disable controls? Registry metadata can help locate components, but it should be joined with authoritative IAM, deployment and service-management evidence.
For example, an MCP server might appear in a catalog yet have an overly broad service account. Conversely, a legitimate external service might be absent because its endpoint was not registered. Neither condition can be inferred from a catalog count alone. Treat discovery coverage and permission correctness as separate metrics.
Design the boundary before centralizing visibility
Google describes folder-wide, organization-wide and optional tag-filtered boundaries. An unfiltered folder boundary can include all child projects, which may be appropriate for a dedicated engineering organization but too broad for a mixed business hierarchy. Tags provide a way to group projects without reshaping folders; inherited tag values can also affect membership. The organization therefore needs change controls over who can set or inherit boundary-defining tags.
A practical starting point is one management boundary for development and another for production, where supported by the hierarchy and tag model. The goal is not to create more dashboards. It is to prevent a discovery or policy change intended for testing from silently expanding its reach to production projects. A central governance team should be able to review membership changes, while project teams retain responsibility for workload configuration.
Original architecture: catalog visibility versus execution authority
Six tests for an enterprise pilot
- Coverage: Register or discover a known test set of supported agents, MCP servers and tools. Compare the registry result with the deployment inventory and investigate omissions rather than assuming complete coverage.
- Membership: Add and remove a test project using the intended folder or tag mechanism. Confirm that search results change as documented and that only authorized administrators can alter boundary-defining tags.
- Least privilege: Test viewer, editor and administrator roles separately. Confirm that a catalog reader cannot modify resources merely because those resources appear in a central search.
- Lifecycle: Deploy, update and retire a test component. Measure the time until catalog metadata reflects the change, and define how stale entries are flagged.
- Incident response: Start with a suspicious MCP server entry. Can an incident responder identify the owner, endpoint, deployment project and appropriate local containment path without relying on guesswork?
- Preview constraints: Document supported regions, quotas, missing resource types, service terms and rollback procedures. Re-test before moving from a pilot to production governance.
Do not confuse a catalog with a security boundary
Discovery provides an index; authorization still depends on workload identities, network policies, tool-specific permissions and application decisions. An inventory also cannot prove that prompts, responses or external tool outputs are safe. For that reason, security architecture should pair the registry with independent access reviews, supply-chain provenance checks and runtime monitoring. A newly discovered agent should be a trigger for due diligence, not automatic approval.
Related CorpExcellence research includes four control planes for enterprise agents, third-party agent risk assessment and MCP tool supply-chain exposure. The AI Risk Assessment hub collects additional governance analysis.
The management decision
Before approving a cross-project rollout, require a named catalog owner, a defined boundary membership rule, a measured discovery coverage rate and an escalation process for unknown components. Run the pilot with synthetic resources and a small set of projects. Because the cross-project feature is still preview, an enterprise should not make the catalog its sole control for production authorization or incident containment. A useful registry makes ownership and exceptions visible; a safe operating model still needs controls outside the registry.
Primary sources and further reading
- Google Cloud Agent Registry release notes (October 30, 2026 entry).
- Google Cloud: Cross-project boundaries (preview documentation, reviewed October 31, 2026).
- Google Cloud: Set up Agent Registry (reviewed October 31, 2026).
Leave A Comment