HashiCorp Token Leak Response: Vault, Terraform, HCP

HashiCorp credentials are keys to other keys: a Vault token opens secrets and dynamic credentials, an HCP Terraform token can plan and apply infrastructure, and an HCP service principal key can manage the platform itself. Each product revokes differently. Vault service tokens can be revoked with their whole tree of children and leases, but batch tokens cannot be revoked at all; HCP Terraform has five kinds of API token with different owners; HCP service principals hold at most two keys. This guide is a leak response reference across Vault, HCP Terraform and Terraform Enterprise, and HCP: how to identify the credential, what it reaches, how to find its use in audit logs, the revoke and rotate steps and the controls that shrink the next leak. It assumes you already run these products; for architecture and hardening depth see the HashiCorp Vault Guide and the Terraform Cloud and HCP Security Guide.

Key takeaways

The prefix tells you the product and the revocation path. hvs. is a Vault service token, hvb. a Vault batch token, hvr. a recovery token, and HCP Terraform API tokens contain atlasv1.
Vault batch tokens cannot be revoked directly. Contain them by revoking their parent (when they are not orphans), by tightening the policy they carry, or by waiting out their fixed TTL, which is why batch TTLs must stay short.
Revoking a Vault service token also revokes its children and leases. That is the right default for a leak, but check what else depends on the tree before you use -mode=orphan to spare children.
An "owners" team token is an owner. HCP Terraform team tokens act with the team's access, so a token for the owners team carries organisation owner permissions.
Audit first, then search by hash. Vault writes HMAC-SHA256 hashes of tokens to audit logs, so you find a leaked token's activity by hashing the value with the same audit device, which only works if that device was enabled beforehand and is still enabled.

How identity and access work in HashiCorp products

Each product has its own identity model, so the first step in any leak is to work out which one you are dealing with.

Credential	How to recognise it	What it reaches	Lifetime
Vault service token	`hvs.` (legacy `s.` before Vault 1.10)	Whatever its policies allow: secrets, dynamic credentials, auth and sys paths	TTL, renewable, optionally periodic; root tokens may never expire
Vault batch token	`hvb.` (legacy `b.`)	Its policies, without child tokens or cubbyhole	Fixed TTL, not renewable, not manually revocable
Vault recovery token	`hvr.` (legacy `r.`)	Recovery mode operations	Generated for recovery
Vault root token	A service token with the `root` policy	Everything in the cluster	Should exist only while in use
HCP Terraform user token	Contains `atlasv1`	Everything the user can do in every organisation they belong to	Expiry set at creation; organisation can cap it
HCP Terraform team or group token	Contains `atlasv1`	The workspaces and permissions the team or group has	Expiry set at creation
HCP Terraform organisation token	Contains `atlasv1`	Organisation-wide CRUD on most resources, but cannot start runs or create configuration versions	One per organisation
Audit trails, metrics service and agent tokens	Product-specific	Reading audit trails, reading metrics, or agent pool communication only	Managed by organisation owners
HCP service principal key	Client ID and client secret pair	The HCP public API, at organisation or project level, with the service principal's role	Until deleted; at most two keys per service principal

Sibling material leaks too. Vault unseal keys and recovery keys, Terraform state files (which can contain provider credentials and outputs in plain text) and release signing keys are all HashiCorp-adjacent secrets that need their own runbooks. The Terraform and IaC Pipeline Credential Security Guide covers state and provider credentials.

Admin roles and privileged access

Vault root tokens: there are only three ways to create one: the initial token from vault operator init, another root token, or vault operator generate-root with a quorum of unseal or recovery key holders. HashiCorp recommends using root tokens only for initial setup or emergencies and revoking them immediately afterwards.
Vault sudo and token-store paths: write access to auth/token/create-orphan, or sudo on auth/token/create with no_parent, lets a holder mint orphan tokens that survive the revocation of their creator. Treat these capabilities as privileged and alert on their use.
Accessor listing: auth/token/accessors lists every token accessor, and accessors can revoke tokens, so this endpoint is both a response tool and a dangerous capability.
HCP Terraform owners: only owners can generate or revoke the organisation token, the audit trails token and metrics service tokens, and owners set the maximum token time to live.
HCP IAM: service principals at organisation level reach every project; prefer project-level service principals with the narrowest role.

Integrations, API tokens and service accounts

Most HashiCorp leaks come from automation: a Vault token pasted into a CI variable, a VAULT_TOKEN exported in a shell profile, a Terraform user token in a .terraformrc or credentials.tfrc.json, or an HCP client secret in a pipeline. Better patterns exist for each:

Instead of	Use	Why it limits a leak
Long-lived Vault service token in CI	A platform auth method (JWT/OIDC, Kubernetes, AppRole with response wrapping) issuing short-TTL tokens	A leaked token expires quickly and is tied to a role you can revoke by path
Static cloud keys stored in Vault KV	Dynamic secrets engines with leases	Revoking the token revokes the leases and the generated credentials
Terraform user token for automation	Team tokens with expiry, and disabling user tokens at organisation level where possible	No person's full access in a pipeline
Owners team token	A team scoped to the workspaces the automation needs	Owner permissions stay with people
HCP service principal client secret	HCP workload identity federation (AWS, Azure, GCP, GitHub, GitLab or generic OIDC)	No static secret to leak

Disabling user tokens for an organisation blocks them from organisation resources, but HashiCorp warns that it breaks automations using them and prevents the GitHub App VCS connection, which relies on user tokens. Test in a non-production organisation first.

Logging and detection

Secret scanning coverage

GitHub secret type	Public repos (partner)	Push protection	Validity check
`terraform_api_token`	Yes	Yes	Yes
`hashicorp_vault_service_token`	No (private with Secret Protection)	Yes	No
`hashicorp_vault_batch_token`	No (private with Secret Protection)	Yes	No
`hashicorp_vault_root_service_token`	No (private with Secret Protection)	Yes	No

Gitleaks' default rules (checked 28 October 2026) include vault-service-token, vault-batch-token, hashicorp-tf-api-token and hashicorp-tf-password. Legacy s. tokens are short and generic, so scanners match them poorly; if you still issue them, upgrade. Vault tokens are self-hosted secrets, so nobody else can revoke them for you: a public commit of an hvs. token is entirely your problem. See the Git Secret Scanning Guide.

Vault audit devices

A new Vault cluster has auditing disabled. Once enabled, Vault sends every request and response to every audit device and refuses requests if it cannot write to at least one, so HashiCorp recommends at least two devices. By default string values, including tokens, are written as HMAC-SHA256 hashes. To trace a leaked token, compute its hash with the audit device's key (through the audit hash API) and search for that value; if the device was disabled and re-enabled, the old hashes can no longer be computed. Setting hmac_accessor=false writes accessors in clear, which makes it much faster to correlate activity and revoke by accessor. Forward audit logs to the SIEM; see the Secrets Access Logging and Detection guide.

Signals worth alerting on

Any request authenticated by a root token, and any sys/generate-root activity.
Calls to auth/token/create-orphan, auth/token/accessors and token role creation.
A token reading many secret paths it has not read before, or listing mounts.
Policy changes under sys/policy or sys/policies, and new auth methods or audit device changes under sys/auth and sys/audit.
In HCP Terraform audit trails: new tokens, team membership changes, runs started from unusual sources and variable changes in sensitive workspaces.
In HCP: new service principals or keys, and role bindings changed.

Metrics that show it is working

Live root tokens: zero outside a documented, time-boxed procedure.
Token TTL profile: share of Vault tokens issued with a TTL above one day.
Terraform tokens without short expiry: count against the organisation maximum time to live.
Static HCP client secrets: service principals still using keys instead of federation.
Time to revoke after a scanner alert, per credential type.

Leak response

Classify the credential by prefix and context (environment variable, file, pipeline). Look the token up by accessor where you have it rather than by using the leaked value.
Vault service token: run vault token revoke with the token or with -accessor. The default revokes all children and their leases, which revokes dynamic credentials they issued. Use -mode=orphan only if you have confirmed children are legitimate and needed. If the token came from an auth method role, -mode=path revokes every token created under that auth path.
Vault batch token: it cannot be revoked. Revoke its parent if it has one, remove or narrow the policy it carries, disable the role or auth path that issued it, and rotate the secrets it could read until its TTL ends.
Vault root token: revoke it, then review every action in the audit log during the exposure window, including new policies, auth methods, tokens and audit device changes. Generate a new root only when needed, with a quorum, and revoke it after use.
Rotate what the token could read: static secrets in KV paths covered by its policies, and any cloud or database root credentials configured in secrets engines it could reach.
HCP Terraform token: delete it in the user's token settings, or under Organization Settings, API Tokens for team, group, organisation, audit trails and metrics tokens. If it is a user token and the user is compromised, remove them from the organisation and reset their identity provider access. Then review runs, state downloads, variable changes and team membership in the audit trail, and rotate provider credentials stored as workspace variables.
HCP service principal key: generate the second key, deploy it, then delete the leaked one (the two-key limit is your rotation slot). Review what the service principal changed.
Remove the source (history rewrite, image rebuild, CI variable change), confirm the old value fails, and record it using the Leaked Credential Response Playbook.

HashiCorp has been on the receiving end of this problem. In the Codecov incident, an altered uploader script exfiltrated CI environment variables from customers, and HashiCorp's release GPG signing key was among the exposed secrets. HashiCorp revoked the key, published a new one, re-signed existing releases and shipped Terraform patch versions that trust the new key. See the HashiCorp GPG key exposure analysis and the Codecov breach analysis.

Hardening baseline

Enable two Vault audit devices before anything else, and forward them to the SIEM. Without them there is no investigation.
Remove standing root tokens: revoke the initial root token after setup and document the generate-root quorum procedure.
Shorten TTLs: set default and maximum TTLs on auth method roles, prefer batch tokens only for high-volume, short-lived workloads, and use periodic tokens only where a service cannot re-authenticate.
Move CI and workloads to identity-based auth in Vault and to workload identity federation in HCP.
Cap HCP Terraform token lifetimes with the organisation maximum time to live, replace user tokens in automation with team tokens, and never create a token for the owners team for automation.
Pilot and roll back: change one auth role or workspace at a time, keep the old credential until the new one is proven, and for Vault use path-based revocation only after confirming which tokens share the path.

Small teams on HCP Vault Dedicated and HCP Terraform should focus on audit, short TTLs and team tokens with expiry. Large self-managed estates need the full set, plus regular reviews of who holds sudo on token paths and drills of the root regeneration procedure.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A	MITRE ATT&CK
Token lifetimes, inventory and root control	IA-5, AC-2	PR.AA-01	A.5.17 Authentication information	T1078 Valid Accounts
No tokens in code, CI or images	IA-5(7)	PR.DS-01	A.8.4 Access to source code	T1552.001 Credentials In Files
Policies, sudo paths and owner tokens	AC-6	PR.AA-05	A.8.2 Privileged access rights	T1555.006 Cloud Secrets Management Stores
Audit devices and audit trails	AU-2, AU-12, AU-6	PR.PS-04, DE.CM-09	A.8.15 Logging	T1098.001 Additional Cloud Credentials
Revocation and secret rotation	IR-4	RS.MI-01	A.5.26 Response to information security incidents	T1195.002 Compromise Software Supply Chain

Common misconfigurations

The initial root token kept "just in case": stored in a wiki or password manager, never revoked.
Long-TTL batch tokens: chosen for performance, then leaked with no way to revoke them.
Auditing switched on late, or off and on again: the hashes you need for the investigation cannot be computed.
Orphan tokens everywhere: revoking the creator leaves a forest of tokens behind.
Owners team token in CI: organisation owner rights in every pipeline log.
Workspace variables never rotated: a Terraform token is revoked but the cloud keys it could read stay valid.

Practitioner checklist

Map each prefix (hvs., hvb., hvr., atlasv1) and HCP client secrets to a revoke procedure and an owner.
Enable at least two Vault audit devices and keep them enabled.
Revoke standing root tokens and alert on root token use.
Keep batch token TTLs short and know which roles issue them.
Alert on orphan token creation and accessor listing.
Set the HCP Terraform maximum token time to live and use team tokens for automation.
Replace HCP service principal secrets with workload identity federation where supported.
After any leak, rotate the secrets and provider credentials the token could read.
Scan for HashiCorp token patterns in private repositories, images and CI logs.

HashiCorp credentials: Revoke Vault, Terraform and HCP Tokens Safely