AI agents that interact with calendars, databases, or support ticketing systems do so using credentials such as API keys, service accounts, OAuth tokens, or certificates. Security teams refer to these as non-human identities (NHIs), which have become the largest identity population within most enterprises. Recent industry research indicates that the ratio of machine identities to human employees is often in the double or triple digits, with AI agents representing the fastest-growing segment. Unlike static scripts that execute repetitive queries, agents plan, select tools, and adapt during tasks. Consequently, their credentials must function more like scoped, revocable badges than shared passwords.

Traditional service accounts are predictable: they are created for a specific task, authenticate consistently, and are typically reviewed annually during access audits. In contrast, AI agents disrupt this model. They may invoke multiple tools within a single task, request data from systems not previously designated, and delegate work to sub-agents that inherit the parent’s permissions. Security researchers now characterize agents as an “aggregation point” for non-human identities. When an agent operates, it does so with the combined authority of all assigned keys, tokens, and service accounts, regardless of whether the current task requires such broad access.

This aggregation represents the central challenge. An overprivileged agent credential poses risks beyond a single erroneous API call; it exposes all resources accessible by any credential the agent possesses. Traditional identity and access management systems were designed for predictable workloads and periodic human review. Agents undermine both assumptions, prompting a shift in non-human identity governance from a compliance formality to a critical engineering concern.

Recent industry reports have highlighted the magnitude of this security gap. Numerous machine credentials are discovered in public code repositories annually, and a significant proportion of older leaked keys remain valid long after their exposure. Verizon’s latest data breach research specifically identifies service and machine accounts as the credentials most susceptible to exploitation as agentic AI adoption increases. These accounts often possess elevated permissions, seldom require multi-factor authentication, and are frequently over-provisioned relative to their actual usage.

The OWASP GenAI Security Project’s Top 10 for Agentic Applications makes the same point from a different angle. Several of its highest-severity risk categories, including identity and privilege abuse, agentic supply chain vulnerabilities, and insecure inter-agent communication, trace back to the same root cause: agents do not have verifiable, scoped identities that other systems can check at the moment of action. When an agent’s credential is a shared secret rather than a certificate tied to a specific task and expiration window, there is no reliable way to confirm that only the intended agent used it, or that it was not silently passed to a sub-agent with broader access than the job required.

The fix is not exotic, and most of it borrows directly from established machine-identity practice rather than inventing something new. Security teams working on this today converge on a similar set of controls. Scope every agent identity to the narrowest set of permissions its current workflow requires, rather than reusing a broad service account across many jobs. Issue short-lived, automatically rotated credentials instead of long-lived API keys that sit valid for months or years. Keep an action-level audit trail that records which identity performed which step, so an incident can be traced back to a specific credential rather than a generic “the agent did it.” And treat agent-to-agent communication as untrusted until it is authenticated, since unsigned messages between agents are one of the easier ways a compromised or rogue agent slips into a workflow unnoticed.

Standards work is catching up to the problem too. Engineers from major cloud and identity vendors have been drafting protocols that compose existing building blocks- workload identity frameworks, workload-to-workload authentication, and OAuth-based delegated authorization- into a coherent model built specifically for agents rather than adapted after the fact from human single sign-on.

None of this requires waiting for a perfect industry standard to arrive. Enterprises that are handling agent identity well today are doing three unglamorous things: they know exactly which credentials each agent holds, they have set an expiration on nearly all of them, and they can revoke any single one without taking down an unrelated workflow. That last test is the simplest way to know whether an organization’s agent identity program is real or theoretical. If a security team cannot, in minutes, answer what a given agent can access and how quickly that access can be cut off, the agent is running on borrowed trust rather than a governed identity.

Researched and written by: Peter Jonathan Wilcheck