Sensitive value redaction in Terraform JSON output: unresolved behavior

The direct answer

As of current Terraform releases, terraform show -json does not redact sensitive values, and there is no built-in flag to make it do so. The sensitive = true marking only suppresses values in the human-readable text output. In the JSON plan, each attribute carries a sensitive boolean in its metadata, but the corresponding value field remains plaintext. This is a deliberate design decision: the JSON output is a machine-readable contract, and silently altering values would break the many tools that parse it. Whether HashiCorp should add an opt-in redaction flag is an open community question, but you should not wait for it — the practical answer today is a post-processing step you control.

Likely explanation vs. confirmed behavior

Confirmed: the JSON schema exposes sensitivity as metadata (sensitive_values trees and per-attribute flags) rather than by masking values. Likely rationale (not officially stated as a single decision): redaction is lossy and irreversible, so Terraform leaves the policy choice to the consumer. Treat any claim about an upcoming native --redact flag as unverified until you check the changelog for your version.

The pragmatic fix: redact with jq

Because the JSON already tells you which nodes are sensitive, you can walk the tree and replace only those values with a placeholder, preserving structure for downstream parsers:

terraform show -json planfile \
  | jq 'walk(if type=="object" and .sensitive==true then .value="<REDACTED>" else . end)' \
  > plan.redacted.json

For plans, also check the top-level sensitive_values tree, which mirrors the shape of planned_values with booleans marking sensitive leaves — a more thorough redactor uses it as a mask against the corresponding value tree rather than relying solely on inline flags.

Selective redaction without breaking workflows

• Two artifacts: keep the full JSON in a restricted store (encrypted artifact bucket, short retention) and publish the redacted copy to CI logs and shared tooling. Automation that needs real values reads the restricted copy; everything else reads the redacted one.
• Stable placeholder: use a fixed string like <REDACTED> so downstream schema validation still sees a string where it expects one; placeholders of the wrong type are the most common cause of consumer breakage.
• Preserve metadata: never delete the sensitive flags — tools use them for their own policy decisions.

Verification

1. Create a test plan with a known dummy secret (e.g., a variable marked sensitive). Run terraform show -json and confirm the plaintext value appears alongside sensitive: true.
2. Apply the jq filter and grep for the secret: it should be absent, with the placeholder in its place and the rest of the plan byte-identical in structure.
3. Run your actual downstream consumer against the redacted file in a staging pipeline before rolling out.

Caveats

Values not marked sensitive — including computed attributes a provider failed to flag — remain exposed, so audit provider schemas for your resources. Also note the state file itself stores secrets in plaintext regardless; redacting plan output does not change that. Exact JSON schema details vary by Terraform version, so validate the redactor against the version you run.