5.4 Enterprise Fleet Governance: ADC, App Hub & Agent Registry

Across Rosku Bank’s 25 engineering teams, developers have spun up 80 agents and MCP servers in separate Google Cloud projects:

Pre-Deployment Chaos: Teams provision Cloud Run and Agent Runtime instances manually without Agent Gateway or Model Armor attached!
Midnight Outage Mystery: When an internal Payment MCP server crashes at 2:00 AM, the SRE team cannot tell which business unit owns it, whether it is Mission-Critical, or which downstream AI agents depend on it!
Orchestrator Routing Hallucinations: Two different teams register a Commercial-Loan Agent and a Retail-Loan Agent with nearly identical vague descriptions ("Handles bank loan questions"), causing the root orchestrator to misroute 40% of customer inquiries!

1. Key Concept Definitions: The 3-Pillar Fleet Governance Stack

1. Application Design Center (ADC)

Allows platform architects to author, version, and publish pre-hardened infrastructure templates (embedding Agent Gateway, Model Armor, and least-privilege IAM) that developers deploy from.

2. App Hub

Organizes underlying cloud resources, microservices, and AI agents into logical business applications tagged with business owners, environment (Prod/Dev), criticality, and dependency graphs.

3. Agent Registry

The centralized enterprise directory for registering, discovering, and governing deployed A2A Agent Cards and MCP tool servers across all projects—eliminating Shadow AI and duplicate tools.

4. Semantic Metadata Governance

Enforcing mutually exclusive, specific skill descriptions and strict JSON schemas in Agent Registry so orchestrator LLMs route tasks accurately without hallucinating.

2. Interactive Fleet Governance Lifecycle Explorer

Switch between the 3 Governance Lifecycle Modes below and click the 4 stages to see how Application Design Center (Pre-Deploy), App Hub (Operational Topology), and Agent Registry (Runtime Discovery & Deprecation) govern Rosku Bank’s agent fleet:

PRE-DEPLOYMENT GOVERNANCE: APPLICATION DESIGN CENTER

1. Authoring Pre-Approved Agent Infrastructure Blueprints

How It Works

Central platform architects design versioned application templates in Application Design Center (ADC) backed by Terraform IaC.

Core Architecture Rule

Use Application Design Center whenever you need to standardize pre-deployment security blueprints before developers provision new agents!

3. Master Governance Matrix: ADC vs. App Hub vs. Agent Registry

Each of these three enterprise governance services owns a distinct stage of the agent lifecycle:

Governance Service	Lifecycle Stage	What It Governs	Primary Architectural Trigger
Application Design Center (ADC)	Pre-Deployment (Day 0)	Versioned, security-hardened infrastructure templates & blueprints (Terraform IaC).	“Prevent developers from deploying agents without Agent Gateway & Model Armor,” “standardize pre-approved blueprints.”
App Hub	Operations & Incident Response (Day 2)	Logical business application grouping, owner contacts, environment tags (`Prod`), criticality (`Mission-Critical`), and dependency topology.	“Determine business owner and blast radius during a severity-1 outage,” “map cloud resources to business applications.”
Agent Registry	Runtime Discovery & Catalog (Day 1–2)	Centralized directory of deployed A2A Agent Cards (`/.well-known/agent.json`) and MCP tool servers, including semantic metadata & versions.	“Stop duplicate MCP tool builds across 20 teams,” “fix orchestrator routing errors caused by overlapping descriptions.”

4. Real-World Deep Dive: Semantic Metadata & Retiring Vulnerable Agents

Why Does Bad Metadata in Agent Registry Cause Orchestrator Hallucinations? When an orchestrator LLM chooses between registered sub-agents or MCP tools, it does not read their Python source code—it reads only the semantic metadata (description, skills, examples, and parameter JSON Schema) published in Agent Registry! If two billing agents register vague, overlapping descriptions, the orchestrator guesses randomly. Winning Fix: Enforce Semantic Metadata Governance in Agent Registry so every registered agent and tool has mutually exclusive boundaries and explicit parameter schemas!
Why Is Agent Registry Critical for Securing MCP tools/list? While Model Armor scans MCP tools/call payloads inline, MCP tools/list discovery metadata bypasses inline Model Armor sanitization! Governing and vetting MCP servers inside Agent Registry ensures orchestrators only discover trusted, non-malicious tool definitions.
How Do You Safely Decommission a Vulnerable Agent Version (v1.0)? When replacing a vulnerable Agent v1.0 with a patched v2.0, execute two complementary actions:
- Inbound (Discovery): Deprecate or remove the v1.0 endpoint in Agent Registry so orchestrators resolve and route all new tasks to v2.0.
- Outbound (Data Access): Revoke the IAM Allow roles and Principal Access Boundary (PAB) bindings on v1.0’s Managed Agent Identity so any lingering v1.0 process can no longer query backend databases!