Machine identities now outnumber human identities 109 to 1 inside the average enterprise, and AI agents are the reason the ratio has nearly doubled in a single year. That number is worth sitting with: for every engineer who logs into a system, more than a hundred non-human identities — service accounts, API keys, workload certificates, and now autonomous agents — are also making requests and reading data on that system’s behalf.
Most identity and access management architecture was never built for this. IAM, as a discipline, grew up around a simple assumption: a human sits down, proves who they are, and does something. Multi-factor authentication, session timeouts, role-based access reviews, even the concept of “logging in” — all of it assumes a person with a face, a manager, and an offboarding date. Non-human identity breaks that assumption in ways static service accounts and API keys already strained, and that autonomous AI agents are now pulling apart entirely.
This isn’t a theoretical concern. Nine out of ten organisations reported a successful identity-related breach in the past twelve months, and 96% report that identities in their environment operate with access far beyond what their function requires. Meanwhile, OWASP shipped its first-ever Non-Human Identities Top 10, a sign that the security community now treats this as a distinct discipline rather than a subset of ordinary access management. This article walks through five specific gaps where IAM architecture assumes a human is on the other end of the request, what breaks when an autonomous agent is on the other end instead, and what engineering teams can do about each one.
What “Non-Human Identity” Means Once Agents Enter the Picture
From service accounts to autonomous actors
Non-human identity isn’t a new category invented for the AI era. Service accounts, API keys, CI/CD credentials, and workload certificates have existed as long as systems have talked to other systems without a person typing a password. What’s new is the behaviour attached to the identity. A traditional service account does one narrow thing: a backup job authenticates, copies files, and disconnects. Its blast radius is small because its job is small.
An AI agent authenticating with a non-human identity is a different animal. It might read a customer record, decide to call three other internal APIs based on what it finds, draft an email, and queue a database update — all within a single credential’s lifetime, with no human reviewing each step. The identity is non-human in the same technical sense as a service account, but the decision-making behind each request is not deterministic, which is precisely what IAM systems built around fixed, predictable access patterns don’t handle well.
Why agentic NHI is a distinct risk category
A growing share of machine identities in the average enterprise are now AI agents rather than static service accounts, and that composition shift is what security teams mean by an “agentic non-human identity” problem specifically. A static service account with a narrow scope is easy to reason about: it does the same thing every time. An agent’s scope is defined by a goal, not a function, and the path it takes to reach that goal can vary from one run to the next.
This matters for IAM because access control has traditionally been designed around predictable, enumerable actions. When the identity making the request might do any of a hundred different things depending on context the system can’t fully see in advance, “what should this identity be allowed to do” becomes a much harder question than it was for a backup job or a cron script. That harder question is the thread running through each of the five gaps below.
Gap 1 — Standing Credentials in a World of Dynamic Actors
Long-lived secrets and the OWASP NHI7 problem
The default way most systems authenticate a non-human identity is still a long-lived secret: an API key generated once, dropped into a config file or environment variable, and left to work until someone remembers to rotate it. OWASP calls this out directly as NHI7 — Long-Lived Secrets — and flags it as one of the most exploitable risks in the entire non-human identity category, precisely because a breached secret with no expiration gives an attacker indefinite access rather than a narrow window.
AI agents make this worse in a very specific way, compounding a non-human identity growth problem that most secret-management practices haven’t caught up with. GitGuardian’s State of Secrets Sprawl 2026 report found 28.65 million new hardcoded secrets added to public GitHub in 2025 alone, and secrets tied specifically to AI services grew 81% year over year to 1.27 million — eight of the ten fastest-growing categories of leaked credential were AI-related.
The same report found 24,008 unique secrets exposed in MCP-related configuration files across public repositories, of which 2,117 were still valid. Part of the problem, the report notes, is that popular setup guides for agent tooling often recommend pasting API keys directly into config files or command-line arguments — insecure patterns get normalised in the same tutorials developers use to get an agent running for the first time.
What ephemeral, workload-based credentials look like
For non-human identity, the fix mature engineering teams are converging on isn’t better secret storage — it’s removing the standing secret entirely. Instead of an agent holding a long-lived API key, the workload proves its identity cryptographically at the moment it needs access and gets a short-lived credential scoped to that single transaction, expiring automatically. This is the model behind SPIFFE and SPIRE, the CNCF-graduated open standard and reference implementation for workload identity: a workload requests a SPIFFE Verifiable Identity Document and presents it to whatever it’s talking to, valid for minutes, not months.
For a non-human identity that only ever does one predictable thing, this can feel like overhead. For an autonomous agent making dozens of API calls across a session, it’s the difference between a single leaked credential exposing a narrow window of access and that same leak exposing months of standing privilege. Rotation stops being a manual chore that gets skipped under deadline pressure and becomes a property of the architecture instead.
Gap 2 — Delegation Without a Verifiable Chain of Custody
The “acting on behalf of” problem
Most AI agents deployed in production today don’t have their own independent non-human identity in any meaningful governance sense — they borrow a human’s or a service’s credentials and act “on behalf of” that identity. This delegation model creates a question that traditional IAM was never built to answer cleanly: when an agent takes an action, is it acting with the full authority of the identity it borrowed, or with some narrower, task-specific subset of that authority — and can the system prove which one, after the fact?
Without a verifiable answer, incident response degrades fast. If an agent with delegated access does something harmful, the audit log shows the human’s or service’s identity, not a distinguishable record of what the agent was actually permitted to do at that moment. That’s not hypothetical — it’s the exact mechanism behind several recent breaches where a trusted OAuth grant became the pivot point for attackers to move well beyond what the integration was meant to touch — the kind of non-human identity blast-radius problem security teams are only now learning to measure.
How SPIFFE, SPIRE, and workload identity standards close it
The direction the industry is moving is toward giving every workload — including every agent — its own cryptographically verifiable identity, with delegation expressed explicitly rather than inherited implicitly. SPIFFE’s federation model lets separate SPIRE deployments exchange trust bundles so that a chain of custody can be verified across service boundaries, not just within one team’s infrastructure. Applied to agents, the practical question engineering teams are starting to design for is precise: how does an agent prove it’s acting on a specific user’s behalf, with a specific scoped permission, for a specific and limited window of time — and how does that proof travel with the request as it passes through multiple services?
The same discipline applies whether the actor is an AI agent or a conventional CI/CD pipeline: a pipeline deploying to production needs to carry evidence of who triggered the deploy, just as an agent needs to carry evidence of who it’s acting for. The non-human identity problem is structurally the same even though the actor looks different — a point worth keeping in mind when a recent overview of how AI agents are changing software delivery pipelines discusses agent credentials and least-privilege access as table-stakes requirements rather than nice-to-haves.
Gap 3 — Authorization Built for Logins, Not Tool Calls
Why static OAuth scopes weren’t designed for autonomous tool use
OAuth has been the default authorization framework for delegated access for close to two decades, designed around one interaction: a user grants an application a fixed scope, once, at a consent screen, and that scope rarely changes for the life of the token. That model maps reasonably well to a human authorizing a calendar app to read their events. It maps far less cleanly to a non-human identity like an autonomous agent, which might need to call a dozen different tools across a session, each with a different, narrower scope, decided dynamically based on what the task requires.
Static, broad scopes granted once are exactly the pattern that turns a single compromised agent integration into a wide-reaching breach, because the token the agent holds is typically authorized for far more than any single tool call actually needs. Verizon’s 2026 Data Breach Investigations Report found the human element present in 62% of breaches and credential abuse remaining the single most pervasive technique across full breach chains at 39% — figures that predate most agentic AI deployment at scale, which suggests the credential and authorization problems agents are inheriting were already serious before agents made them worse.
What MCP’s 2026 authorization hardening signals
The Model Context Protocol — the emerging standard for connecting AI agents to external tools — has moved through several rounds of authorization hardening because early implementations treated authorization as an afterthought. The November 2025 revision formalised OAuth 2.1 as the baseline for remote MCP servers, and the 2026-07-28 release candidate goes further: clients must validate the issuer parameter on authorization responses per RFC 9207 to prevent a mix-up attack more prevalent in MCP’s single-client, many-server pattern, and must implement Resource Indicators per RFC 8707 so a token requested for one MCP server can’t be replayed against a different one .
That specificity reflects lessons learned from real exposure, not theoretical hardening. Authorization for a non-human identity calling tools needs to express “this token is valid for this server, this operation, this window” — considerably narrower than what a browser-based consent screen grants a human-facing application. Engineering teams building agent tooling should treat scoped, resource-bound tokens as baseline, the same way MCP support itself became baseline for agent platforms over the past year.
Gap 4 — Secrets Sprawl and Governance That Can’t Keep Up
Why agents leak credentials differently than developers do
Developers have always occasionally committed a secret to a repository by mistake. Agents introduce a different failure pattern: local coding assistants now have deep access to terminals, files, editors, and environment variables, so the developer’s workstation itself becomes a more meaningful non-human identity attack surface. GitGuardian’s analysis of the Shai-Hulud supply chain attack found 294,842 secret occurrences across 6,943 compromised machines, and 59% of those machines were CI/CD runners rather than personal laptops — the exposure wasn’t confined to individual error but extended into automated infrastructure.
The same report found internal repositories were roughly six times more likely than public ones to contain hardcoded secrets, and that 64% of secrets confirmed valid in 2022 were still valid when retested in early 2026. That persistence is the real non-human identity governance failure: it’s not that secrets leak — some leakage is close to inevitable at scale — it’s that most leaked secrets are never rotated even after they’re known to be exposed, turning a detection problem into a remediation backlog.
Discovery, ownership, and offboarding for non-human identity
Most organisations are still in a basic discovery phase when it comes to non-human identity: before you can govern something, you have to know it exists, who owns it, and what it can access. OWASP’s Top 10 lists Improper Offboarding as the single most exploitable non-human identity risk category, ahead even of secret leakage — unmonitored, deprecated service accounts and forgotten agent integrations remain live and privileged long after the project or person that created them has moved on.
This is the same discovery problem that continuous cloud security posture management exists to solve for misconfigured infrastructure — non-human identity just extends the same “you can’t secure what you can’t see” logic to every credential an agent might be holding.
A workable governance programme starts with three questions applied consistently across every non-human identity in the environment: what exists, who owns it, and what can it access. Answering those questions for agents specifically means treating agent credentials with the same lifecycle rigour as human credentials — provisioned for a defined purpose, reviewed on a schedule, and deprovisioned automatically when the agent, integration, or project that created them is retired. Teams that have already built this discipline into their DevSecOps pipeline as a control system that governs how software moves from code to runtime tend to find that extending the same enforcement model to agent identities is a natural next step rather than a separate initiative.
Building an IAM Architecture That Assumes Non-Human Actors
Practical steps for engineering teams this quarter
None of the five gaps above require rebuilding an organisation’s entire identity stack. A few concrete, sequenced steps matter more than any single tool purchase. First, inventory before you enforce: catalogue every non-human identity active in the environment, including every agent integration, and assign a named owner to each. Second, replace standing secrets with short-lived, workload-issued credentials wherever an agent authenticates with a static key, starting with the highest-privilege integrations. Third, scope every token to the narrowest operation it needs, and treat resource-bound, expiring tokens as non-negotiable when evaluating any agent framework or MCP-compatible tool.
Fourth, wire rotation and offboarding into the same automated pipeline that provisions the identity, so deprovisioning isn’t a manual step someone forgets months later. Fifth, build the audit trail before you need it: every delegated action an agent takes should trace back to a specific, scoped, time-bound authorization rather than a shared credential’s logs reconstructed after an incident. Teams that have already built an SBOM readiness plan for supply chain compliance will recognise the pattern — visibility has to exist before an incident forces you to build it under pressure.
Where this fits into zero trust and DevSecOps
None of this is a new philosophy so much as an extension of one most security teams already claim to follow. Zero trust architecture is built on the premise that identity is the new perimeter and that no request should be trusted by default regardless of where it originates — a principle that applies with more force once a meaningful share of the requests hitting your systems come from autonomous agents rather than people. Non-human identity governance is what that principle looks like once you stop treating “identity” as something only humans have.
The organisations that handle this transition well will be the ones that treat non-human identity as a first-class engineering discipline now, while the ratio is 109 to 1 and climbing, rather than waiting until it’s the subject of a post-incident review. The tooling and the standards already exist. What most environments are still missing is the inventory, the ownership, and the discipline to enforce them.
If your team is evaluating how AI agents fit into your identity and access management architecture, or needs help building a non-human identity governance programme from the ground up, contact us.
