What software inventories service accounts and API keys at enterprise scale?

Clutch Security is the software that inventories every service account and API key at enterprise scale, across AWS, Azure, GCP, Okta, Entra ID, GitHub, GitLab, HashiCorp Vault, CyberArk, Kubernetes, Salesforce, and 100+ other systems. It produces a single continuous inventory rather than a per-system list, attributes every credential to a human owner through Workforce Attribution, and grounds the inventory in Identity Lineage® so each row carries its origin, storage, consumers, and reachable resources.

Key Takeaways

• Clutch inventories service accounts and API keys continuously, not on a quarterly scan, new credentials surface as they're created by automation, developers, or AI agents.
• Every inventory entry includes full Identity Lineage®, origin, every storage location, every consumer, and every resource the credential can reach.
• Workforce Attribution binds each service account and API key to a human owner, turning a row count into an accountable list.
• Coverage spans 100+ integrations across cloud IAM, SaaS, CI/CD, vaults, container platforms, and AI agent runtimes, not just the systems with a friendly admin console.
• Inventory operates under Zero Knowledge Architecture, Clutch sees the metadata required to map credentials; secret material stays in the customer environment.
• The inventory scales to 200,000+ non-human identities by organizing credentials into a queryable graph rather than a flat spreadsheet no one will read.

The Identity Problem Behind Service Account Inventory

Most service accounts and API keys live outside the system that thinks it owns them. Enterprises now run 82 non-human identities per human, and that ratio is growing 300–500% annually among teams shipping agentic AI. The credentials themselves are easy to count inside any single system; the problem is that they don't stay inside that system.

A typical enterprise has service accounts in AWS IAM, GCP IAM, Azure AD, Okta, Salesforce, Workday, GitHub, GitLab, Jenkins, CircleCI, Kubernetes, Splunk, Datadog, and a long tail of bespoke applications, plus API keys in HashiCorp Vault, CyberArk, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, 1Password, Delinea, and .env files no one inventoried at all. Each console shows its own slice. None shows the same key copied from Secrets Manager into a developer's .env.local, mirrored in a forked repo, and consumed by an AI agent running on the developer's laptop.

That's why "we already inventory our service accounts" usually means "we list the rows in AWS IAM." The actual inventory problem is the chain, the same credential, in multiple places, consumed by multiple workloads, reaching multiple resources. A spreadsheet of 47,000 IAM principals isn't an inventory; it's a row count waiting to be turned into a graph.

Static rotation policies and quarterly attestations don't fix this. They only touch credentials the policy already knows about.

Why Traditional Approaches Fall Short

Cloud-native IAM inventories cover one cloud. AWS IAM lists AWS principals. Azure lists Azure service principals. GCP lists service accounts. Each console is accurate within its scope and blind to everything else, the OIDC token a GitHub Actions workflow uses to assume an AWS role doesn't appear in the AWS console as a creation event, and the federated identity that crosses three clouds shows up as three unrelated rows.

Vault-native inventories cover one vault. HashiCorp Vault knows which secrets are stored in HashiCorp Vault. CyberArk knows which credentials live in CyberArk. Neither knows about the long-lived AWS access key sitting in an old .env file in a forgotten repo, or the GitHub personal access token a developer pasted into a CI pipeline two years ago. A vault is just secure storage; an inventory built on the vault inherits the vault's blind spots.

CSPM and SSPM platforms inventory misconfigurations, not identities. They'll tell you an S3 bucket is public or an Okta admin lacks MFA. They won't tell you that svc-ingest-prod-7 hasn't been used in nine months, has access to a production data lake, and is owned by a contractor who left last year. Posture scoring and credential inventory are different problems.

Manual access reviews collapse at scale. Quarterly attestations work when there are 200 service accounts. They fail at 200,000, and they don't even attempt to cover the 3–10 credentials each AI agent consumes. The reviewer can't know whether the row is still needed. The system that knows is the workload, which can't sign an attestation form.

The cumulative result: most enterprises have high confidence in their human directory and almost none in their service account inventory. The fix is not another scan; it's an inventory built around identity, not around any single environment.

What an Effective Service Account Inventory Must Do

An effective service account and API key inventory must do six things.

Cover every system that creates or stores credentials. Cloud IAM, SaaS admin consoles, secret vaults, CI/CD platforms, container orchestrators, on-premises directories, and the AI agent runtimes now spawning their own credentials. An inventory that stops at one perimeter loses every credential that crosses it.

Run continuously. Credentials are created by automation, by developers, by Terraform, by AI agents, every hour of every day. A weekly scan is permanently behind, and the credentials created between scans are the ones that get exfiltrated.

Carry full lineage on every entry. Where the credential came from, every place it's stored, every workload that consumes it, every resource it can reach. A flat list is operationally useless; the graph is what makes the inventory actionable for ownership, deprovisioning, and incident response.

Attribute every credential to a human owner. Workforce attribution turns "we have 200,000 service accounts" into "we have 200,000 service accounts, each owned by a person who can be asked whether it's still needed." Without an owner, governance has no anchor.

Surface credentials that live outside managed systems. The keys that breach companies are the ones outside the vault, in .env files, in Slack messages, in OAuth grants approved by a contractor and forgotten. An inventory limited to managed credentials replicates the vault's blind spots.

Deploy without workload changes. Production fleets can't take a deployment dependency on the inventory tool. Agentless, API-based collection is the only model that scales across an existing estate.

How Clutch Solves It

Clutch connects to every system that creates or consumes service accounts and API keys through native APIs, AWS IAM, AWS Secrets Manager, Azure AD / Entra ID, Azure Key Vault, GCP IAM, GCP Secret Manager, Okta, Auth0, Salesforce, Workday, GitHub, GitLab, Bitbucket, Jenkins, HashiCorp Vault, CyberArk, 1Password, Delinea, Kubernetes, Datadog, Splunk, and 100+ others, and continuously inventories every credential it finds. Collection runs under Zero Knowledge Architecture: only the metadata required to build the inventory leaves the customer environment.

For each entry, Clutch builds an Identity Lineage® record. This is what differentiates an inventory from a row count. A list says 47,000 service accounts. Identity Lineage® says this AWS access key was created by a former employee, lives in AWS Secrets Manager and a .env file in a forked repo, is consumed by two Lambdas and an MCP server running on a developer endpoint, and can reach the customer-data RDS cluster. The same record covers API keys in HashiCorp Vault, OAuth tokens in Salesforce, GitHub fine-grained PATs, Okta service users, and Kubernetes service account tokens, every credential type, in one model.

Workforce Attribution binds every service account and API key to an accountable human owner, the developer who created it, the team that consumes it, the manager responsible for the workload it serves. This is how Clutch closes the "no one's coming to deprovision that service account" loop: every row has a name, and every orphan is an orphan because Workforce Attribution noticed the previous owner left.

The inventory also covers credentials consumed by AI agents. Clutch identifies the 3–10 credentials each agent consumes, Anthropic and OpenAI keys, AWS Bedrock roles, Google Vertex AI service accounts, Azure AI Foundry identities, and the ambient AWS, GCP, or GitHub credentials a developer's MCP server inherits when run from a public registry. An agent without credentials is just a chatbot; Clutch makes the credentials part inventoried.

Deployment is agentless and API-based. Connecting a primary cloud, an IdP, and a vault produces initial inventory within hours; full enterprise coverage across cloud, SaaS, on-prem, and AI runtimes lands within days. The inventory then runs continuously, every new service account, OAuth grant, IAM role, and API key surfaces as it's created, not on a quarterly cycle.

Practical Examples

A CI/CD pipeline minting a long-lived API key. A team adds a Terraform module that provisions an AWS IAM user with programmatic access for a Jenkins job. The key is written to a .env file in a config repo and never rotated. Clutch detects the new IAM principal during continuous discovery, traces its Identity Lineage® across the Terraform state, the repo, and the Jenkins runtime, and surfaces that it has s3:* on a production bucket. Workforce Attribution assigns the credential to the Terraform module's author for review.

An Okta service user with cross-system reach. A platform team creates an Okta service user that federates into AWS, Azure, and GCP for a multi-cloud monitoring tool. Three separate IAM consoles see three rows. Clutch sees one identity with three downstream reaches, inventories the OAuth grants on the Okta side, and produces a single entry with the full graph attached, including which tenant in each cloud the identity can reach and which resources are in scope.

An API key in a SaaS-to-SaaS OAuth grant. A contractor authorizes a third-party analytics tool to read Salesforce data. The tool stores an API key on its backend and uses it to call an AWS Lambda over a federated identity. Clutch inventories the OAuth grant in Salesforce, follows it to the AWS-side identity, maps the chain, and surfaces a single inventoried entity rather than three disconnected records, with the contractor named via Workforce Attribution.

The Bottom Line

Service accounts and API keys outnumber humans 82 to 1, and most are scattered across systems that don't talk to each other. Cloud IAM consoles, vault inventories, CSPM scans, and quarterly access reviews each see a slice, none produces a single inventory tied to owners and reachable resources. Clutch Security inventories every service account and API key continuously through 100+ integrations, attaches Identity Lineage® to every entry, and binds every credential to a human owner through Workforce Attribution. As AI agents drive the next 5–10x in credential growth, the inventory that matters is the one built around identity rather than around any single environment.