Which human is accountable for this API key?
Most companies cannot answer that for most of their machine identities. HumanAudit connects read-only, finds every service account, OAuth application, token and AI agent in your estate, and names the human accountable for each one — or shows you there is none.
Interface concept. Figures are illustrative, not a real customer environment, and some sources shown are connectors still on our roadmap.
The identities nobody offboards
“The one service token and three accounts were not rotated because mistakenly it was believed they were unused. This was incorrect.”
Cloudflare, official incident post-mortem, 1 February 2024. Written while remediating a credential leak the team already knew about. The remediation that followed rotated more than 5,000 credentials and triaged 4,893 systems.
This is not a story about a careless company. It is a story about one of the strongest security organisations on the internet being unable to tell which of its machine credentials were still alive.
Every organisation accumulates them the same way. An engineer wires up an integration to solve a problem on a Tuesday. It works. The engineer moves teams, then leaves. The integration keeps authenticating. There is no leaving date on a service account, no manager to sign its access review, and nothing anywhere in the stack that connects the person to the credential they created.
Multiply by four years and a few hundred SaaS integrations.
Six layers, none of which answer the ownership question
We are not claiming these tools are deficient. Each answers its own question well. The point is that none of them was built to answer this one.
| Layer you already own | The question it answers | Where it stops |
|---|---|---|
| Okta, Microsoft Entra — IAM | May this principal access that resource? | Built around a human lifecycle: hire, move, leave. A service account has none of those events, so nothing triggers a review when its creator resigns. |
| CyberArk, Delinea, BeyondTrust — PAM | How do we control the most dangerous accounts? | Vaulting and session recording assume an interactive session. Most machine identities never log in interactively. |
| HashiCorp Vault, Akeyless — secrets | Where is this credential stored? | Knows the secret exists. Does not know who owns the identity behind it, what it can reach, or whether anything has used it since 2023. |
| SailPoint, Saviynt — IGA | Can we prove access was reviewed and approved? | Certification campaigns assume a human reviewer on a quarterly cadence, and they attest to access rather than to ownership. |
| Wiz, Orca — CNAPP | Is the cloud estate misconfigured or exposed? | Infrastructure-centric. A third-party OAuth grant into your Google Workspace tenant is not in a cloud account and is not visible to a cloud scanner. |
| AWS, GCP and Azure workload identity | Which workload is this, cryptographically? | Free, excellent, and the right answer for infrastructure-to-infrastructure. It does not apply at all when the trust anchor is a third party's cloud. |
Read down the final column. The gap is consistent: nine of the categories that make up a modern identity stack stop before the question “prove what this identity did, and on whose human authority.”
Two things changed, eighteen months apart
Every product built for this was acquired
Astrix went to Cisco. Oasis Security to Cyera. Entro to SailPoint. Natoma to Snowflake. Permiso to Okta. SGNL to CrowdStrike. Veza to ServiceNow. CyberArk, which owns Venafi, went to Palo Alto Networks.
Astrix's own website now states that it ended standalone sales of new licences on 30 June 2026.
The platforms that bought them sell from roughly $50,000 a year upward, to the Fortune 500 CISO, through channel partners. A 600-person company is not a customer any of them are trying to reach.
The credential was never the problem
In every documented AI-agent security incident of 2025 and 2026 — EchoLeak, CamoLeak, ForcedLeak, ShadowLeak — the credential involved was correctly issued, correctly scoped and correctly authenticated.
Identity was working exactly as designed. What failed was the ability to say, afterwards, on whose authority the action was taken and who was answerable for it.
Agents did not create this problem. They industrialised it, at machine speed, in an estate nobody had inventoried.
Connect, discover, attribute, prove
Connect, read-only
One OAuth consent per source. Google Workspace, Microsoft 365, GitHub and Slack today. Narrowest scopes that return the data, published in advance, revocable in one click. Nothing is installed and nothing can be written.
Discover every non-human principal
Third-party application grants, service accounts, personal access tokens, workflow and pipeline identities, bot users, and the agent identities that inherit from them. With the scopes each one holds and, where the source exposes it, when it was last used.
Attribute to a human
Resolve who created or authorised each identity, whether that person is still with the company, and who inherited responsibility if they are not. Where no answer exists, the record says so explicitly rather than leaving the field blank.
Prove it later
A dated, scoped, exportable record mapped to the specific controls that touch non-human accounts. Attestations are timestamped and kept, so the question “who owned this in March?” has an answer in September.
What the output actually looks like
Not a dashboard. A record, with a column that most organisations discover is mostly empty.
Unowned
No human can be resolved as responsible. The most common finding, and the one that makes the rest of the programme impossible.
Orphaned
The person who created or authorised the identity has left the organisation, and nobody inherited it.
Over-scoped and idle
Holding permissions it has never exercised, or not used at all for longer than your own policy allows.
What exists today, and what does not
HumanAudit is early. We would rather you know exactly what you are getting than discover it on a call.
| Capability | Status | Detail |
|---|---|---|
| Guided exposure scan | Available now | Run as a guided session with design partners. You connect read-only, we walk the findings with you, you keep the report either way. |
| Control-mapped report | Available now | Findings mapped to PCI DSS 8.6, CIS 5.5, ISO 27001 A.5.16 and SOC 2 CC6, with the scope limits stated. |
| Google Workspace, Microsoft 365, GitHub, Slack | Available now | Read-only connectors. Scopes published on the security page. |
| Self-serve scan without a call | Roadmap | The guided session is deliberate at this stage — it is how we learn what the report is missing. |
| Continuous monitoring and change alerts | Roadmap | Alerting on a new grant, an escalated scope, or an owner who has left. |
| Owner attestation workflow | Roadmap | A named human confirms ownership; the confirmation is timestamped and retained. |
| Salesforce, Okta, Entra, cloud IAM, CI/CD, MCP server discovery | Roadmap | Ordered by what design partners ask for, not by what demos well. |
| Write actions and automated remediation | Not planned near-term | We do not want write access to your identity provider, and you should not want to give it to an early-stage vendor. |
| SOC 2, ISO 27001 certification | Not yet held | SOC 2 Type I is planned before general availability. We will not claim it before we hold it. |
We publish the evidence, including the parts that undercut us
Most vendors in this space cite a machine-to-human identity ratio. Six of them published numbers between 17:1 and 144:1 in the same twelve months, every figure self-published by a company selling machine-identity software. We do not use that statistic, and our research explains why.
Control reference
PCI DSS 8.6, CIS 5.5, ISO 27001 A.5.16 and SOC 2 CC6 with verbatim text and the scope conditions that determine whether they apply to you at all.
Read the referenceIncident library
Documented breaches in which a non-human identity was the mechanism. Identity type, root cause, and what would actually have prevented it — including the cases where the answer is a free cloud feature.
Read the libraryWhat counts as an NHI
A working taxonomy: what qualifies, what does not, and how non-human identity overlaps with IAM, PAM, secrets management, IGA and workload identity.
Read the definitionWe also publish independent research at NHI Governance. HumanAudit owns that publication and we say so on it — it is our research, not a third-party endorsement of us.
An honest account of the company
HumanAudit Inc. is a Delaware C-Corporation founded in 2026 by Akshay Dubey. Before this product, the company built and sold an ISO/IEC 42001 implementation toolkit, which has earned $5,426 from five customers, acquired organically with no paid marketing.
That is a small number and we are not going to dress it up as traction for this product. What it demonstrates is narrower and still relevant: that this team can identify a specific compliance and security problem, build something people will pay for, and reach buyers without a marketing budget.
We have no enterprise logos to show you, because we have not earned any yet. When we do, they will appear here with permission and not before.
What we will never put on this site
- Customer logos we do not have permission to use
- Certifications we do not hold
- Analyst recognition we have not received
- Integrations we have not built
- Statistics we cannot source and date
- A machine-to-human identity ratio
Frequently asked
What is a non-human identity?
A non-human identity is any credentialed principal that can authenticate to a system without a human present at the moment of authentication. That includes service accounts, API keys, OAuth applications and their grants, certificates, SSH keys, cloud workload identities, Kubernetes service accounts, CI/CD pipeline identities and AI agent identities.
The boundary matters because it is precisely the point at which your existing controls stop working. Multi-factor authentication, session timeouts, joiner-mover-leaver processes and the manager who signs the quarterly access review are all built around a human being present. None of them fire for a service account.
How is this different from what Okta or Microsoft Entra already do?
Identity providers answer whether a principal may access a resource. They are built around a human employment lifecycle, and a machine identity has no hire date, no manager and no leaving date. When the engineer who created a service account resigns, nothing in your IAM system connects those two facts.
HumanAudit answers a different question: which human is answerable for what this identity did. That is an accountability record, not an access control plane, and it sits above whichever identity providers you already run.
Do we need to have AI agents deployed for this to be useful?
No, and that is a deliberate design decision. Independent estimates suggest only a small minority of large enterprises currently run genuinely autonomous, credentialed agents in production. But essentially every company already has third-party OAuth applications connected to its Google Workspace, Microsoft 365, Salesforce, GitHub and Slack tenants, accumulated over years and rarely reviewed.
That installed base is where the scan starts. Agent identities are the same problem arriving faster.
What access does the scan require?
Read-only OAuth scopes, and nothing else. There is no agent to install, no network access required, no write permissions requested and no ability for HumanAudit to change anything in your environment. The exact scopes requested for each connector are published on the security page before you connect anything.
Is HumanAudit a compliance product?
It produces evidence a compliance programme can use, and it is not sold as compliance software. The findings are mapped to the specific controls that touch non-human accounts — PCI DSS 4.0.1 requirement 8.6, CIS Controls v8.1 safeguard 5.5, ISO/IEC 27001:2022 Annex A 5.16 and the SOC 2 CC6 series — because auditors ask for that mapping and producing it by hand is miserable.
We are also straightforward about the limits of those controls. Our control reference sets out where PCI 8.6 does and does not apply, including the scope conditions most vendors leave out.
Who is HumanAudit for?
Cloud-native organisations of roughly 200 to 3,000 people, with a meaningful number of SaaS integrations and a security or platform team small enough that nobody has time to maintain an identity inventory by hand. The person who typically brings us in owns a rollout — of AI tooling, or of a new SaaS estate — and has been asked a question they could not answer.
See the list before someone else finds it
A guided read-only session, about twenty minutes. You get the full report whether or not you ever become a customer, and we will tell you honestly if your existing tooling already covers what we find.