A listener with tls_disable = 1 on 0.0.0.0 sends every token and secret over plain HTTP, a "break-glass" policy with path "*" and sudo is the root policy under another name, and a saved vault-init.txt hands anyone with the repository your unseal keys and root token. This skill finds those and the other Vault mistakes below before you deploy, and tells you how to fix each one.

Your agent runs a scanner on Vault server, Agent and Proxy configs (HCL and JSON, also inside vault-helm values, ConfigMaps and VAULT_LOCAL_CONFIG), ACL policies (HCL, JSON, Terraform vault_policy heredocs, vault_policy_document rules, vault policy write heredocs in scripts and CI), and the files that run or reach Vault: docker-compose, Kubernetes manifests and injector annotations, vault-helm values, systemd units, Dockerfiles, Nomad jobs, .env files, shell scripts, GitHub Actions with vault-action and saved vault operator init output. It reads HCL with a line number for every key (also blocks written on one line), knows Vault's defaults (a listener without an address binds 127.0.0.1), policy path matching with + and *, the legacy policy = "write" syntax and env:// and file:// references, and never contacts Vault or runs anything. It returns BLOCK, REVIEW, or NOT FLAGGED, with the file, line, reason, and a safer approach. Secrets are never printed.

What it checks

BLOCK (fix before shipping)

• V01: a tcp listener with tls_disable on while it listens beyond loopback (0.0.0.0, [::], a host name, a private IP), in a deployment config (in a local compose file, docker run script or dev/test path it is V19 instead)
• V02: a dev server (vault server -dev, the hashicorp/vault image with no command, server.dev.enabled) in a systemd unit, Kubernetes workload, Helm values, Nomad job or a production-named compose file or Dockerfile; production words in the path win over local ones
• V03: a policy path that matches every path (* or +/*) with sudo or a write capability
• V04: Vault tokens (hvs., hvb., hvr. and the older s., b., r.), unseal and recovery keys, saved init output, literal VAULT_TOKEN values, passwords typed after vault login, and seal or storage credentials written in a config (placeholders and the dev root token are not reported; .env.example files only for real token formats)

REVIEW (check before release)

• V11: disable_mlock = true with a storage backend other than integrated storage (check that swap is off or encrypted)
• V12: plain http:// to Vault on another host, or certificate checks turned off (tls_skip_verify, VAULT_SKIP_VERIFY, skip_tls_verify, tlsSkipVerify, the tls-skip-verify annotation)
• V13: write or sudo on a wildcard that covers a whole mount (secret/*, kv/data/*, auth/*), or read on every path
• V14: grants that raise privileges: most of sys/, writing any ACL policy (also scoped ones like app-*), sys/raw, audit devices, auth mounts, generate-root, rekey, seal, the plugin catalog, sudo on auth/token/create, writing identity entities and groups
• V15: tls_min_version or tls_max_version set to tls10 or tls11
• V16: raw_storage_endpoint, enable_unauthenticated_access, or unauthenticated metrics or pprof on a non-loopback listener
• V17: settings Vault rejects or ignores: unknown capabilities such as write, unknown path keys, arguments set twice (Vault 2.1), a * before the end of a path, integrated storage without disable_mlock (Vault 1.20), a TLS listener without a certificate
• V18: the old Docker official vault image (last release 1.13.3) or hashicorp/vault with no tag or latest
• V19: dev-only settings in a local setup: TLS off on all interfaces in a compose file or dev/test path, or the dev root token used while VAULT_ADDR points at another machine

What's included

• The scanner (Python 3.9+, standard library only)
• A rules guide with the reason, safer approach and official HashiCorp documentation link for each rule
• A risky and a safe example project (server and raft configs, policies, an Agent config, a systemd unit, an env file, a compose file and saved init output), and the real report the scanner produces on the risky one

Limits

It reads files as written. Audit devices, auth methods and the policies a token really receives live in Vault's storage and are not visible. Each policy path is judged on its own, templated paths are treated as fixed text, and Sentinel policies are not read. The vault-helm chart's default config runs without TLS on all interfaces, so V01 fires on it on purpose (the Docker Hub compose example gets V19); a service mesh that encrypts traffic is not visible. Whether a file is a deployment or a local setup is decided from the file type and the words in its path inside the repository. NOT FLAGGED is not a guarantee.

Contents

One ZIP file with 27 files: SKILL.md, the scanner in scripts/ (7 Python files), references/rules.md (every rule with its reason and safer approach), and examples/ (17 example files plus report.md, the real scanner output on the risky example).

How to use: This is an agent skill: a folder with a SKILL.md file and Python scripts that an AI coding agent such as Claude Code, Cursor, or Codex CLI can run. Unzip it into your agent's skills folder (for Claude Code: ~/.claude/skills/), then ask your agent to check your project. The scripts also run on their own with Python 3.9 or newer, with nothing to install. They read your files only: no network access, and nothing is sent anywhere.