How do you govern prompts, models, and tools in one platform?

Summary

• A production GenAI application has three governed artifacts: the prompts that steer a model, the models themselves, and the tools an agent calls. Governing them in one platform means one permission model, shared versioning, unified lineage, and runtime enforcement across all three.
• On Databricks, Unity Catalog governs models and tools as securable objects using the same EXECUTE, CREATE, and MANAGE privileges you use for data.
• The MLflow Prompt Registry (in Beta) versions prompts as Unity Catalog objects, with immutable versions and movable aliases like production and staging, plus lineage to the runs that used them.
• The Unity Gateway enforces access, rate limits, budgets, and guardrails when a model or tool is called, with on-behalf-of permissions so an agent runs with the requester's scope.
• Unity Catalog tracks lineage across prompts, models, and tools and logs every access in system tables for audit and cost attribution.

How do you govern prompts, models, and tools in one platform?

A production GenAI application is built from three moving parts: the prompts that steer a model, the models themselves, and the tools an agent calls. Governing them in one platform means putting all three under a single permission model, versioning them so you can promote and roll back safely, tracing which version produced a given result, and enforcing access at the moment a request runs. On Databricks, Unity Catalog governs models and tools as securable objects, the MLflow Prompt Registry versions prompts as Unity Catalog objects, and the Unity Gateway enforces access at runtime, so the three are governed together instead of in separate systems.

Why prompts, models, and tools need shared governance

Treated separately, these assets drift. A prompt changes and no one can say which version an output came from. A model or tool gets exposed with looser access than the data behind it. An agent calls an external service with a shared service identity instead of the user's own permissions. Shared governance closes those gaps: one place to register each asset, one privilege model, one lineage graph, and one audit trail across prompts, models, and tools.

Key capabilities to evaluate

Capability	Why it matters
One securable model across asset types	Prompts, models, and tools should use the same permission model as your data, not separate per-tool access lists.
Versioning and safe promotion	Immutable versions plus movable aliases (like production and staging) let you roll forward and back without editing code.
End-to-end lineage	You should be able to trace which prompt version, model, and tool produced a given output.
Runtime enforcement	Access, rate limits, and guardrails should apply when a model or tool is called, not only at registration.
Identity and scope	Agent calls should run with the requester's permissions, not a broad shared identity.
Audit and observability	Every access and call should be logged for compliance and cost attribution.

How Databricks governs prompts, models, and tools

Databricks puts the three artifacts under Unity Catalog, the same governance layer that secures your data.
Prompts. The MLflow Prompt Registry (in Beta) stores prompts as Unity Catalog objects with Git-like versioning: each edit creates an immutable, auto-numbered version, and movable aliases such as production or staging point at the version you want live, so you promote or roll back without code changes. Prompts carry tags, and MLflow links a prompt version to the application and evaluation runs that used it. Registering and using prompts follows Unity Catalog privileges (CREATE FUNCTION, EXECUTE, and MANAGE on the schema).
Models. Models are registered as Unity Catalog objects and governed with the same privileges used for data: EXECUTE to call a model, CREATE to register new ones, and MANAGE to administer them.
Tools. Tools are governed as Unity Catalog functions and as MCP servers and connections, so an agent's tool calls are authorized against the catalog like any other object.
At runtime, the Unity Gateway routes model and tool requests through a central control plane, adding access control, rate limits, budgets, and guardrails, with on-behalf-of permissions so an agent acts with the requester's scope rather than a shared service identity. Unity Catalog tracks lineage across these assets, and system tables log every access for audit and cost attribution. See generative AI capabilities and LLMOps for how prompts, models, and tools fit together.

FAQs

How are prompts governed on Databricks?

The MLflow Prompt Registry (in Beta) stores prompts as Unity Catalog objects with immutable versions and movable aliases (such as production and staging), plus tags and lineage to the runs that used them. Access follows Unity Catalog privileges on the schema.

Can models and tools use the same permissions as data?

Yes. Models are Unity Catalog objects and tools are Unity Catalog functions, MCP servers, and connections, all governed with the EXECUTE, CREATE, and MANAGE privileges used for data.

What governs an agent's requests at runtime?

The Unity Gateway routes model and tool requests through a central control plane with access control, rate limits, budgets, and guardrails, and on-behalf-of permissions run the call with the requester's scope.

How do I trace which prompt or model produced a result?

MLflow links a prompt version to the application and evaluation runs that used it, and Unity Catalog tracks lineage across models and tools, so you can trace an output back to the versions behind it.

Is activity audited?

Yes. Unity Catalog logs access to prompts, models, and tools in system tables, which supports compliance and cost attribution across teams and workloads.