A sensitive value is a Terraform marking that redacts display in plans, outputs, and logs. It does not encrypt the underlying data, prevent state storage, or change who can retrieve the value from backend copies, so it is useful hygiene but not a storage control.
Expanded Definition
In Terraform, a sensitive value is a display control, not a data protection control. It suppresses accidental exposure in plans, state diff output, and logs, but the underlying value still exists wherever Terraform stores or transmits it, including state files and backend copies. That distinction matters in NHI operations because secrets, tokens, API keys, and certificates often travel through infrastructure code paths that people assume are automatically protected.
Practically, the term is about reducing human exposure during authoring and review, while leaving storage, retrieval, and authorization unchanged. That is why it should be read alongside broader controls in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where secrets handling, access enforcement, and audit logging intersect. Definitions vary across vendors and tooling ecosystems, but the common operational meaning is consistent: the label changes presentation, not privilege.
The most common misapplication is treating a sensitive value marker as equivalent to encryption or secret vaulting, which occurs when teams assume hidden output means the secret is no longer retrievable from state.
Examples and Use Cases
Implementing sensitive values rigorously often introduces a tradeoff between safer review workflows and more disciplined secret management, because teams must still secure the real value outside Terraform.
- A service account token is marked sensitive so it does not appear in a plan review, while the token itself is stored in a proper secrets manager rather than in configuration.
- An API key used by a CI/CD pipeline is hidden in console output, but access to backend state remains restricted and audited to prevent credential harvesting.
- A certificate private key is redacted from logs during provisioning, while the key lifecycle is governed separately through rotation and revocation procedures described in the Ultimate Guide to NHIs.
- A platform team labels outputs as sensitive to prevent accidental disclosure in downstream automation, but still documents who can retrieve the underlying data and from where.
- Security reviewers compare the Terraform behavior against NIST SP 800-53 Rev 5 Security and Privacy Controls to confirm that redaction is paired with access control and storage policy.
NHIMG notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which is exactly the environment where sensitive value flags are most often mistaken for real protection. For deeper NHI context, the Ultimate Guide to NHIs is the most relevant reference point.
Why It Matters in NHI Security
Sensitive values matter because NHI incidents often begin with exposure rather than exploitation. Redacting a token from a Terraform plan reduces casual leakage, but it does nothing if the same token is present in state, backend snapshots, deployment artifacts, or debug telemetry. That gap is critical in environments where NHIs outnumber human identities by 25x to 50x, and where one overlooked credential can multiply into broad service-to-service access.
When teams misunderstand the term, they underinvest in vaulting, state hardening, and access review. That can leave service accounts, API keys, and certificates effectively immortal after deployment, even when the infrastructure code looks clean. The broader NHI security lesson from the Ultimate Guide to NHIs is that visibility and rotation matter as much as redaction, because hidden secrets are still secrets if they can be recovered later.
Organisations typically encounter the operational cost of sensitive value misuse only after a state file, log stream, or backend copy is exposed, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST IR 8596 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Sensitive markers can hide secrets, but NHI-02 covers proper secret storage and handling. |
| NIST CSF 2.0 | PR.DS-1 | This term affects protection of data at rest and does not itself provide encryption. |
| NIST SP 800-63 | Credential strength and lifecycle rules apply to the underlying secret, not the Terraform label. | |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust requires enforcing access decisions where secrets are retrieved, not where they are displayed. |
| NIST IR 8596 | AI systems also rely on hidden credentials, making redaction insufficient without governance. |
Verify the underlying credential meets identity assurance requirements regardless of Terraform sensitivity flags.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
