Governance: Registries, Versions and Ownership

Someone must own every endpoint

As servers and agents multiply, sprawl and risk grow. Keep a registry of approved MCP servers and Agent Cards with an owner, purpose, data classification, required scopes, version and review date. Require a security review before adding entries, pin and review versions, and set a deprecation process: announce changes, support the old contract for a period, then retire it. Treat tool names/schemas and Agent Card skills as public APIs with semantic versioning. Define SLOs for shared servers and agents, assign on-call ownership, and review the audit logs periodically. Provide a fast path for approved low-risk servers so teams do not bypass governance with shadow integrations.

A registry entry

Fields that make a server or agent reviewable and owned.

{
  "name": "orders-mcp",
  "kind": "mcp-server",
  "owner": "orders-platform-team",
  "purpose": "Read order status for support agents",
  "data_class": "customer-internal",
  "scopes": ["orders:read"],
  "version": "1.4.2 (pinned, hash recorded)",
  "tools": ["get_order_status"],
  "review": { "security": "2026-09-14", "next": "2027-03-14" },
  "deprecation_policy": "90 days notice for breaking changes"
}

Quick check: Why treat tool schemas and Agent Card skills as public APIs?

• They are secret
• Other systems and prompts depend on them, so changes can break callers
• They never change
• They replace tests