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.

AuditBadger claims the other architecture

AuditBadger is a SOC 2 and ISO 27001 compliance platform. On 1 September 2026 it released what it calls auditable agentic compliance, opening its full compliance workflow to external AI agents, naming Claude, ChatGPT and Codex specifically, working through a dedicated agent facing surface rather than a general purpose API. The company's own framing is direct: agents may read the customer's live compliance state and may propose changes, and every change an agent proposes becomes a reviewable change set that a human must explicitly approve before a separate step applies it. AuditBadger's own account states this is not a configuration choice sitting on top of a more permissive default. It describes the approval gate as architectural, states plainly that no setting restores a direct write path for the agent surface, and claims its own test suite fails the build if a direct write path is introduced. That is the mirror image of DataHub's design. DataHub ships a real pause, on by default, that a documented environment variable can switch off. AuditBadger's claim is that there is no switch in the agent surface to find, because the surface it exposes to an agent was never given a path that writes directly in the first place.

What AuditBadger documents, and what we could only corroborate

Automated fetch of auditbadger.com, including its dedicated auditable agentic compliance page, was blocked in Moona's tooling environment, and this record found no public source repository, API schema or test suite to inspect directly, unlike the DataHub material above, which was read from primary release notes and code hosted on GitHub. What follows is corroborated through multiple independently phrased search retrievals that converged on consistent wording, including a syndicated copy of AuditBadger's own release distributed through openPR, and is held to the same manual review evidence standard this record already applies to sources it could not fetch directly. AuditBadger's own figures, as corroborated, describe an agent surface of 118 tools across ten modules, with zero tools described as performing a direct write, and a split of 58 read operations and 49 propose operations. Those two counts sum to 107, not 118, and nothing in what this record could verify accounts for the remaining eleven tools; this record states that gap plainly rather than rounding the marketing figure up to a total that matches it. The audit trail is described as naming the agent token or agent actor, the change set, and the approving person as separate fields, which, if accurate, is a materially more specific attribution model than DataHub's Audit Dashboard, itself a usage log rather than a documented approval decision ledger as this record established above. AuditBadger also describes two independent pause controls, one that stops new agent activity from being accepted and a separate one that stops approved change sets from being applied, and states that proposals expire and that judgment calls are not bulk approved. This record found no specific expiry window, no documented behavior for a change set already pending when a pause is activated, and no confirmation of whether resuming from a pause replays queued approved work automatically or requires a fresh action; each of those is preserved here as unknown rather than assumed in either direction.

No direct write path in the agent surface is not the same claim as no write API

AuditBadger's own material, as corroborated, is specifically about the surface an external agent reaches: an agent token, a distinct credential type, calling a defined set of tools. Nothing in what this record could verify claims that AuditBadger the product has no way to write data at all, and this record does not imply that it does. A compliance platform plainly needs ordinary write paths for its own web application and its human administrators; the claim worth taking seriously is narrower and more specific than that, that the specific credential and tool surface an agent authenticates through does not include a tool that persists a mutation without first becoming a change set awaiting approval. Whether a human administrator's own API token, distinct from an agent token, could be used to write directly, and whether an agent process could obtain or misuse a human token issued outside the agent interface, is not addressed in what this record could verify and is preserved as unknown. AuditBadger's claim that a legacy MCP endpoint was replaced by a new agent endpoint requiring its own token type appears in corroborated coverage of the release; this record could not confirm the migration mechanics or the old endpoint's prior behavior directly and treats that detail the same way, as reported rather than independently read.

The claim this record cannot promote past vendor claimed

AuditBadger's strongest claim, that the approval gate is architectural rather than configurable and that its own tests fail if a direct write path is introduced, is exactly the kind of claim this record has treated carefully elsewhere for other vendors: a statement about a system's own internals that only holds up under independent inspection of the system itself. Without a public repository, published API schema or independently reviewable test suite, this record cannot verify that claim and does not report it as demonstrated. The defensible, narrower version of what AuditBadger has shown is this: in what Moona Intelligence could read and corroborate, no supported configuration is documented that turns AuditBadger's agent endpoint into a direct write endpoint. That is meaningfully different from saying the gate cannot be bypassed by any means, a claim this record does not make, because complete mediation is not something a vendor's own marketing language or a blocked website can establish on its own. This record also cannot verify, from what is available, whether a change set is bound to an exact, immutable payload once approved, whether an approved change set can be applied more than once, whether the same person who is the agent's associated user can also be its approver, whether multiple approvers are supported, or whether an approval can be revoked after it is granted but before the apply step runs. Each of those is a real question this record raises rather than answers, in the same spirit as the open questions this record already preserves about DataHub's own approval mechanics above.

Audit attribution is not proof of entitlement, on either side of this comparison

AuditBadger's audit trail, as corroborated, names the agent and the approving human as separate, attributable actors, which is a real design decision and a more specific one than DataHub's usage log. It is worth being precise about what that attribution does and does not establish, the same distinction this record already draws for DataHub above and that Moona Intelligence has drawn for other approval systems, including the blocking, not merely observing, human in the loop step Zendesk shipped in its sequential approval flow. Naming the approver in an audit record proves who clicked approve. It does not, on its own, prove that person held the organizational entitlement to approve that specific change, that the change's business rationale was ever reviewed, or that the approval could not have been granted by someone with account access but no real authority over the compliance program in question. AuditBadger's own material does not claim otherwise, and this record does not read a named approver as a settled question of legitimate authority, only as evidence of who took the recorded action.

Two architectures answering the same authority question

Set next to each other, DataHub and AuditBadger demonstrate two different answers to the same underlying question this record exists to ask: who is authorized to remove the requirement for human authorization. DataHub's architecture makes approval the default and leaves the authority to disable it undocumented, a real, specific, checkable gap in DataHub's own published permission model. AuditBadger's architecture, as the company describes it, tries to remove that gap by removing the lever itself, so that disabling approval in the agent surface is not a permission question because it is not a configuration option at all. If AuditBadger's claim holds up under the kind of direct, primary source verification this record was able to give DataHub, that is a genuinely stronger position on the exact question this record has been asking since it first read DataHub's release notes. What this record will not do is treat a vendor's own description of its own architecture as equivalent to the independent verification DataHub's public release notes and public authorization documentation allowed. The DataHub finding stands as read: a documented, checkable gap in who may switch off an approval requirement. The AuditBadger finding stands as read too: a vendor's claim that no such switch exists in its agent surface, offered without the primary material needed to confirm it directly.