Skip to content

CONCEPT Cited by 1 source

Four pillars of agent governance

Definition

The four pillars of agent governance is Databricks' 2026-05-20 framing for the non-overlapping, stacked architectural surfaces an enterprise needs to govern a non-deterministic, cross-department agent population:

  1. Delegated access — three-layer runtime control: permissions (OBO) → per-call policies (Service Policies) → content guardrails (Guardrails).
  2. Data-centric AI governance — agent governance is data governance (concepts/data-centric-ai-governance); audit substrate is the Unity Catalog-managed lakehouse with Inference Tables capturing full prompt/response payloads, joinable with business data, feedable into Lakewatch for active threat detection.
  3. Cost intelligence — Unity AI Gateway usage-tracking + Budgets with per-user / per-group thresholds, joinable with business outcomes for cost-vs-outcome analysis.
  4. Open and interoperable — governance travels with resources, not frameworks; same UC + AI Gateway across LangGraph / CrewAI / OpenAI SDK / Anthropic SDK / AutoGen / LlamaIndex; same gateway across Databricks-hosted / Azure OpenAI / AWS Bedrock / Anthropic.

Why four (not three)

The framing is explicitly different from the wiki's prior canonicalisation of centralized AI governance (the three-pillar shape from the 2026-04-17 Unity AI Gateway launch: security+audit / cost / observability). Two changes:

Three-pillar (2026-04-17, coding-agent scope) Four-pillar (2026-05-20, org-wide agent scope)
Centralised security + audit (1) Delegated access (three-layer: OBO + Service Policies + Guardrails)
Single bill + cost controls (3) Cost intelligence
Full observability in the Lakehouse (2) Data-centric AI governance (audit + telemetry as a data-governance problem)
— (4) Open and interoperable (governance-travels-with-resources)

Two structural additions:

  • Pillar 1 (Delegated access) — runtime access control is split out as its own pillar, distinct from audit. The three-layer composition (permissions / policies / guardrails) is the load-bearing detail.
  • Pillar 4 (Open and interoperable) — framework-agnosticism is promoted from an implementation property to a governance pillar. The argument: governance bound to a framework is governance that has to be migrated every time the framework version bumps.

Pillar 2 collapses the prior security+audit and full observability pillars into a single principle: AI governance is data governance (concepts/data-centric-ai-governance).

Why these four are non-overlapping

"In practice, these three layers work together: permissions control who can call what. Service Policies control whether a specific tool call should proceed in the context of a given request. Guardrails control what content flows in and out." — Source: sources/2026-05-20-databricks-governing-ai-agents-at-scale-with-unity-catalog

Each pillar covers a question the others can't:

  • Pillar 1 (access) answers can the agent reach this resource at all? / should this specific call proceed? / is this content safe? — the gate at every step of the request.
  • Pillar 2 (data) answers what data did the agent actually access, was it good data, and what did it do with it? — the substrate of the gate plus the forensic record of what got through.
  • Pillar 3 (cost) answers who's paying for this and is it worth it? — the operational dimension that's invisible to the gate and the substrate.
  • Pillar 4 (open) answers will any of pillars 1-3 still apply when the framework / model / vendor changes? — the durability dimension that protects the investment in pillars 1-3.

Why these four are stacked

The pillars are not parallel concerns — they have a dependency order:

Pillar 4 (Open + interoperable)
    ↑ governs the durability of
Pillar 3 (Cost intelligence)
    ↑ adds operational dimension to
Pillar 2 (Data-centric AI governance)
    ↑ provides the substrate for
Pillar 1 (Delegated access)

Pillar 1 needs Pillar 2's substrate (where do permissions live? in UC). Pillar 3 needs Pillar 2's joinable-data property (cost-vs-outcome requires joining inference-tables with business tables). Pillar 4 protects the durability of all three.

Distinct from sibling framings

  • Sibling to concepts/governed-agent-data-access (Redpanda's Gallego framing — two-axis: access controls + observability). The Redpanda framing is two-axis (access + audit); the Databricks framing is four-pillar (access + audit-as-data-governance + cost + openness). Both reject "governance is a compliance bolt-on" but compose the surface differently.
  • Sibling to MongoDB's registry-as-governance-precondition — the upstream-of-policy argument. MongoDB argues a tool registry is the structural precondition for any of the four-pillar properties; Databricks' equivalent is UC itself, which is both the registry and the policy substrate.

Canonical statement on the wiki

"Unity Catalog has governed enterprise data since 2021 through a single permissions model, unified lineage, and a consistent audit trail across every asset. We're now extending that same governance infrastructure to cover every asset an AI system touches: LLMs, MCP servers, skills, and agents." — Source.

The four pillars are the architectural decomposition of "that same governance infrastructure" extended to AI assets.

Seen in

Source

Last updated · 542 distilled / 1,571 read