Skip to content

CONCEPT Cited by 10 sources

Governed agent data access

Definition

Governed agent data access is a two-axis design surface — access controls (which agent gets what data, on whose behalf, under what consent) + observability (what did the agent actually do, why, and can the trail be replayed) — framed as the primary CIO-facing design concern for enterprise AI-agent deployment, rather than as a compliance add-on bolted onto a product that was designed without it.

Canonical statement on the wiki

Alex Gallego's 2025-10-28 framing (Source: Gallego 2025-10-28):

"The fear from CIOs is not the code of the agent itself, it is governance. In simple terms, it is access controls: can I trust that data is accessed by the right things? And observability: when things go wrong, can I understand what happened?"

"If agents are given free rein over sensitive, regulated data, with no ability to audit their work and no global governance to enforce boundaries, we are headed for disaster."

Why the framing inverts

Most 2024-2025 agent product discourse centres on quality (hallucination, reasoning depth, tool-use correctness) and capability (how many tools, how fast, how cheap). Gallego's inversion: for regulated enterprises, quality and capability are necessary but not sufficient — the blocking concern is that the agent might access the wrong data (access-control failure) or that when something goes wrong nobody can explain it (observability failure). Quality failures are embarrassing; governance failures are "disaster".

The rhetorical move reframes agent-platform purchasing from "what can it do?" to "can I trust it, and can I prove what it did?".

The structural foil: API-era root-token permissions

Gallego's canonical contrast verbatim:

"the new digital workforce often interacts with systems created in the API era of root-token permissions, with all-or-nothing as the norm. Agents need centralized governance, enforceable guardrails, and the ability to explain when things go wrong."

Legacy enterprise integration patterns — one service-account token per integration, broad scopes, rotate quarterly at best — worked for human-operated systems-integration where a small number of long-lived service accounts had known scopes. They fail for agent populations because:

  1. Agents operate on behalf of different users with different entitlements. A shared agent-service token cannot enforce per-caller access policy.
  2. Agents are short-lived per-task but numerous; rotating long-lived tokens doesn't match the threat model of an agent instance that might leak a credential in a response.
  3. Audit trails keyed on service-account identity cannot answer "what did this user's agent do with their data?".

The workaround: on- behalf-of (OBO) authorization — the pattern Gallego names as the first shipped ADP feature.

The two axes

Axis 1: Access controls

Concrete substrate named in the Redpanda ADP announcement verbatim: "OBO to task-based authentication, DLP hooks, per- agent consent workflows".

  • OBO — the agent's tool calls carry the caller's identity + scoped consent, not a shared agent-service token. Resolves the per-caller-entitlement failure of legacy integration shapes.
  • Task-based authentication — the identity attached to a tool call is scoped to the specific agent task it was authorized for, not an open-ended session token.
  • DLP hooks — content-filtering at the proxy boundary (MCP dynamic content filtering) to prevent e.g. PII exfiltration.
  • Per-agent consent workflows — user + agent + scope + duration as a first-class audit-able artefact, not a checkbox.

Axis 2: Observability

Concrete substrate verbatim: "immutable audit trails with configurable retention", "replayable audits", "records intent, and enables replayable audits".

  • Immutable audit trail — every tool call by every agent on every data surface recorded to an append-only log (natural fit for Redpanda's streaming substrate).
  • Intent recording — capture what the agent tried to do (the plan / reasoning) + what it actually did (the tool calls), so audits can reconstruct intent + action.
  • Replayable audits — re-execute the audit trail against a point-in-time snapshot of the data + policy state, to reproduce what the agent saw at decision time.
  • Configurable retention — per-regulation retention windows (SOX / HIPAA / GDPR), not one-size-fits-all.

Relationship to adjacent wiki concepts

  • Autonomy (enterprise agents) — the 2025-04-03 Gallego framing of what enterprise agents are. Governed agent data access is the governance layer the autonomy vision requires to be safely deployed — autonomy is the capability, governance is the precondition.
  • Centralized AI governance — peer concept canonicalised from Databricks Unity AI Gateway 2026-04-17 post. Unity AI Gateway + ADP's policy/observability layer are two vendors converging on the same structural pattern from different starting points (Unity from the Catalog + Governance side; ADP from the Streaming + Agent side).
  • Coding-agent sprawl — the problem that motivates centralized governance: many agent vendors × many tools × many users × no single enforcement point = unmanageable risk surface. Governed agent data access is the structural answer.
  • AI agent guardrails — broader safety-control vocabulary; governed data access is the data-plane subset (as distinct from prompt-injection-mitigation, output-filtering, agent-sandboxing guardrails).
  • Business-group authorization gating — Pinterest's 2026-03-19 canonicalisation of org-scope tool access; related mechanism for Axis 1 at the group altitude rather than the per-caller altitude.
  • Data Plane Atomicity — Redpanda's BYOC tenet (no externalised runtime dependencies) composes naturally with governed data access: if the data plane doesn't leave the customer's VPC, governance enforcement is structurally simpler because the enforcement point and the data are co-located.

Mechanism patterns that operationalise the framing

  • patterns/on-behalf-of-agent-authorization — OBO as the Axis-1 mechanism.
  • patterns/mcp-as-centralized-integration-proxy — MCP as the choke-point where both axes are enforced.
  • patterns/central-proxy-choke-point — general form of the same idea; single-enforcement-point architectural stance.
  • dynamic-content-filtering-in-mcp-pipeline — DLP / content-filtering as the Axis-1 data-shape-level enforcement mechanism.
  • three-layer-agent-control — Databricks' (2026-05-20) three-layer composition of permissions + Service Policies + Guardrails as the structured Axis-1 mechanism: each layer keys on a different decision input (identity / tool-call / content) so the union of failure modes is covered. Sibling to but more granular than Gallego's "access controls" axis.
  • policy-as-uc-function-attached-to-mcp — Databricks' (2026-05-20) instance of policy-as-code attached to the resource (MCP server), not the agent. Concrete instance: systems/uc-service-policies.
  • inference-payload-table-for-audit — Databricks' (2026-05-20) full-payload-replayable-evidence shape for the Axis-2 observability axis. Concrete instance: systems/inference-tables. The lakehouse-resident substrate breaks the completeness-vs-cost tradeoff that Gallego's "replayable audits" requirement implies.

Sibling four-pillar framing (Databricks, 2026-05-20)

The 2026-05-20 Databricks four-pillars post restates Gallego's two-axis framing in a more granular four-pillar decomposition (concepts/centralized-ai-governance). The two framings agree on the structural shape but differ in granularity:

Gallego (2025-10-28, two-axis) Databricks (2026-05-20, four-pillar)
Axis 1: Access controls Pillar 1: Delegated access (three-layer)
— Pillar 4: Open + interoperable (governance survives framework changes)
Axis 2: Observability Pillar 2: Data-centric AI governance (concepts/centralized-ai-governance)
— Pillar 3: Cost intelligence (operational dimension Gallego doesn't address)

Gallego's framing is purer ethics — "can I trust agent access? can I prove what it did?" — and ignores cost. The Databricks framing is purer architecture — adds the operational (cost) and durability (open-and-interoperable) dimensions Gallego treats as out-of-scope. Both compose into the same overall posture: ungoverned-sprawl and locked-down-stagnation are both risks; the architecture must enable speed while controlling access and proving what happened.

Databricks instance (post-coding-agent generalisation)

Per the 2026-05-20 source (sources/2026-05-20-databricks-governing-ai-agents-at-scale-with-unity-catalog), Databricks' UC + AI Gateway stack instantiates governed-agent-data-access for an org-wide agent population (dev / analytics / sales-ops / support / marketing / finance). Notable load-bearing details:

  • Identity flows end-to-end. "From the user who asks the question to the specific table row the agent retrieves. Agents inherit the invoking user's data permissions in real time via on-behalf-of token passing, not a shared service account. If you can't access a table in Unity Catalog, neither can the agent acting on your behalf." — first explicit Databricks disclosure of the specific table row granularity of OBO + UC ABAC composition.
  • Dual-identity audit logging. "Every action is logged against both identities: the real user who triggered the request and the agent that acted on their behalf, capturing which tables were accessed, what operations ran, and when." — the audit-trail keys on both the human and the agent, satisfying GDPR / HIPAA / SOX per-user-action audit requirements.
  • Data classification feeds access control automatically. "An agentic AI system continuously scans and tags sensitive columns, such as PII, HIPAA and GDPR-regulated data, and those tags feed directly into access control. Masked columns remain masked regardless of which agent or framework requests them." — the data-governance layer's masking applies to agent traffic without any AI-specific configuration. Concrete instance of data-centric AI governance.

Open questions / caveats

  • Gallego's framing is product-positioning voice. The two-axis split is rhetorically clean but real enterprise governance surfaces include at least four additional axes (network isolation, data residency, key management, regulatory attestation) that the ADP announcement doesn't engage at the two-axis altitude.
  • Observability substrate depth varies. "Replayable audits" is a strong claim requiring not just the audit log but point-in-time data snapshots + policy versioning. The ADP post doesn't disclose the mechanism for "replayable" — only the property.
  • The access-control threat model isn't exhaustive. Per- caller entitlement via OBO handles the authorised-user-plus- agent case. It doesn't address the compromised-model case (prompt injection coaxing the agent into exercising legitimate entitlements maliciously), which is a separate guardrail axis.
  • No cross-vendor comparison. The two-axis framing is distinct from but related to Databricks' Unity Catalog + AI Gateway framing (governance = catalog entitlements + centralised token exchange), AWS Bedrock Agents' guardrails framing (content + topic filters + PII redaction), and Anthropic's MCP governance proposals. The wiki treats Gallego's framing as one canonical statement among several converging industry positions.

Seen in

  • sources/2026-09-25-databricks-from-data-to-dialogue-how-sp-global-energy-made-its-structured-data-estate-conversational — Governance inherited, not built — extended to external consumers. S&P Global Energy exposes its structured-data estate to AI agents by making each Genie Agent a managed MCP server governed by Unity Catalog: "A Genie Agent — or the user behind it — can only reach the agents and underlying tables they have permission to see," authentication is platform-handled, and every question runs through UC permissions on governed native/federated tables with full auditability. "We did not have to build a security layer around our AI access; we inherited the one we already had." Distinctive framing: because MCP is an open standard, the same governed endpoints serve external customers' own MCP agents — "making data available to AI did not mean making it available outside our controls." A rare external-consumer instance of governed agent data access (vs the internal-agent framing elsewhere on this page).

  • sources/2026-09-22-databricks-genie-one-mcp-give-any-ai-agent-the-right-business-context — the four-failure-mode argument that direct data access is not governed access. Databricks' Genie One MCP frames wiring an agent directly to sources as introducing four gaps — accuracy (unknown approved sources/joins), cost & latency (repeated schema/doc inspection), governance (per-user access hard to enforce across direct connections), and consistency (definitions drift per client/session) — and routes every agent through one governed layer instead. The access-control realization: agents query through Genie One, so identity must flow through via OBO — the end user's OAuth token drives Unity Catalog privilege + row-filter + column-mask evaluation in that user's context, and "two users can ask the same question in the same client and receive appropriately scoped answers without per-user prompt logic." M2M service-principal auth is the explicit anti-shape called out (flattens every caller to one identity, removing per-user enforcement). External MCP connections are Unity Catalog securables governed through standard grants.

  • sources/2026-09-15-databricks-data-ontology-defined-the-context-layer-your-ai-agents-are-missing — the context layer must not become a back door around permissions. Genie Ontology (the data ontology under Genie One / Genie Agents) enforces access during retrieval, using the underlying sources' governance including Unity Catalog: "If a user can't access the source information, the agent shouldn't be able to retrieve context derived from it… two employees can ask the same question and appropriately receive different answers." Adds a second governance job beyond access: teaching the agent what to trust — certification, authoritative definitions, lineage, usage, expertise, and provenance become the authority-ranking signals that separate the official metric definition from a one-off calculation.

  • sources/2026-08-03-redpanda-out-of-band-policy-engine-governance-ai-agents-cant-ignore — both axes rendered as shipped products (2026-08-03). Axis 1 (access) becomes the OBPE: field-level mask/drop/clamp enforced server-side at the MCP boundary, policy attached to the resource, shipping ABAC. Axis 2 (observability) becomes the Agent Network View (live estate graph) plus the transcript-as-log that feeds a grader → verdict stream → kill switch. Names the exact anti-pattern this concept warns against — the confused-deputy leak ("one Jira board, but the credential opens all fifty") — and the answer: "if the agent can see the policy, you don't have governance."
  • sources/2026-08-03-redpanda-agentic-kill-switch-is-a-database-problem-so-we-built-redpanda-sql — the enforcement endpoint of the observability axis. Gallego's 2026-08-03 post resolves "when things go wrong, can I understand what happened?" into an action: the agentic kill switch that dispatches a circuit breaker on a misbehaving agent in real time, enforced out of band ("channels they can't see or touch"). Reframes the detection side as a join-heavy workload — the database problem that motivated Redpanda SQL.
  • sources/2026-08-10-databricks-how-to-ground-genie-agents-in-both-structured-data-and-documents-without-losing-governance — The concrete Databricks realization of the access-control axis for a query agent. Genie Agents run with the end user's credentials so Unity Catalog — not the LLM — is the security perimeter; the post names the exact anti-pattern this concept warns against: granting an agent broad access and filtering via prompt engineering "makes the LLM your security perimeter, a dangerous bet." Governs both structured data (object privileges + ABAC + row filters + column masks) and documents (UC Volumes + READ VOLUME), with validation by impersonation — the observability-axis counterpart (prove what the agent would return per group).
  • sources/2026-02-10-redpanda-how-to-safely-deploy-agentic-ai-in-the-enterprise — Akidau talk-recap extends the governance framing with enforcement at interconnection points as the load-bearing architectural claim ("Enforcement at each data source is virtually impossible... To effectively govern a fleet of agents, focus on the interconnection points"). Positions governance as one of eight enterprise- agent infrastructure challenges and reinforces the rhetorical D&D chaotic-good default framing: governance is the mechanism that moves agents leftward from chaotic toward lawful.
  • sources/2025-10-28-redpanda-introducing-the-agentic-data-plane — canonical framing for this concept; 2025-10-28 Redpanda ADP launch.
  • sources/2025-10-28-redpanda-governed-autonomy-the-path-to-enterprise-agentic-ai — companion 2025-10-28 post extending the two-axis framing with named patterns: Agentic Access Control (AAC) as the Axis-1 access-control mechanism (no-long-lived- credentials + per-call-policy-before-and-after-I/O + fine-grained-temporary-access); durable event log as agent audit envelope as the Axis-2 observability substrate (six captured event classes — prompt
  • input + context-retrieval + tool-call + output + action — as first-class durable events).

Merged aliases

  • agentic-data-access
  • agentic-workflow-governance- agent-governance-via-identity
  • data-products-as-ai-context
Last updated · 766 distilled / 2,225 read