Ask DataHub Requires Human Approval. One Setting Decides Whether It Still Does.

DataHub answered one authority question cleanly in this release. A different, more consequential one, it left open, and its own documentation is precise enough to show exactly where the second question starts.

What actually shipped, precisely

DataHub Cloud v2.1 was announced on 3 August 2026. DataHub's own release notes, which we read directly, date the underlying build's availability to 30 July 2026 and describe the same change the announcement leads with: Ask DataHub is generally available, the Beta label is gone, and the chat agent now pauses for human in the loop approval before applying any metadata edit on the web, so a human can confirm important changes before they are made. That is a specific, checkable claim. It does not say every AI initiated write everywhere in DataHub pauses. It says the chat agent, on the web, pauses before applying a metadata edit.

Two follow on releases refined the mechanism rather than changing it. In v2.1.2, on 12 August 2026, the tool approval card itself was reworked: plain language titles with entity links, collapsed details by default, and clearer handling of stale pending approvals. In v2.1.3, on 19 August 2026, a boot time circular import bug that could silently leave system agents with an empty tool palette was fixed. The most recent point release, v2.1.4, shipped 25 August 2026, a day before this record, and rolled up hotfixes without touching the approval mechanism.

The setting that turns the pause off

DataHub's release notes document the control directly, in its own environment variables section, in language precise enough to quote whole. DATAHUB_AI_TOOL_APPROVAL_ENABLED, default true, gates the AI chat's human in the loop approval of mutating tools on the web UI. Set false to auto apply edits as before. Re read per chat turn.

That last property is what makes this a policy question rather than a one time configuration choice. A setting read once at startup is closer to an architectural decision. A setting re read every turn is a live control somebody can flip mid week, and the interesting authority question follows immediately: who.

Two authority questions, not one

DataHub's release notes fully answer the first question this record set out to check. When Ask DataHub proposes a metadata edit on the web, with the default configuration, a human sees an approval card before the write happens. That is action level authority: does this specific write get a yes.

The second question is different in kind, and it is the one DataHub's documentation does not answer. Who is authorized to decide that future writes, plural, stop needing a yes at all. That is authority policy administration, and it sits one level above any single approval. A person who can flip DATAHUB_AI_TOOL_APPROVAL_ENABLED to false is not approving one edit. They are deciding that nobody has to approve any edit, for as long as the setting stays false, for every user of that deployment's Ask DataHub.

Moona Intelligence has used this same distinction before, describing GitHub's approve workflow run safe output as a case where an agent could execute the approval action itself, once a policy allowed it. DataHub's case is quieter and, in a sense, more consequential. Nobody is proposing that Ask DataHub approve its own writes. The open question is who is allowed to decide that approval, as a category, no longer applies going forward.

Who approves one write is itself not fully specified

Even at the action level, DataHub's documentation leaves a gap this record will not paper over. The tool approval card appears to the person using Ask DataHub in that chat session. Nothing in the release notes or in DataHub's Ask DataHub feature documentation, which we read directly and which focuses on Ask DataHub's conversational capabilities rather than its approval mechanics, states that the approver must be the owner of the metadata being edited, or must hold a permission distinct from simply being present in the chat. The most defensible reading of what is documented is that the interactive user is the approver, not a separately designated reviewer and not necessarily the resource's owner. Applying the edit itself still runs through DataHub's underlying entity level authorization, the same Edit Entity style privileges that govern any write to that asset, so a user without edit rights to a dataset could plausibly see a proposed edit fail on ordinary permission grounds regardless of the approval card. Whether DataHub documents that interaction explicitly is not established by what we read, and this record preserves it as unconfirmed rather than assumed.

Who controls the switch is a genuine gap

This is the material finding. DataHub's authorization documentation, which we read directly, describes a Manage Platform Settings privilege, Admin only, for viewing and changing platform level settings such as integrations and notifications. It also describes a separate, considerably older Change Proposals system, in which specific privileges like Manage Tag Proposals and Manage Owner Proposals, granted by default to the Editor and Admin roles, govern who can approve or deny a crowdsourced suggestion to add a tag, term or owner to an asset. Neither of those documented permissions is described anywhere we found as covering DATAHUB_AI_TOOL_APPROVAL_ENABLED. The setting lives in the release notes' Environment Variables section, the same section that documents infrastructure level toggles like EXTERNAL_OAUTH_MAP_TO_CORPUSER or ENTITY_GRAPH_CACHE_ENABLED, not in the Settings and Permissions surface DataHub documents for its Roles and Policies.

That placement matters. An environment variable is set where a deployment's configuration lives, which for a self managed DataHub instance means whoever operates that infrastructure, a deployment operator distinct from any in product Admin role. For DataHub Cloud, the managed version of the product that Ask DataHub, Scoped MCP servers and the AI Tool Audit Dashboard are all documented as belonging to, the material available to us does not say whether a customer's own administrator can set this variable directly through some self service path, or whether changing it requires a request to DataHub's own operations team. Both are plausible. Neither is documented in what we could read. Rather than guess, this record states the gap: DataHub has built a specific, named, well described control over whether one write requires a human's approval, and the authority to retire that requirement for every future write is not shown, anywhere in DataHub's own published material, to be governed by DataHub's own permission model at all.

Three things this is not

Getting DataHub's authority picture right means keeping several genuinely different mechanisms apart, and DataHub's own documentation draws these lines even when marketing language blurs them.

Scoped MCP servers, also shipped in v2.1, let a team create purpose built MCP servers from the UI, each exposing a curated set of tools with configurable instructions and optional scoping to specific data assets through Views. That is an access surface constraint, deciding which tools and which data an agent can reach at all, and DataHub's own comparison material describes it exactly that way, alongside rather than inside the approval feature. It answers a different question than the tool approval card does. A scoped server can hand an agent zero mutating tools at all, which is a stronger control than any approval prompt, but it is not the same control, and this record does not fold the two together.

Decisions, part of DataHub's Agents, Tasks and Decisions framework, are documented as human in the loop checkpoints where an agent pauses and requests input before continuing, with an optional predefined choice list or a free text field. That is a generic long running task checkpoint, the kind a data quality agent might use to ask which of three candidate fixes to apply, and DataHub's own material does not tie it to a specific metadata mutation or to Ask DataHub's tool approval gate. Treating Decisions as an authority gate on resource writes would be reading more into the documentation than it states.

Change Proposals, sometimes called Approval Workflows in DataHub's material, predate Ask DataHub and address an entirely separate scenario: a user suggesting a tag, term, domain or owner for an asset, routed to that asset's owners or stewards for a yes or no, governed by named permissions granted through DataHub's Editor and Admin roles. It is a real, older, well permissioned authority system. It is also not the mechanism this record is about, and nothing in DataHub's documentation connects it to DATAHUB_AI_TOOL_APPROVAL_ENABLED.

The standalone DataHub MCP server, used by external AI clients through a scoped or hosted MCP endpoint, is a fourth adjacent mechanism worth naming precisely because it is not the same gate either. Its mutation tools are enabled by a different setting, and DataHub's own documentation for that server states plainly that each mutating tool is annotated with a readOnlyHint value of false so that MCP compatible clients can require confirmation before invoking them. That is client side signaling, not a server side hold. Nothing in that documentation states DATAHUB_AI_TOOL_APPROVAL_ENABLED governs those calls, and this record does not assume a write reaching DataHub through an external MCP client receives the same web UI approval card that Ask DataHub's own chat surface does.

What the Audit Dashboard actually records

DataHub's AI Tool Audit Dashboard, described as generally available for anyone with the MCP server and Ask DataHub enabled, gives a platform admin a single view across Ask DataHub, the MCP server and the Claude connector, covering who accessed which AI tool, from which surface, and when, downloadable as a usage log. That capability traces back to what DataHub's v2.0.0 release notes, published 25 June 2026, described as MCP Audit, a GraphQL mcpAudit resolver surfaced as a dedicated tab under Settings, AI, with KPI charts and a history table, and an environment variable controlling whether full tool call payloads are captured alongside the audit event.

That is genuine, usable evidence, and it is worth being precise about what kind. Who used which tool, from where, and when is access and usage evidence. Nothing in the documentation we read shows that dashboard recording, as a distinct field, which pending approvals were granted or denied, or by whom, as opposed to which tool calls eventually executed. A tool usage log and an authorization decision record are not automatically the same artifact, and this record does not call the Audit Dashboard the latter without documentation that says so.

Where the pause is actually enforced remains unknown

One question this record cannot close, and says so directly rather than rounding up. DataHub's language, a chat agent that pauses for approval, a card that can go stale while pending, is consistent with a backend that tracks a mutation as held in a pending state until a person acts on it, which would be more than a client side dialog box the server has no memory of. It is also consistent with a UI that shows a confirmation step while trusting the same web client to only send the mutation call after that confirmation, which would put the actual enforcement boundary in the browser rather than at the point the tool call reaches DataHub's servers. Nothing in the release notes, the feature documentation, or the comparison material available to us states which of those two architectures is the real one. Moona Intelligence's own reading, developed across other records, is that a control that lives in the client is a materially weaker claim than one enforced at the point of execution, and DataHub's own tool approval card, real and specific as it is, does not yet come with the documentation needed to say which side of that line it sits on. We preserve that as unknown rather than assume the stronger claim.

A policy change is prospective, not retroactive, and the pending case is undocumented

DATAHUB_AI_TOOL_APPROVAL_ENABLED is re read per chat turn, which is a meaningfully different design than a value cached at process start. It means a change to the flag takes effect from the next turn onward rather than requiring a restart, which is also what makes the policy administration question live rather than theoretical: someone can change the market's default behavior for a whole deployment inside a single working day. What DataHub's documentation does not address is the in flight case. If a mutating tool call is sitting in a pending, not yet stale approval state when an operator flips the flag to false, nothing we read says whether that specific pending request is auto applied, left pending indefinitely, or still requires the approval it was created under. This record treats that as an open question rather than inferring an answer either way.

Recovery is not something Ask DataHub itself documents

DataHub the platform has general purpose tools for reversing metadata changes, notably CLI level rollback of an ingestion run and undo of a soft delete, and these are real, documented capabilities. Nothing in Ask DataHub's own documentation, or in the v2.1 release notes, describes a specific reversal path for an edit Ask DataHub itself applied, whether that edit went through an approval or, with the setting off, was auto applied. Whatever recovery exists for an Ask DataHub write appears to be whatever DataHub's ordinary metadata versioning and manual editing tools already provide, not a feature purpose built for undoing an AI agent's mutation, and this record does not credit DataHub with a reversal capability its own material does not describe as such.

Where this sits in the pattern

DataHub's tool approval card and TrueFoundry's Human Gate, which Moona Intelligence verified separately, are both real answers to whether one action gets a human's yes, and both leave a version of the same question sitting one level up. TrueFoundry's Gateway boundary at least changes where the decision to require approval is enforced, moving it somewhere an individual agent builder cannot silently skip. DataHub's version is narrower still: the requirement to approve is itself a single deployment wide switch, and the authority to flip that switch is not shown to be governed by anything DataHub's own Roles and Policies documentation describes. A default that protects every write today is a real control. Whether it stays a control next month depends entirely on who is allowed to decide it should not.

If you operate DataHub Cloud, or any AI system that ships an approval requirement behind a flag rather than inside its permission model, the question worth asking this week is not whether your writes are protected today. It is who, specifically, in your own organization, is capable of deciding they stop being protected, and whether that person was ever meant to hold that authority at all.