"Agent-ready data governance" is mostly marketing language for applying existing Unity Catalog primitives to AI workloads. The actual production mechanics are less novel than the branding suggests. Here's how each of your items maps to what's really available:

Agent permissions and tool permissions. Agents deployed as model serving endpoints run under a service principal. You scope that service principal's UC privileges exactly like you would a Spark job: GRANT EXECUTE ON FUNCTION for UC functions used as tools, SELECT on tables the agent needs, and endpoint-level ACLs for the serving endpoint itself. For MCP tools, they can be registered as Unity Catalog securables and governed with the same grant/revoke model. One service principal per agent (or per agent group) makes this manageable across 20+ domains.

Vector Search access. UC governs the index at the schema level, CREATE TABLE privilege is required to create one, and endpoint-level ACLs control who can query it. The big limitation to know upfront: row/column-level security is NOT supported on Vector Search today. If you need data isolation within an index (e.g., one index serving multiple domains with different access rights), you have to implement filtering at the application layer using the filter API rather than relying on the platform to enforce it.

Prompt governance. This is handled through AI Gateway guardrails. You attach service policies to a model service or MCP service endpoint. Policies run on both input and output, and you can layer built-in ones (PII detection, jailbreak detection, unsafe content) with custom ones backed by a UC function. For cross-domain deployments, you configure different policies per endpoint rather than one global policy.

Business glossary. Unity Catalog's Business Semantics (formerly "AI-ready metadata") lets you attach natural-language descriptions, synonyms, and semantic labels to tables and columns. This is what feeds Genie and helps agents understand what data means without you hardcoding it in every prompt. Governance here is just standard UC metadata management.

MCP tools. Registered through AI Gateway as UC securables. You control which identities can invoke which MCP server, apply service policies per server, and track usage through system tables. The pattern teams are using in production is to register one MCP server per domain and grant access to agents in that domain's service principal group.

Cross-domain reasoning. This is the least mature piece and the most architecture-dependent. The platform doesn't have a native concept of "cross-domain agent federation." What you actually build is either a supervisor/orchestrator agent that routes to domain-specific agents, or a single agent with tools spanning multiple domains where access is controlled at the tool/function level. The governance in that case is: does the agent's service principal have privileges on all the UC objects across the domains it needs to touch? That's a grant management question, not a new feature.

In practice, teams handling 20+ domains are leaning heavily on groups and group-based grants rather than per-agent grants, and using separate catalogs or schemas per domain so you can apply coarse-grained catalog/schema-level grants without managing hundreds of object-level permissions.