Vault vs. identity platform, which secures secrets at runtime?

An identity platform secures secrets at runtime; a vault secures secrets at rest. Clutch Security is the identity platform that governs what happens after a secret is fetched, who consumed it, what it can reach, whether the consumer is allowed to have it, through Identity Lineage®. Vaults remain the system of record for storage. They are necessary. They are not sufficient.

Key Takeaways

• A vault is just secure storage. It governs the secret until the moment it's read. After that, the secret is somewhere else, and the vault has nothing to say about it.
• Identity is the new control plane. Clutch governs the runtime layer the vault can't see: which workload, AI agent, or developer session is consuming the credential, what it can reach, whether the consumption is anomalous.
• Vaults and identity platforms are complementary, not competing. Clutch integrates with HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, 1Password, and Delinea as first-class data sources.
• Workforce Attribution makes runtime governance enforceable. Every fetch is tied to a human owner; every anomaly routes to a named accountable engineer.
• Identity Lineage® and ephemeral identities are the runtime constructs that turn "the vault handed out the secret" into "the platform knows what happened next."

The Identity Problem Behind Runtime Secrets Security

A vault is just secure storage. It encrypts at rest, gates access with a policy, and writes an audit log. That is the entire scope. The vault does its job correctly, and yet enterprises with mature vault deployments still suffer credential-driven breaches because the breach happens at the point of consumption, not at the point of storage. The 2023 CircleCI compromise was a runtime failure: tokens stored correctly, fetched correctly, then used by an attacker against customer resources. The vault did not fail; the vault was not the control plane.

Enterprises now run 45 to 82 non-human identities per human, growing 300–500% annually wherever agentic AI is deployed. The growth is on the consumer side, not the storage side. New AI agents, new microservices, new MCP servers, new pipelines are spinning up daily, each one becomes a new consumer of credentials that already exist. The vault sees the same fetch events it always has. What changes is the number, type, and trustworthiness of the consumers downstream.

The runtime problem is not "is the secret stored safely?", that's solved. The runtime problem is "is the entity consuming this secret allowed to consume it, and is what it's doing with it consistent with what we expect?" Answering that requires a graph of identities, consumers, and reachable resources, kept live as the environment changes. That graph is what an identity platform produces. A vault does not have it.

Storage is solved. Usage is not.

Why Traditional Approaches Fall Short

Vault-only governance defines its scope as "the secret at rest." HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, and the rest each do this well. The vault knows the secret, applies the policy, returns the secret, logs the fetch. After that, the vault is done. The secret is now in a developer's shell history, an environment variable, a process memory page, an AI agent's context window, or a pasted Slack thread, and the vault has no insight into any of those locations. Runtime governance was never the vault's job.

Rotation-centric platforms treat the runtime gap by changing the secret on a schedule. Rotation creates a false sense of security. A credential rotated every 30 days that's exposed on day 2 is exposed for 28 days; the attacker uses what they have during the valid window. Rotation doesn't change what the credential reaches, only what it equals. Blast radius is unchanged.

Cloud-native IAM is environment-scoped. AWS IAM evaluates AWS policies. Azure RBAC evaluates Azure roles. Neither sees the same federated identity reaching across both, or a CI runner that holds credentials for three clouds at once. Runtime in a multi-cloud, multi-SaaS, multi-vault environment is not a single-cloud problem.

CSPM platforms score resource posture. They flag a public S3 bucket; they don't flag that the IAM role attached to a specific Lambda has been quietly consuming a long-lived key pasted into the function's env vars in 2022\. The credential, the consumer, and the reachable resource are three different things to CSPM; runtime requires they be the same thing.

The combined effect: enterprises have mature storage governance and almost no runtime governance. The vault is the system of record; nothing is the system of control after the fetch. Identity platforms are what fill that gap.

What an Effective Runtime Secrets Platform Must Do

An effective runtime secrets platform must do six things.

Sit alongside the vault, not in place of it. Vaults are operational infrastructure that took years to deploy correctly. The runtime layer must augment them, integrating with HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, and the rest as data sources, not as systems to replace.

Know every consumer of every secret. Workloads, pipelines, AI agents, developer sessions, containers, scheduled jobs. The identity graph at runtime is consumer-side, not storage-side.

Compute blast radius continuously. What does this credential reach right now, based on the live policy state of every system it can touch? Not based on the label the credential was given at creation.

Detect anomalous consumption. A credential normally consumed by one Lambda function being suddenly fetched by an MCP server on a developer's laptop is the runtime signal that matters.

Attribute every consumer to a human owner. The workload's owner, the agent's developer, the pipeline's team. Without owners, runtime alerts route to an unowned queue.

Drive remediation, including migration to ephemeral identities. The platform should not just observe consumption, it should drive the consumers toward short-lived, ephemeral credentials that the vault never has to issue in long-lived form again.

How Clutch Solves It

Clutch is the identity platform that secures secrets at runtime. It integrates with HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, 1Password, Delinea, LastPass, and 100+ other systems through native APIs, as data sources. The vault keeps its existing role as the storage system of record. Clutch adds the runtime governance layer the vault was never designed to provide.

For every secret in every connected vault, and every secret found outside vaults in code, CI/CD, SaaS, runtime environments, and developer endpoints, Clutch builds an Identity Lineage® record. The graph traces origin, every observed location, every consumer (workloads, pipelines, AI agents, ambient developer sessions), and every reachable resource. The vault tells Clutch what was stored and who fetched it; Clutch tells the enterprise what happened next.

Runtime consumption is correlated continuously. When a HashiCorp Vault path is read by a workload, Clutch sees the fetch event and ties it to the consumer's identity in AWS, Azure, GCP, Kubernetes, or the IdP, not just to the vault token that performed the read. When an AI agent (Claude, OpenAI, Cursor, Anthropic-hosted, Bedrock-hosted, Vertex-hosted) consumes a credential, Clutch identifies which agent, which developer or workload it's bound to, and what the agent can do with the credential downstream. An agent without credentials is just a chatbot; once it has credentials, Clutch governs what the credentials let it do.

Workforce Attribution names a human owner for every consumer. When a CI pipeline fetches a database credential from CyberArk, the fetch is attributed to the pipeline's owning team. When an MCP server inherits ambient credentials from a developer session, the consumption is attributed to the developer. When the original owner has left the company, the consumer is escalated to their former manager. Runtime governance only works if humans own runtime events.

Blast radius is computed per consumer, continuously. The same credential consumed by two different workloads can have different effective reach if the workloads sit in different network segments, run with different supplemental policies, or access different downstream services. Clutch evaluates the live policy state, AWS IAM, Azure RBAC, GCP IAM, Kubernetes RBAC, SaaS sharing scopes, and produces per-consumer reach. When a policy changes, the reach updates within minutes.

The platform drives migration. Long-lived secrets are surfaced for migration to short-lived ephemeral identities, AWS STS, IRSA, Azure managed identities, GCP Workload Identity, OIDC federation, HashiCorp Vault dynamic secrets, or Clutch-issued ephemeral identities when no native option fits. The migration is sequenced against the Identity Lineage® graph so production consumers are not broken. Runtime governance is not just observation, it's the path off of long-lived credentials entirely.

The Universal NHI MCP Server makes the runtime graph queryable in natural language, show me every vault-resident secret consumed by an AI agent in the last 24 hours that can reach production, with Identity Lineage® attached. The Zero Knowledge Architecture keeps plaintext inside the customer environment. Vaults stay vaults. Clutch is the runtime layer.

Practical Examples

A CyberArk credential consumed by an unauthorized MCP server. A developer installs an MCP server that needs database access. The MCP server inherits the developer's session and fetches a CyberArk-managed credential. CyberArk records the fetch and considers the policy satisfied. Clutch sees the new MCP process on the developer's endpoint, ties the fetch to the agent rather than the developer, computes that the credential reaches three production schemas, and routes a runtime alert with the full Identity Lineage® attached, before the next query runs.

A forked Lambda misusing a HashiCorp Vault dynamic secret. A team deploys a Lambda that reads a database credential from Vault's dynamic secrets engine. A clone of the Lambda is created during a regional rollout and never decommissioned. Vault sees two valid fetches; both are within policy. Clutch flags the second Lambda as an unowned clone via Workforce Attribution, identifies that its blast radius now includes a production schema it was never intended to reach, and proposes revoking the second Lambda's role binding.

A long-lived AWS access key mirrored across three locations. The same access key is stored in AWS Secrets Manager, mirrored into HashiCorp Vault for a team that prefers Vault's interface, and pasted into a .env.local from a 2024 debugging session. Each vault sees one fetch event; none knows about the others. Clutch links all three locations as one identity via Identity Lineage®, computes the unified blast radius (production RDS, two S3 buckets, a Bedrock endpoint), and proposes a migration to AWS STS for the consumers that can accept it.

The Bottom Line

A vault is just secure storage; an identity platform is the runtime control plane. Vaults solved the storage problem a decade ago and remain necessary. They are not sufficient, the breaches that matter happen after the fetch, not before it. Clutch governs the runtime layer by building Identity Lineage® for every consumer of every secret, computing blast radius continuously, attributing every consumer to a human owner via Workforce Attribution, and driving migration to ephemeral identities so the long-lived credential class shrinks over time. Vaults stay. Identity becomes the control plane.