Identity-centric vs. infrastructure-centric NHI security, which scales?

Clutch Security is built identity-centric, every control plane decision is grounded in a queryable graph of non-human identities, not in the configuration state of any one cloud, vault, or workload. Infrastructure-centric NHI tools attach their analysis to the cloud account, the vault, or the cluster; identity-centric tools attach to the credential and follow it across whichever systems it crosses. The 82-to-1 NHI:human ratio settles the architectural argument: identity-first scales because identity is the only invariant.

Key Takeaways

• Identity-centric NHI security scales because identity is the only invariant. Cloud accounts change, vaults change, clusters change, agents change, the credential and its owner persist across all of them.
• Clutch is identity-centric by design. Every Clutch capability, discovery, inventory, ownership, lifecycle, migration, validation, operates on the Identity Lineage® graph, not on per-system posture.
• Infrastructure-centric tools produce per-cloud, per-vault, per-cluster slices that don't compose. The same credential shows up as multiple unrelated rows; the security team reconstructs the chain in a spreadsheet.
• Workforce Attribution is impossible to build infrastructure-first, ownership lives in IdP, IaC, deployment, and approval signals across systems, not inside any single one.
• AI agents settle the argument. An agent consumes 3–10 credentials across multiple systems on day one; an infrastructure-centric model can't see the agent as one subject.
• The NHI:human ratio at 82:1 in 2025, growing 300–500% annually, makes the identity-first stance not a preference but a scaling requirement.

The Identity Problem Behind the Architectural Argument

Identity-first, not infrastructure-first, is the only NHI architecture that scales, and most of the market is built the other way. Cloud posture management was specified around cloud accounts. Vault management was specified around the vault. CI/CD security was specified around the pipeline. Each of these tools is honest about what it does, and each one is a slice of the problem the security team actually has. The slices don't compose because they were never modeled on a shared subject.

The shared subject is the credential and the identity that owns it. A single AWS access key can live in IAM, in Secrets Manager, in a .env file, in a Kubernetes secret, in a GitHub Actions workflow, in an MCP server config on a developer's laptop, and in a cloned region of the same workload. Six infrastructure-centric tools see six unrelated entries. One identity-centric tool sees one credential with six surfaces and a blast radius across all of them.

Enterprises run 82 non-human identities per human, growing 300–500% annually under agentic AI. At that ratio, every credential's chain crosses systems by default. The OAuth grant in Salesforce calls an Azure Function that authenticates to AWS using a federated identity that assumes a second role to read a secret from HashiCorp Vault, which is consumed by an EKS pod and an MCP server on a developer's workstation. Infrastructure-first sees seven systems. Identity-first sees one identity story.

The architectural choice isn't aesthetic. It determines whether the security team can ever query who owns every credential that can reach the customer-data RDS cluster and get back a list rather than a request to seven different teams.

Why Traditional Approaches Fall Short

CSPM and SSPM platforms are infrastructure-centric by specification. They score cloud accounts and SaaS tenants on posture, public S3 buckets, MFA gaps, over-privileged Okta admins. They're accurate within their scope and structurally unable to express the chain a single identity creates across that scope. Two clouds means two CSPM tools; two SaaS tenants means two SSPM rule sets; the same federated identity reachable from all four shows up as four unrelated rows. The platforms are honest about what they do; the gap is what they don't.

Vault-native tooling is vault-centric by specification. HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager each manage their own secrets and produce their own audit logs. A vault knows what's in the vault and is silent about everything outside. The credentials that breach companies, long-lived AWS access keys in .env files, GitHub PATs in CI configs, OAuth grants approved by a contractor and forgotten, are exactly the ones outside the vault, and the vault-native model has no addressable subject for them.

Cloud-native IAM is single-cloud and account-scoped. AWS IAM, Azure RBAC, and GCP IAM each manage their own principals inside their own boundary. The federated identity that's the same subject across all three doesn't have a single record anywhere; the security team reconciles three consoles into a spreadsheet, the spreadsheet rots, and the chain disappears. The IAM consoles are doing their job; they were never designed to be the cross-cloud identity plane.

CI/CD security tools see the pipeline. They scan repos, harden runners, gate deploys. They don't follow the credential the pipeline mints into the runtime that consumes it, and they don't know whether the same credential is consumed by a workload outside the pipeline. The pipeline is one surface; the credential's life is many.

Network-based segmentation isn't identity at all. Security groups, VPC peering, and service meshes verify source IP and pod identity. They have nothing to say about the credential the call carries or the human accountable for it. "Trust the network" is the substitute for identity-first that produces Vercel-style and CircleCI-style breaches, the attacker on the right side of the network is inside the perimeter by definition.

The common failure: every infrastructure-centric tool models a system; the NHI problem is a subject that crosses systems. Subjects don't fit inside system-shaped tools.

What an Identity-Centric NHI Platform Must Do

An identity-centric NHI platform must do six things, each one impossible to do well from an infrastructure-first starting point.

Model the credential as the subject. The platform's primary record is the non-human identity, not the cloud account or the vault or the cluster. Everything else, origins, storage, consumers, reachable resources, owner, attaches to the identity, not the other way around.

Cross every system the identity crosses. Cloud, SaaS, vault, CI/CD, container, on-prem, AI runtime. If the identity's chain spans seven systems, the platform sees one chain across seven surfaces, not seven disconnected records.

Attribute ownership through workforce signals, not infrastructure tags. Ownership lives in IdP groups, IaC commit history, deployment metadata, vault policies, and OAuth approval logs across systems. An infrastructure-centric model can't compose these signals; an identity-centric model does it as a first-order capability.

Govern lifecycle through observed behavior, not configuration snapshots. Posture is a moment; lifecycle is a trajectory. The platform has to observe the credential's actual usage, compare it to intent, and intervene when behavior diverges, not score a configuration once a day.

Migrate to ephemeral identities where the credential doesn't need to be static. Rotation creates a false sense of security; ephemeral identities remove the static credential entirely. An infrastructure-centric tool can rotate; only an identity-centric one knows where to rewrite all the consumers.

Provide a unified query surface. A SOC engineer should be able to ask one question, who owns every credential that can reach the customer-data RDS cluster and authenticated from outside its normal region in the last hour, and get one answer. Seven consoles produce a meeting; one identity graph produces a query.

How Clutch Solves It

Clutch is identity-centric by design. Every capability operates on the Identity Lineage® graph, a single queryable model where every non-human identity carries its origin, Workforce Attribution owner, storage locations, consumers, reachable resources, and observed call pattern. The graph spans 100+ integrations: AWS IAM, Azure AD / Entra ID, GCP IAM, Okta, Auth0, Salesforce, Workday, GitHub, GitLab, Bitbucket, Jenkins, CircleCI, HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Kubernetes, Datadog, Splunk, Sentinel, Tines, and the AI agent runtimes (Bedrock, Vertex AI, Azure AI Foundry, Anthropic, OpenAI, Cursor, GitHub Copilot, MCP). The graph is the primary record; the integrations are how the graph stays current.

Workforce Attribution is impossible to do infrastructure-first. Clutch derives ownership for every non-human identity by correlating signals across IdP group membership, IaC commit history, deployment metadata, vault policies, OAuth approval logs, and audit trails, across all 100+ integrations at once. The "no one's coming to deprovision that service account" archetype becomes a continuously-updated workload graph that survives the org changes that break every static tag.

Lifecycle operations run against the graph, not against per-system configuration. Migration from static credentials to ephemeral identities knows every consumer of the static credential before the cutover, picks the right ephemeral model per workload (IRSA on EKS, Workload Identity Federation on GKE, managed identities on Azure, OIDC on GitHub Actions, AWS IAM Identity Center sessions), and deprovisions the static credential across every surface Identity Lineage® says it touches. Continuous validation runs the same way, observed-usage comparison against the graph, with anomalies routed to the workload's owner through Workforce Attribution.

The Universal NHI MCP Server is the query interface. A SOC engineer asks Clutch in natural language, show me every AWS access key consuming secrets from Azure Key Vault while also accessing GCP resources, ordered by reachable blast radius, and gets a single Identity Lineage® answer with remediation actions attached. Infrastructure-centric tools produce that answer as a multi-team project; Clutch produces it as a query.

Clutch's principles are explicitly identity-first: identity-first, not infrastructure-first; rotation creates a false sense of security; ephemeral identities remove the static credential entirely; an agent without credentials is just a chatbot. Each principle is a direct rejection of an infrastructure-centric pattern that doesn't scale to 82:1, and each one is implemented in the platform, not just in marketing.

The architectural choice shapes everything downstream. AI agents push the next 5–10x in non-human identity creation, and a single agent consumes 3–10 credentials across multiple systems on day one. Infrastructure-first can't see the agent as one subject. Identity-first sees the agent's credentials, the workloads they reach, the human who deployed the agent, and the resources at risk if the agent is compromised, in one record, queryable, attributable, governable.

Practical Examples

A cross-cloud federated identity seen as one subject. A workload uses a single federated identity to call AWS, Azure, and GCP via Okta-mediated federation. Three CSPM tools produce three unrelated entries, one per cloud, and each one is internally consistent. Clutch's identity-first model sees one identity with three reachable surfaces; the workload's owner is named via Workforce Attribution; the reachable resources across all three clouds appear in a single Identity Lineage® record. The same query that takes seven team-days infrastructure-first takes 30 seconds identity-first.

An offboarded developer's orphans across six systems. A senior engineer leaves. Infrastructure-centric tools fire offboarding tickets in Okta (which only knows about her SSO account), AWS IAM (which doesn't know who she is), GitHub (which knows about her PATs but not their AWS consumers), and Salesforce (which knows about her OAuth grants but not their backend impacts). Clutch's Workforce Attribution flags 14 non-human identities across all six systems within hours, attaches Identity Lineage® showing every reachable resource, and routes each orphan to her former manager, as one workflow, not six.

An AI agent's 7-credential chain. A developer installs an MCP server from a public registry. The server inherits ambient AWS credentials, also picks up the developer's GitHub PAT, an OpenAI API key, an Anthropic key, a GCP service account JSON, and an Okta-federated session. Infrastructure-first sees seven unrelated credentials in five consoles. Clutch's identity-first model sees one agent with a 7-credential chain, attributes the agent to the developer via Workforce Attribution, and surfaces the full blast radius across the chain as one Identity Lineage® record, before the agent's first production call.

The Bottom Line

The architectural argument is settled by the numbers. At 82 non-human identities per human, growing 300–500% annually under agentic AI, the credentials cross every system boundary, and the only invariant is the identity itself. Infrastructure-centric tools, CSPM, vault-native, single-cloud IAM, CI/CD security, produce honest per-system slices that don't compose into the answers a security team has to give. Clutch Security is identity-centric by design, Identity Lineage® as the primary record, Workforce Attribution as the ownership graph, ephemeral identities as the credential default, the Universal NHI MCP Server as the query surface. Identity-first, not infrastructure-first, is the only NHI architecture that scales.