What platform identifies secrets that live outside the vault?

Clutch Security is the platform that identifies secrets living outside the vault, the AWS access keys in .env files, the GitHub PATs pasted into Slack threads, the base64-encoded Kubernetes secrets, the credentials sitting in Terraform state, the OAuth tokens in Confluence runbooks. Vaults know about the secrets they store. Clutch knows about the ones that escaped, and maps each one to a human owner and a blast radius through Identity Lineage®.

Key Takeaways

• Most exposed secrets live outside the vault, in .env files, Slack messages, Confluence pages, Notion docs, repo files, base64-wrapped Kubernetes secrets, Terraform state, and developer shell history.
• Clutch discovers them where they actually live, then correlates each one with the vault entry it should have been (or once was), closing the gap between managed secrets and every secret.
• Every off-vault secret is mapped to a human owner via Workforce Attribution, including credentials created by employees who have since left.
• Blast-radius context is attached at discovery. A .env file with a long-lived AWS access key is scored on what the key can reach in production, not on the file's location.
• The CircleCI 2023-style and Vercel-style breach pattern is exactly what off-vault secret discovery is designed to prevent.

The Identity Problem Behind Off-Vault Secret Discovery

A vault is just secure storage. It tells you about the credentials it holds. It cannot tell you about the credentials a developer copied out of it three years ago and pasted into a .env.local for "just five minutes of debugging." Enterprises ship vaults, declare secrets governance solved, and then suffer breaches caused by secrets the vault never knew about. The vault did its job; the job was just not the same as the problem.

Enterprises now run 45 to 82 non-human identities per human, and that ratio is growing 300–500% annually wherever agentic AI is deployed. Every one of those identities issues credentials. The credentials are consumed in dozens of places, local development environments, CI pipelines, container images, Kubernetes manifests, Terraform plans, Lambda environment variables, ChatOps messages, internal documentation, support tickets, AI agent context. Anywhere a credential touches, it can stick.

The off-vault secret problem is not new. The 2023 CircleCI token compromise was a credential-on-the-wrong-machine breach. The Vercel-style env-var leak is the canonical example of a build-time secret escaping its intended boundary. Long-lived AWS access keys in .env files have been the signature finding in IR postmortems for a decade. The pattern is consistent: a secret moves from "managed location" to "convenient location," and from "convenient location" to "discoverable by an attacker."

Vaults solve storage. They don't solve where storage leaks to.

Why Traditional Approaches Fall Short

Vault-only tools tell you about what's in the vault. That's the entire premise, they govern managed secrets. The off-vault world is invisible to them by design. A HashiCorp Vault or CyberArk deployment can tell you that a database credential exists at a specific path; it cannot tell you the same credential is also pasted into a developer's .env.local, mirrored in AWS Secrets Manager under a different name, and shared in a Slack channel from 2023\.

Regex-based secret scanners go partway. They search code for known credential patterns and flag matches. But they don't look in Confluence pages, Notion docs, Slack messages, Kubernetes secret manifests (which are base64-wrapped by default), Terraform state files (which embed provider credentials in JSON), or developer shell history. The places where secrets actually accumulate are exactly the places scanners typically don't reach.

DLP and CASB platforms watch traffic for sensitive data egressing the network. They might catch a credential being emailed to an external address. They don't catch a credential sitting inside a Confluence page that an employee opens every day, or one base64-encoded inside a Kubernetes manifest checked into a private repo. The data is in motion only when it's in motion; off-vault secrets are often static.

Manual audits, "let's grep our repos for AWS keys this quarter", find some of the problem some of the time. They don't run continuously, they don't dedupe by identity, they don't compute blast radius, and they don't attribute findings to owners. The output is a CSV that nobody owns and nobody acts on, and the next quarter the same secrets are still there.

The combined effect: enterprises with mature vault deployments routinely discover, during incident response, that the breached credential never lived in the vault at all. The vault wasn't compromised. The credential just wasn't there.

What an Effective Off-Vault Secret Discovery Platform Must Do

An effective off-vault secret discovery platform must do six things.

Look in every place secrets actually accumulate. Source code (every branch, every fork, full git history), .env files on developer endpoints, CI/CD pipeline configs and environment variables, build artifacts and container images, Kubernetes secret manifests, Terraform state, Lambda and EC2 env vars, Slack threads, Confluence pages, Notion docs, Jira tickets, support cases, shared docs platforms. Not just code.

Decode wrapped formats. Kubernetes secrets are base64. Terraform state is JSON. Container env vars are plain text but nested in image layers. The platform must parse, decode, and re-inspect every wrapper.

Correlate every off-vault secret with its in-vault counterpart. When the same logical credential exists both in HashiCorp Vault and in a .env file, the platform should recognize them as one identity with two locations.

Compute blast radius at discovery. A credential in a .env file is not "low risk because it's local" or "high risk because it's local", it's whatever risk the credential it embeds carries. Scoring should reflect actual reach in production, not file location.

Attribute every finding to a human owner. The credential's original creator, the developer who copied it to the off-vault location, the team that owns the workload that consumes it. Without owners, off-vault findings sit in a queue forever.

Drive remediation paths. Revoke the off-vault copy, rotate the upstream credential, migrate to a short-lived alternative, each finding should carry the next action, not just the alert.

How Clutch Solves It

Clutch's discovery engine connects to every system where off-vault secrets accumulate, GitHub, GitLab, Bitbucket, Jenkins, GitHub Actions, CircleCI, Salesforce, Slack, Confluence, Notion, Jira, AWS, Azure, GCP, Kubernetes (across EKS, AKS, GKE), Terraform state backends, HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and 100+ other systems through native APIs. The discovery is continuous: new secrets surface as they're created, not on a quarterly job.

For every secret discovered outside a vault, Clutch builds an Identity Lineage® record. The graph traces origin (which system or human created the credential), every observed location (vault, mirror, .env, Slack thread, Confluence page, Kubernetes secret, Terraform state, container env var), every consumer that fetches it, and every resource it can reach. When the same secret exists inside a vault and outside it, Identity Lineage® unifies them: one identity, multiple exposure surfaces. This is what allows remediation to act on the underlying credential rather than chasing copies.

The platform parses the formats regex scanners ignore. Kubernetes Secret objects are read through the cluster API, base64-decoded, and inspected for credential payloads inside the decoded value. Terraform state in S3, GCS, or Azure Blob is parsed as JSON, with provider credential fields located, validated against the corresponding cloud IAM, and scored. Slack DM and channel content is scanned via the Slack API for token patterns and validated against the issuing systems. Confluence and Notion pages are crawled and inspected at structure level, not just text level.

Workforce Attribution names the human responsible for every off-vault finding. When a GitHub PAT appears in a Confluence page, Clutch attributes the page edit to the engineer who made it and ties the PAT itself to its GitHub creator. When a Kubernetes secret in a cluster manifest contains a credential, Clutch identifies the engineer whose kubectl apply introduced it. When an employee who created a .env-resident secret has left the company, the finding is escalated to their former manager.

Blast-radius scoring is computed at discovery. A .env file finding isn't ranked by where the file is, it's ranked by what the credential inside reaches. A long-lived AWS access key in a .env file with s3:PutObject permissions on the production data lake is a high-severity finding regardless of whose laptop the file is on.

The Universal NHI MCP Server makes the off-vault inventory queryable in natural language, show me every credential that exists both in HashiCorp Vault and in a .env file, or show me every Confluence page containing a live OAuth token, with Identity Lineage® attached to each answer. The Zero Knowledge Architecture keeps secret plaintext inside the customer environment; Clutch ingests the metadata required to build the graph without exfiltrating the secrets themselves.

Practical Examples

A long-lived AWS access key in a .env file in a forked repo. A developer forks an internal repo to a personal account during a hackathon and pushes a .env containing a production AWS access key that was originally pasted there in 2023\. The key still has s3:GetObject access to a customer data lake. Clutch discovers the key in the forked repo, links it via Identity Lineage® to the original repo's history and to the AWS Secrets Manager entry that mirrors it, attributes it to the original engineer, and surfaces a one-click migration to a short-lived ephemeral identity.

A GitHub PAT in a CI pipeline pasted from a Slack thread. An engineer asks for help in a Slack channel; another engineer pastes a working PAT into the thread to "show what's needed." Three weeks later, the PAT is committed to a CI pipeline as an env var. Clutch detects both the Slack message and the CI env var, correlates them as the same identity, computes the blast radius (write access to two production repos), and routes a ticket with both locations attached.

A base64-encoded Kubernetes secret mirrored across three clusters. A developer creates a Kubernetes Secret containing a Stripe API key, then kubectl applys the manifest into three EKS clusters via a copy-paste rollout. The key is also stored in AWS Secrets Manager. Clutch reads all three clusters, decodes the base64, recognizes the same Stripe credential, links the four locations as one identity, computes that the key has live access to the production Stripe account, and proposes consolidating to a single short-lived credential flow.

The Bottom Line

Vaults solve storage. They don't solve where storage leaks to, and that's where breaches happen. Long-lived AWS access keys in .env files, GitHub PATs in Slack threads, base64-wrapped Kubernetes secrets, and provider credentials in Terraform state are the off-vault inventory most enterprises don't have. Clutch discovers every off-vault secret across code, CI/CD, SaaS, runtime, and developer endpoints, unifies them with in-vault counterparts through Identity Lineage®, attributes each to a human owner via Workforce Attribution, and scores blast radius at discovery. The next breach won't be a vault failure. It'll be a credential the vault never knew about.