Skip to content
Open to board advisory and board seats — 2H 2026, then CY 2027–2028.
See details →
Writing

Your Agents Already Outnumber Your People. Nobody Is Governing Their Credentials.

Your agents already outnumber your people, they can authenticate but not prove they're authorized, and that's the gap SOC 2 and HIPAA were never built to close.

June 19, 2026 7 min read 1,238 words All postsTable of contents

Non-human identity is the control gap your SOC 2 and HIPAA programs were never designed to close. Here is how to build the program that does.

Count the humans with logins in your environment. Now count the service accounts, CI runners, API keys, OAuth integrations, and lately the AI agents acting on someone's behalf. The second number is not close. In its non-human identity governance whitepaper from May 2026, the Cloud Security Alliance put the ratio at roughly 45 to 1, and as high as 144 to 1 in some estimates. You already run a workforce that is overwhelmingly machine. Almost no one is governing it like one.

I want to be precise about the failure mode, because "AI security" gets discussed at a level of abstraction that is useless on a Monday morning. The problem is not that agents are dangerous in some science-fiction sense. The problem is narrow and mechanical: your agents can authenticate, but they cannot prove they are authorized. And every compliance framework you are graded against was written for humans who can.

Authentication is solved. Authorization is the hole.

When a person joins, they get an identity, an entitlement set tied to a role, an approval trail, an offboarding date, and an access review every quarter. Authentication tells the system who is knocking. Authorization tells it what they may do once inside. For humans we built an entire lifecycle around the second question.

Agents skip it. An agent presents a token and the token works. There is no role attached to the agent as a principal, no joiner-mover-leaver process, no quarterly review asking whether this thing should still be able to read the customer table. The credential is the entire identity.

That is why GitGuardian found 1,275,105 AI-related secrets sitting in public GitHub repositories in 2025, up 81 percent year over year. Secrets sprawl is not a hygiene problem you nag developers about. It is the predictable result of treating long-lived credentials as if they were identities, then handing them to software that copies, logs, and forwards them at machine speed.

The blast radius is not theoretical either. There is a widely circulated account of an AI coding agent that deleted a startup's production database, and the volume-level backups along with it, in roughly nine seconds. Whether or not every detail is exact, the shape is right. An over-permissioned non-human principal, a standing credential, and no authorization boundary between "help me" and "destroy everything." A human with that much standing access would have tripped three separate controls. The agent tripped none.

Why your frameworks do not catch this

Pull up your SOC 2 or HIPAA IAM controls and read them as if a machine were the subject. Access provisioning assumes a request and an approver. Periodic access review assumes a reviewer who recognizes the user. Termination assumes a person who leaves. Least privilege assumes a role. An agent that a developer spun up last Tuesday, gave a personal access token, and wired into three internal APIs satisfies the letter of none of these, and breaks the spirit of all of them.

This is the gap regulators are starting to name. The US Treasury published a Financial Services AI Risk Management Framework in February 2026, with 230 control objectives across seven domains. NIST released a preliminary Cyber AI Profile, IR 8596, in December 2025. The EU AI Act deferred its high-risk Annex III obligations to December 2027, but its general-purpose AI enforcement powers still switch on August 2, 2026, with fines up to three percent of global turnover. The direction is unambiguous. You will be asked to demonstrate governance over machine actors, and "we rotate keys sometimes" will not be an answer.

The mechanism is moving. Use it.

The good news is that the identity industry has stopped hand-waving and started shipping the primitives you need. In May 2026 Auth0 released an agent-native stack with the right vocabulary: Agent as Principal, meaning the agent is a first-class identity rather than a borrowed human one; a Token Vault; and general availability of authorization for MCP. The European Identity Conference in June converged on OAuth 2.1 plus OpenID AuthZEN as the pattern. That matters because AuthZEN externalizes the authorization decision into a policy decision point you can audit, instead of burying it in application code. Cloudflare shipped scannable API tokens in April with automatic revocation and resource-scoped RBAC, so a leaked token can be detected in a public repo and killed before it is used.

Notice what these have in common. They separate the question of who you are from the question of what you may do right now, and they shorten the lifetime of the answer.

A non-human identity program you can start this quarter

Here is the program I would stand up, in the order I would do it. None of it requires waiting for a vendor.

First, build an agent identity registry. Every non-human principal gets a record: a unique identity, a human owner, the systems it may touch, the data classifications it may see, and an expiry. If it is not in the registry, it does not get a credential. This is your machine equivalent of an HR roster, and it is the single highest-leverage item on this list, because you cannot govern what you have not enumerated.

Second, kill standing credentials with just-in-time, scoped issuance. An agent should request access for a task and receive a credential minted for that task, that resource, and that window. The default posture flips from "the agent holds a key" to "the agent asks for permission and gets a narrow grant." This is where Agent-as-Principal and AuthZEN-style policy decisions earn their keep.

Third, vault the tokens. Agents should never see raw long-lived secrets. They reference a vault that injects short-lived material at call time. The vault becomes your chokepoint for rotation, revocation, and logging, instead of secrets being smeared across config files and prompt history.

Fourth, make tokens short-lived, with revocation measured in minutes, not days. This is the control that bounds the nine-second database deletion. If the worst-case credential lifetime is fifteen minutes and you can revoke on signal, a leaked or hijacked agent token is a contained incident rather than a standing liability. Scannable tokens with auto-revocation make the detection-to-kill loop close on its own.

Fifth, audit per agent, not per service account. Every action should be attributable to a specific agent identity, its owner, and the grant it was operating under. OWASP mapped prompt injection to six of its ten agentic-AI Top 10 categories in June 2026. When injection turns one of these agents against you, your only forensic hope is a log that says which principal did what, under which authorization.

The takeaway

Treat your agents as a workforce, because that is what they are. Give them identities, owners, scoped and expiring credentials, a vault, and an audit trail tied to the principal. Do that and most of the scary AI-agent incident reports become ordinary, contained access-control events. Skip it and you are running the largest unmanaged workforce in your company with the loosest access controls you own.

I would start with the registry. You cannot govern what you have not counted, and right now most of us have not counted.

If you have stood up scoped, short-lived credentialing for agents in a regulated environment, I want to hear where it broke first. That is the part the whitepapers leave out.

AINon-Human IdentityIAMCloud Security