CONCEPT Cited by 1 source
Governance travels with resources¶
Definition¶
Governance travels with resources is the architectural principle — canonicalised in Databricks' 2026-05-20 four-pillars post — that agent governance must live in the data and services that agents access, not in the agent code or framework that calls them. The corollary: a single policy on a resource (table, MCP server, model endpoint) applies to every agent that calls it, regardless of which framework / language / vendor produced the agent.
Canonical statement on the wiki¶
"Governance can't live only in the agent layer. It also needs to live in the data and services that agents access, whether those services are Databricks-managed or not. An agent built on LangGraph and one built on CrewAI both query the same Unity Catalog, invoke the same governed MCP servers, and flow through the same AI Gateway. The framework is irrelevant. Governance travels with the resources, not the code that calls them." — Source: sources/2026-05-20-databricks-governing-ai-agents-at-scale-with-unity-catalog
"The end result is that governance becomes a property of your platform rather than something you rebuild for each new framework or model." — Source.
The forcing function¶
The principle is a defensive architecture move against a structural failure mode: agent frameworks ship weekly; if governance is bound to the framework, every framework update is a governance migration.
"Every enterprise AI governance strategy eventually faces the same forcing function: a new team picks a different framework, a new provider releases a better model. If your governance is built into today's tooling choices, you're on a treadmill: every new framework is a new integration, every new model is a new policy." — Source.
The economic argument: the cost of governance bound to frameworks is super-linear — every new framework × every existing policy = a new integration. The cost of governance bound to resources is constant — one resource, one policy, applies to every framework. The principle asserts the second economics is the only viable one at enterprise scale.
Two layers of "travel"¶
The post enumerates two parallel layers where the principle applies:
- Tool-call layer — "An agent built on LangGraph and one built on CrewAI both… invoke the same governed MCP servers." The tool-call standard is MCP: "register once in Unity Catalog, invoke from any framework with the same permissions and audit trail." Service Policies attach to the MCP server, not the calling agent — so the policy travels with the tool.
- Model-call layer — Unity AI Gateway provides "a single, governed endpoint for Databricks-hosted models, Azure OpenAI, AWS Bedrock, and Anthropic, with one policy, one audit trail, and one cost-attribution layer across providers." The policy attaches to the gateway endpoint, not the calling framework — so the policy travels with the model surface.
A third layer — telemetry — uses MLflow tracing: "auto-instruments LangChain, LlamaIndex, AutoGen, the OpenAI SDK, the Anthropic SDK, and more, with traces landed in Unity Catalog as tables without custom instrumentation per framework." The trace destination is the resource (UC tables), not the framework.
Frameworks named (governance-agnostic-to)¶
The post enumerates the supported framework set explicitly:
- LangGraph
- CrewAI
- LangChain
- LlamaIndex
- AutoGen
- OpenAI SDK
- Anthropic SDK
Plus model providers (gateway-unified):
- Databricks-hosted (via Foundation Model API)
- Azure OpenAI
- AWS Bedrock
- Anthropic
What "travels with the resource" specifically means¶
For each Pillar 1 control surface, the policy lives with the resource:
| Control | Resource | Policy lives in |
|---|---|---|
| Data permissions (OBO) | UC table | UC table-level grants |
| Tool admission (Service Policies) | MCP server | UC function attached to MCP |
| Content checks (Guardrails) | Model endpoint | Gateway-side policy on the endpoint |
| Cost (Budgets) | User identity | Gateway-side per-user threshold |
The framework calling these resources does not appear in the policy in any of the four cases. That's the load-bearing property.
Sibling principles in adjacent stacks¶
- MongoDB's registry-as-governance-precondition (sources/2026-05-11-mongodb-fighting-tool-sprawl-the-case-for-ai-tool-registries) — coordination at the inventory layer. Different mechanism (a registry of tools, not a catalog of tables/MCPs/models), same outcome (governance applies regardless of which team built the agent).
- Cloudflare's three-pillar gateway model (sources/2026-04-20-cloudflare-internal-ai-engineering-stack) — single gateway with BYOK + per-user UUID. Same resource-bound, not framework-bound shape; specialised for Cloudflare's internal-app workloads.
- Redpanda's governed agent data access (sources/2025-10-28-redpanda-introducing-the-agentic-data-plane) — Gallego's ADP names "the data plane is the substrate" — same principle from the streaming-broker side rather than the catalog side.
Limits of the principle¶
The post asserts the principle without showing a worked example of (e.g.) the same Service Policy applying unmodified to a LangGraph agent and a CrewAI agent against the same MCP. The claim rests on:
- MCP being the actual interop substrate — true for MCP-compliant tools, undefined for tools an agent invokes through non-MCP paths (direct REST, language-native SDK calls).
- Model providers having a uniform API — Unity AI Gateway provides "unified APIs" for the named providers; new providers without compliant adapters fall outside the principle until adapted.
- Frameworks calling through the gateway — a framework that hits a model provider directly (bypassing the gateway) escapes the gateway-side policy. The principle requires the gateway is the only path (patterns/central-proxy-choke-point).
The principle is therefore architectural, not automatic — it requires the central-proxy-choke-point discipline to be enforced.
Seen in¶
- sources/2026-05-20-databricks-governing-ai-agents-at-scale-with-unity-catalog — first wiki canonicalisation as Pillar 4 (2026-05-20).
Source¶
- Originating post: https://www.databricks.com/blog/governing-ai-agents-scale-unity-catalog
Related¶
- concepts/four-pillars-of-agent-governance — Pillar 4 of the four.
- concepts/data-centric-ai-governance — sibling principle (Pillar 2) for the data-half of the same argument.
- concepts/centralized-ai-governance — sibling Cloudflare framing.
- systems/model-context-protocol — the tool-layer interop substrate.
- systems/unity-ai-gateway — the model-layer interop substrate.
- systems/mlflow — the telemetry-layer interop substrate.
- patterns/central-proxy-choke-point — the discipline this principle requires.
- patterns/ai-gateway-provider-abstraction — the gateway-layer mechanism that enables it.