Your AI Agents Have Logins Nobody Owns: The Non-Human Identity Problem

The most consequential change in how software works over the past year is not that AI got smarter, it is that AI started acting. Coding agents like Claude Code, Cursor and Devin no longer just suggest text, they read repositories, run commands and open pull requests. Agents built on frontier models now query databases, call payment APIs, file support tickets and trigger deployments. Every one of those actions requires a credential, an API key or a token or a service account that tells the target system this actor is allowed to do this thing. And here is the uncomfortable truth most teams have not confronted: nobody is keeping a list. A 2026 study from the Cloud Security Alliance and Oasis Security found that 78 percent of organisations have no formal policy for creating or removing AI agent identities at all. The agents are multiplying, the keys are being minted, and the governance is simply absent.

To see why this matters, you have to understand how an AI agent differs from the service accounts that security teams have managed for decades. A traditional service account is static and predictable: it does one job, touches a known set of systems, and its permissions do not change unless a human changes them. An AI agent is the opposite. It is an autonomous actor that acquires permissions dynamically at runtime, spawns sub-agents to handle parts of a task, invokes external APIs it decides it needs, writes and executes its own code, and chains together actions that can span dozens of systems in a single run. That autonomy is exactly what makes agents useful, but it also means the blast radius of one compromised credential is far larger than anything a static account could reach. When an agent key leaks, the attacker does not inherit one narrow permission, they inherit an actor that can decide what to do next.

The scale of the exposure is already alarming, and it is growing faster than the tooling meant to contain it. The population of non-human identities across the industry grew 44 percent between 2024 and 2025, driven almost entirely by AI adoption. In 2025 alone, 28.65 million hardcoded secrets were pushed to public GitHub repositories, and AI-related secrets accounted for more than 1.27 million of them, an 81 percent jump year over year. Worse, 91.6 percent of those secrets were still valid five days after the affected organisation was notified, which tells you the problem is not only that keys leak, it is that almost nobody rotates them in time. Against that backdrop, only 15 percent of organisations say they feel highly confident in their ability to prevent an attack that rides in on a non-human identity. The gap between how fast agents are being deployed and how well their credentials are governed is the security story of the year.

This is where the security and compliance frameworks a serious company already runs become the tool for the job, rather than a separate burden. The access-control requirements at the heart of SOC 2 and ISO 27001 were written for human and machine accounts, and they translate directly to agents: least privilege, unique identity per actor, regular access reviews, and prompt deprovisioning when an account is no longer needed. PCI DSS and HIPAA reach agent access indirectly, through their demands on how systems that touch card data or health records control who and what can read them. The point founders miss is that an AI agent with a key to a production database is inside the scope of controls they have already committed to, whether or not they have thought of the agent that way. An access review that ignores every non-human identity is not a complete access review.

Two frameworks speak to agent governance most directly, and both belong in the conversation. NIST AI RMF, the voluntary risk management framework, and ISO 42001, the certifiable AI management system standard, are the two that address autonomous AI behaviour head on rather than by inference. ISO 42001 in particular asks the questions that map cleanly onto the agent identity problem: which AI systems do you operate, what can each of them do, what data flows to them, and who is accountable for each one. A company operating a genuine AI management system is already required to maintain the inventory that answers where do my agents get their permissions, which is precisely the inventory the Cloud Security Alliance found most organisations lack. Governance of agent identities is not a new discipline bolted onto AI, it is what an AI management system is supposed to produce.

The regulatory clock adds urgency that a founder cannot wave away. The EU AI Act imposes transparency, human oversight and logging duties that apply squarely to agentic systems, and the Article 50 transparency obligations take effect on 2 August 2026, with the heavier high-risk obligations under Annex III arriving on 2 December 2027 after the Digital Omnibus deferral. Logging is the requirement that ties this back to identity: to satisfy an oversight or logging duty for an agent, you have to be able to reconstruct what it did, which is impossible if you do not know which identity acted. The best practice emerging across the security industry is to capture the full chain for every agent action in an immutable log: the triggering event, the delegating identity, the policy that was evaluated, the tool that was invoked, the data that was accessed, and the outcome. That record is at once a security control, a compliance artefact, and the only way to answer the question of what happened after an incident.

The compliance automation vendors have read the same signals and are moving to meet them. Vanta shipped what it calls an Agentic Trust Platform in late 2025 and has been extending its tooling toward AI and non-human identity as its customer base has grown past 16,000, while Drata, Secureframe, Sprinto and Thoropass have added ISO 42001 support and framework coverage for the newer regimes that touch machine identity. The practical value of these platforms here is the same cross-mapping that makes them useful elsewhere: an access-review control you already implement and evidence for SOC 2 can be pointed at your agent credentials with modest extension rather than a fresh program, and the platform can help you keep the inventory current instead of letting it drift the moment you stop looking. The tooling will not discover an agent you never told it about, but it lowers the cost of governing the ones you do.

The near-term move for any founder shipping agents is unglamorous and entirely doable: find every agent credential in your environment, understand what each one can actually do, and make sure a named person owns it. From there the discipline is familiar security hygiene applied to a new class of actor, scope each agent to least privilege rather than the broad keys teams hand out for convenience, prefer short-lived credentials over long-lived secrets that sit valid for months, rotate anything that has leaked immediately rather than in five days, and log every action in a form you could hand to an auditor or an incident responder. If you already run an ISO 27001 information security management system or carry SOC 2, none of this is a new project, it is your existing access-control and change-management controls extended to cover the agents you have quietly put to work. The companies that get ahead of this will treat their AI agents as the powerful, permissioned actors they are, and the ones that do not will discover, the hard way, that a login nobody owns is a login nobody is watching.