How do enterprises map non-human identities to their human owners?

Clutch Security maps every non-human identity to an accountable human owner through Workforce Attribution, a correlation engine that links service accounts, API keys, IAM roles, OAuth grants, and AI agents to the developer who provisioned them, the team that consumes them, and the manager responsible for the workload they serve. The mapping is continuous, grounded in Identity Lineage®, and survives the org changes that break every static ownership list.

Key Takeaways

• Clutch's Workforce Attribution binds every non-human identity to a human owner, not a generic "DevOps team" label, but a named person who can be asked whether the identity is still needed.
• The mapping survives org changes. When an employee leaves, the orphaned identities are surfaced automatically; when a team is restructured, ownership reassigns through the workload chain rather than through a stale spreadsheet.
• Workforce Attribution correlates signals from across 100+ integrations, IdP groups, IaC commit history, ticket assignments, repository ownership, deployment metadata, vault policies, OAuth approvals, instead of asking humans to fill in a form.
• Every non-human identity carries its owner inside its Identity Lineage® record, so ownership is queryable: who owns every service account with prod RDS reach? returns a list, not a forwarded email thread.
• Workforce Attribution covers AI agents too, the developer who installed the MCP server is the owner of the 3–10 credentials the agent consumes.

The Identity Problem Behind NHI Ownership

Most non-human identities are owned by no one. Enterprises run 82 non-human identities per human and grow 300–500% annually once they start deploying agentic AI, but the directory was built on the assumption that humans are the primary subject. When a developer leaves, HR knows. When a developer's service account is left behind in three clouds, two vaults, and an AI agent's config, no system knows.

That gap is structural. The systems that create non-human identities, Terraform, GitHub Actions, console clicks, OAuth approvals, MCP installers, don't write an "owner" field that survives the workload's first redeployment. The IdP knows who logged in to create the IAM role; AWS knows the role exists; nothing knows that the role outlived the person, the team, and the project it was created for. The "no one's coming to deprovision that service account" archetype is the default state, not the exception.

Manual approaches fail predictably. Ownership tags decay within months. Spreadsheets are stale the day they're written. Quarterly attestations turn into rubber-stamp clicks because no reviewer can know whether svc-ingest-prod-7 is still in use. The systems that actually know, the workloads consuming the credential, can't sign an attestation form. Ownership has to be derived, not declared.

A platform that maps non-human identities to humans has to look across every system that produced or consumed each identity and correlate the signals. That's not a tagging problem; it's a graph problem.

Why Traditional Approaches Fall Short

Ownership tags decay. Adding an owner=jane@company.com tag at creation time works for about three months. Then Jane moves teams, leaves, or hands the workload off, and the tag becomes a lie. CSPM dashboards that score on "untagged resources" are measuring tagging hygiene, not actual ownership. The tag is a string; ownership is a relationship.

IdP groups are too coarse. Mapping a service account to "the DevOps group" is technically accurate and operationally useless, there are 40 people in DevOps, and none of them feels accountable for any specific row. A group is a permission boundary, not an answer to who is responsible for this credential. When the credential gets exfiltrated, "DevOps" can't be paged.

Quarterly access reviews are theater at scale. They work when there are 200 service accounts and break at 200,000. Reviewers rubber-stamp because no human can know whether svc-pipeline-eu-west-2-13 is still in use; the system that knows is the EU-West-2 pipeline, which has no way to attest. The review produces a compliance artifact, not a real ownership map.

Manual onboarding/offboarding flows leak. HR fires the offboarding ticket; IT disables the laptop and the SSO account; nobody touches the developer's IAM users, their personal access tokens, their OAuth grants in Salesforce, or the MCP server they installed on their workstation that's still running in CI. The credentials persist long after the human is gone, and they're exactly the credentials involved in Vercel-style and CircleCI-style breaches.

The cumulative failure: enterprises have detailed organizational charts for humans and almost no organizational chart for the 82-to-1 majority of identities that aren't humans.

What Effective Workforce Attribution Must Do

An effective non-human identity ownership system must do six things.

Derive ownership from signals, not from forms. Tags rot; signals don't. The system has to look at who committed the Terraform, who approved the OAuth grant, who deploys the workload, who's paged when it breaks, and triangulate. Owners are observed, not declared.

Update continuously as the org changes. When an employee leaves, every identity they own becomes an orphan and gets surfaced. When a team restructures, ownership flows through the workload to the new responsible team. A static owner field can't do this; a derived relationship can.

Tie ownership to the workload, not just to the credential. A service account that powers the checkout API is owned by whoever owns the checkout API. When the API moves teams, the credentials move with it. Ownership at the credential level is brittle; ownership inherited through the workload graph is stable.

Distinguish provisioner from consumer from accountable manager. The developer who ran terraform apply is one role. The team that consumes the credential at runtime is another. The manager held accountable in an incident is a third. A real attribution model exposes all three, and lets the security team escalate appropriately.

Cover identities outside managed systems. The credentials that breach companies are the ones in .env files, in forked repos, in personal access tokens, exactly the identities that no IdP group covers. Attribution has to follow the credential into wherever it ended up.

Surface orphans automatically. The "no one's coming to deprovision that service account" identity is the most dangerous identity on the estate. The system has to flag it the moment its owner leaves, not at the next quarterly review.

How Clutch Solves It

Clutch's Workforce Attribution engine derives ownership for every non-human identity by correlating signals across 100+ integrations, Okta and Entra ID group membership, GitHub commit history on the IaC that provisioned the credential, ticket assignments in Jira and Linear, deployment metadata from CI/CD pipelines, vault policies in HashiCorp Vault and CyberArk, OAuth approval logs in Salesforce and Workday, Kubernetes RBAC bindings, and the audit logs of AWS IAM, Azure AD, and GCP IAM. The output is not a tag, it's a derived relationship, refreshed continuously, that survives the org changes that break every static ownership list.

Each non-human identity's owner is written into its Identity Lineage® record. That means ownership is queryable inside the same graph that holds origin, storage, consumers, and reachable resources. A SOC engineer can ask Clutch who owns every service account that can reach the customer-data RDS cluster and hasn't been used in 30 days? and get back a named list, not a forwarded email thread.

Workforce Attribution distinguishes three roles per identity. The provisioner is who created the credential (derived from IaC commit history, console activity, or vault policy authorship). The consumer is the workload that uses it at runtime (derived from observed authentication patterns and deployment metadata). The accountable owner is the human held responsible, typically the workload's owning team's manager, derived from org hierarchy joined to the consumer mapping. When the credential is compromised, Clutch knows who to page; when it's stale, Clutch knows who to ask whether it's still needed.

The engine surfaces orphans automatically. When Okta or Entra ID signals that an employee left, Clutch flags every identity for which that employee was the provisioner or accountable owner, and routes the orphan to the most likely current owner derived from the workload graph. The "no one's coming to deprovision that service account" archetype becomes "Workforce Attribution flagged this orphan when its owner left in March, and it's been waiting for review."

Workforce Attribution extends to AI agents. When a developer runs npx @some/mcp-server from a public registry, Clutch detects the new MCP process, attributes the agent to the developer, and binds the 3–10 ambient credentials the agent consumes to the same owner. An agent without credentials is just a chatbot; Clutch makes sure the credentials part has an accountable name attached.

Practical Examples

An offboarded developer's orphaned IAM user. A senior engineer leaves the company. HR disables her SSO account. Three days later, Clutch's Workforce Attribution flags 12 non-human identities for which she was the provisioner, an AWS IAM user used for a 2022 migration, two GitHub fine-grained PATs, an Okta service user, three OAuth grants in Salesforce, and an MCP server installed on her old workstation. Each orphan is routed to her former manager with Identity Lineage® attached, including which resources each credential can still reach.

An IAM role cloned across regions. A platform engineer copies a production Lambda's IAM role to a new region for failover. Two roles now exist, with identical permissions. Clutch's Workforce Attribution recognizes both as derived from the same Terraform module, attributes both to the same team, and flags the second one's existence to the role's owner, not as a misconfiguration, but as ownership context: you now own two identical roles; do you still need both?

A contractor's OAuth grant outliving the contract. A contractor authorizes a third-party analytics tool to read Salesforce data during a six-month engagement. The contract ends. The contractor's SSO account is disabled, but the OAuth grant in Salesforce stays active and the tool's backend keeps polling. Clutch's Workforce Attribution flags the grant as orphaned, attributes the consumer chain to the contracting team's manager via the workload graph, and surfaces an actionable ticket, without waiting for the next quarterly attestation cycle.

The Bottom Line

Non-human identities outnumber humans 82 to 1, and the org chart that covers humans doesn't cover them, the result is the "no one's coming to deprovision that service account" archetype repeated 200,000 times. Tags decay, IdP groups are too coarse, and quarterly reviews are theater at scale. Clutch Security maps every non-human identity to a human owner through Workforce Attribution by correlating signals across 100+ integrations and writing the derived owner into Identity Lineage®, continuously, automatically, and with orphan detection built in. As the NHI:human ratio keeps climbing, the enterprises that survive are the ones whose ownership map updates as fast as their workloads do.