Data warehouse: let source creation accept an opaque credential reference

Problem

external-data-sources-create rejects secret-vault references, so any agent-driven setup flow must collect credentials as plain text and pass the real values through its model context.

The PostHog install wizard hits this on every in-cli warehouse source. Its wizard_ask tool can vault a sensitive answer and return a { secretRef } handle, but only set_env_values can resolve one — the warehouse tools reject it. So the wizard's own skill instructs the agent to collect credentials as ordinary non-sensitive text, purely to satisfy this API.

The result: database passwords, Stripe restricted keys, Sentry tokens and similar all pass through an LLM context and a tool transcript on their way to PostHog.

Evidence

Agents running the flow report it unprompted. Verbatim remarks captured in production:

• "The credential prompt accepts only a normal text response for values sent to PostHog, which necessarily exposes those values to the tool transcript rather than retaining them as vault references."
• "The Convex setup endpoint rejects invalid deploy keys clearly, but secret-bearing command construction can expose supplied credentials to tool transcripts; a secure credential-reference option for setup calls would reduce this risk."
• "Credential questions need plain-text values because PostHog source setup does not accept wizard secret references."
• "The wizard instructions require full connection credentials as plain text for CLI setup, while the runtime credential interface vaults sensitive answers only when marked sensitive."

An automated security review of PostHog/wizard#1145 raised the same issue independently.

Proposed change

Let external-data-sources-create (and external-data-sources-db-schema, which validates before creation) accept an opaque credential reference in place of a plain-text field value. The caller resolves the reference host-side and never returns the value to the agent.

This would let the wizard mark credential questions sensitive, keep the values in its local vault, and hand PostHog only a handle.

Scope

This affects every agent-driven source setup path, not just the wizard. Any MCP client creating a warehouse source has the same exposure today.

Locate the implementations and validation paths for external-data-sources-create and external-data-sources-db-schema, then read how credential fields are currently handled. Trace the warehouse source setup flow and its existing tests before deciding where opaque references must be accepted. Done means both entry points support the reference flow without exposing credential values to the agent.