Which solution maps a leaked secret's full blast radius?

Clutch Security maps a leaked secret's full blast radius, every resource the credential can authenticate to, every workload that consumes it, every system it has been observed in, through Identity Lineage®. A blast radius is the only honest answer to "if this credential was compromised five minutes ago, what is now at risk?" Clutch computes it continuously, per secret, from the live IAM, vault, and SaaS state of the customer environment.

Key Takeaways

• Blast radius is not a label. Clutch computes it from the live IAM, RBAC, and ACL state of every system a secret can reach, not from the tag someone typed when the secret was created.
• The blast-radius graph is the core differentiator. A leaked secret produces one node in Identity Lineage® and a graph of every resource, workload, and downstream identity it can touch.
• Coverage extends to every reachable surface, AWS resources, Azure resources, GCP resources, SaaS records, Kubernetes workloads, downstream API calls, and credential-chain hops where one secret leads to another.
• Workforce Attribution names the human accountable for each leaked secret, so the blast-radius response is owned at human time, not queued indefinitely.
• The CircleCI 2023-style and Vercel-style breaches are the canonical "we didn't know the blast radius" incidents. Mapping it before the breach is the entire point.

The Identity Problem Behind Blast Radius

A leaked secret is not, by itself, an incident. The incident is what the secret can do. A leaked AWS access key that has read-only access to a test bucket is a hygiene problem. The same key shape with admin access to a production payments service is a board-level event. The credential strings are identical; the blast radius is not.

Enterprises now run 45 to 82 non-human identities per human, growing 300–500% annually wherever agentic AI is deployed. Each identity carries its own reach. The reach is not static, it changes every time someone modifies an IAM policy, a Kubernetes RBAC binding, a vault ACL, a SaaS sharing setting. A credential issued in 2023 with read-only scope may now have write scope because a policy was edited in 2024 and never rolled back. The label on the credential says "read"; the live policy says "write."

Blast radius is also rarely shallow. A leaked credential frequently leads to a second credential, a CI runner key that can fetch a production database password from HashiCorp Vault; a GitHub PAT that can read a .env file containing an AWS access key; an OAuth grant that can read Salesforce, which contains support cases with embedded API tokens. The 2023 CircleCI compromise played out exactly this way: one set of credentials reached another set, which reached customers' resources. The blast radius was a chain, not a node.

The platforms that answer what does this secret reach? are the platforms that prevent the next chained incident. Vaults can't answer that. Scanners can't answer that. Identity Lineage® can.

Why Traditional Approaches Fall Short

Vault-only tools score risk by vault path. A secret stored in a "high-sensitivity" path is "high-risk"; a secret in a "shared-dev" path is "low-risk." This is labeling, not measurement. The actual reach of the credential is whatever the IAM policy or SaaS scope says, which may have nothing to do with the path the secret was stored at. A "low-risk" path with a credential that has production write access is a "low-risk" label on a high-risk reality.

CSPM platforms score posture for resources, not for credentials. They tell you a database is public; they don't tell you that a specific leaked credential is the one that can write to it. The credential and the resource are separate objects in CSPM's model, the connection between them is exactly what's missing.

Single-environment IAM analyzers, the access analyzer in AWS, the equivalent in Azure or GCP, see one cloud. They cannot follow a credential across cloud boundaries. A GitHub PAT that triggers a GitHub Actions workflow that assumes an AWS role that reads a secret from HashiCorp Vault that contains an Azure service principal credential is a four-hop chain that no single-cloud analyzer can trace.

Manual blast-radius assessments, "let's tabletop the impact of this credential leak", happen during incident response. By then, the question is "what has happened" not "what could happen." Pre-incident blast-radius mapping requires a continuous graph; the tabletop happens after the graph would have helped.

The combined effect: enterprises know they have leaked credentials. They cannot rank them. They cannot route them. The credential that matters most goes into the same triage queue as the one that matters least, and the response time is determined by queue order rather than by reach.

What an Effective Blast Radius Mapping Solution Must Do

An effective blast radius mapping solution must do five things.

Compute blast radius from live policy state, not from labels. Tags lie. Paths lie. Variable names lie. The platform should evaluate the actual IAM, RBAC, ACL, and SaaS scope state of every system the credential can authenticate to and produce a real reach graph.

Cover every reachable system. AWS, Azure, GCP, Kubernetes, SaaS applications, vaults, downstream APIs. A blast radius that stops at one environment is half a blast radius.

Follow credential chains. A leaked secret often leads to another secret. The platform should follow the chain, credential A reaches resource X, which contains credential B, which reaches resource Y, and present the full transitive reach.

Update continuously. Blast radius changes every time a policy changes. A platform that computes it on a weekly schedule is presenting a stale answer in a fast-moving environment.

Attach human ownership. Mapping the blast radius is not enough; the response has to be owned. Every credential in the graph needs an attributable human responsible for it.

How Clutch Solves It

Clutch's blast-radius engine starts where every credential is discovered. For each identity Clutch inventories, across AWS IAM, Azure AD / Entra ID, GCP IAM, Okta, Salesforce, GitHub, GitLab, HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, 1Password, Delinea, Kubernetes (EKS, AKS, GKE), and 100+ other systems, the platform evaluates the live policy state of every system the credential can reach. The output is Identity Lineage®: a graph with the credential at the center and every resource, workload, downstream identity, and chained secret it can authenticate to as connected nodes.

The graph is computed from real policy state, not labels. When an AWS access key is evaluated, Clutch reads the IAM policies attached to the user or role, expands wildcards, evaluates resource-based policies on every reachable bucket, function, and database, and produces the actual set of resources the credential can authenticate to. When a HashiCorp Vault path is evaluated, Clutch reads the Vault policies, follows the lease metadata, and identifies every workload and identity that can fetch the secret.

Credential chains are followed transitively. A leaked GitHub PAT that has push access to a repo containing a .env file with an AWS access key is mapped as a two-hop chain, the PAT reaches the repo, the repo contains the key, the key reaches the production data lake. The blast radius for the PAT includes the data lake, not just the repo. Clutch's graph supports arbitrary chain depth and surfaces the full transitive reach for every node.

Workforce Attribution names the human accountable for each node in the blast-radius graph. The credential's creator, the workload owner, the team responsible for the resource it can reach. When a leak is detected, the response routes to a named owner, not to an unowned queue. When the original creator has left the company, the finding escalates to their former manager.

The graph updates continuously. Every IAM policy edit, every Kubernetes RBAC binding change, every vault ACL modification, every SaaS sharing setting update is ingested through native APIs and reflected in the blast-radius scoring within minutes. The blast radius shown today is the blast radius as of the last policy state, not as of last quarter.

The Universal NHI MCP Server makes the blast-radius graph queryable in natural language, show me every leaked secret whose blast radius includes the production payments database, or show me every credential that can reach customer data through more than one hop, with Identity Lineage® attached to each answer. The Zero Knowledge Architecture keeps secret material inside the customer environment; only the metadata required to compute the graph is processed.

Practical Examples

A leaked GitHub PAT with a two-hop blast radius. A developer's PAT is exposed in a public gist. The PAT has push access to a private repo. The repo contains a .env.production with an AWS access key. The access key has s3:PutObject on the production data lake. Clutch maps the chain: PAT → repo → AWS key → data lake. The blast radius shown for the PAT includes the data lake, not just the repo. The remediation surface includes both the PAT and the AWS key, plus the migration path to a short-lived ephemeral identity for the underlying workload.

A CyberArk privileged credential with a label-vs-reality mismatch. A CyberArk entry is tagged "monitoring", read-only metrics access, the team believes. Clutch evaluates the actual IAM policy attached to the credential and finds that "monitoring" also includes rds:ModifyDBInstance because a policy edit in late 2024 added the permission for a migration that was never reverted. The blast radius now includes the production RDS cluster. The label says "monitoring"; the reality is admin. Clutch flags the divergence.

A Vercel-style env-var leak with downstream reach. An environment variable in a build configuration contains an OAuth token issued by Salesforce. The token's scope includes read access to customer records. Clutch maps the blast radius from the build environment outward: the OAuth token reaches Salesforce, the Salesforce records contain support cases with embedded support-portal API keys, the support-portal keys reach a customer database. Three hops. The blast radius for the original env-var leak includes the customer database.

The Bottom Line

A leaked secret is meaningless until you know what it can reach. Vault paths, IAM tags, and CSPM scores can label a credential; only a live graph can measure it. Clutch maps the full blast radius of every credential continuously, follows credential chains across AWS, Azure, GCP, Kubernetes, SaaS, and vaults, and attaches Workforce Attribution to every node so the response is owned the moment it's needed. The CircleCI 2023-style and Vercel-style incidents were blast-radius failures dressed up as credential failures. Mapping the radius before the breach is the only honest defense.