By Victor Hernandez Guzman

The Explosion of Autonomous Software

The Non-Human Identity (NHI) Reality in the Cloud Era

Over the last decade, enterprise cloud transformations have shifted the center of gravity in Identity and Access Management (IAM). For decades, enterprise IAM centered on the human lifecycle: onboarding employees, provisioning SAML/OIDC single sign-on, and enforcing MFA. Today, that operational center of gravity has shifted entirely to non-human identities (NHIs).

In modern multi-cloud infrastructure and hyperscale microservice deployments, machine identities routinely outnumber human users by orders of magnitude. Ratios of 100:1 are common, with dense containerized and serverless environments pushing even higher non-human identities for every single human user. 

To govern this machine population, enterprise IAM established a mature set of workload identity patterns:

• Service Principals & API Keys: Dedicated non-person accounts tied to specific applications or OAuth 2.0 client credential grants.
• Workload Identity Federation: Short-lived cryptographic tokens bound to cloud infrastructure (e.g., cloud-provider workload identities, platform-managed service accounts, or SPIFFE/SPIRE SVIDs) to eliminate hardcoded secrets. 
• Static Access Policies: Coarse-grained Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC) scoped to predictable, deterministic workload boundaries.

For traditional software, where execution paths are pre-compiled, predictable, and deterministic, these NHI paradigms work effectively. A microservice processing payment transactions follows a known code path, calls a predefined set of internal APIs, and requires static, predictable permissions.

However, the rapid integration of Generative AI and multi-agent orchestration frameworks has introduced an entirely new class of software actor, one that breaks the fundamental security assumptions of traditional NHI.

The Agentic Paradigm Shift: Deterministic Code vs. Autonomous Action

The critical distinction between a standard non-human identity and an autonomous AI agent lies in the shift from fixed program logic to dynamic reasoning and action.

Unlike a traditional microservice or background batch job, an AI agent operates with agency:

1. Dynamic Tool Selection: Rather than executing a hardcoded sequence of API calls, an agent evaluates natural language inputs or intermediate outputs to dynamically choose which external tools, APIs, or databases to invoke at runtime.
2. Context-Driven Workflow Execution: An agent can chain multi-step workflows, autonomously passing data and sub-tasks to downstream tools, plugins, or secondary agents.
3. Non-Deterministic State: Because the agent’s execution path depends on probabilistic LLM outputs, its runtime behavior cannot be fully modeled or predicted prior to execution.

When software transitions from executing deterministic logic to taking autonomous action across enterprise boundary lines, the central security question fundamental to IAM changes. It is no longer enough to ask, “Is this microservice authenticated?” We must instead ask: Who or what is acting, under whose delegated authority, from which execution environment, with what dynamic scope, and backed by what immutable evidence?

The Identity Misalignment: Why Treating Agents as Workloads Fails

When enterprise teams begin deploying generative AI tools, the path of least resistance is almost universally to assign the agent a traditional workload identity, a standard service principal, a static OAuth client ID, or a long-lived API key.

Treating an autonomous agent as “just another microservice” creates severe structural vulnerabilities at the IAM layer:

1. Scope Escalation Mid-Session

A microservice’s permission scope remains constant throughout its execution. In contrast, an agent’s authorization requirements fluctuate dynamically as its task unfolds. If an agent is provisioned with a static, over-privileged permission set to cover all possible tools it might need, a single malicious or mis-prompted output can result in unauthorized data access or catastrophic operational actions (e.g., wiping a database, modifying user roles, or making unauthorized financial transfers).

2. The Confused Deputy & Credential Inheritance Problem

When an agent acts on behalf of a human user, standard implementations frequently fall into one of two dangerous extremes:

• Full Credential Inheritance: The agent inherits the human user’s full authorization context, allowing it to perform any action the user can do, completely bypassing Segregation of Duties (SoD).
• Identity Stripping (Context Erasure): The agent executes downstream calls via its own static service account (OAuth client credentials). This drops the initiating human’s claims entirely, blinding SIEM and telemetry pipelines and destroying cryptographic non-repudiation.

3. Ephemeral Lifecycles vs. Static Provisioning

Traditional NHI lifecycle management relies on provisioning cycles built for long-running workloads (daily, weekly, or monthly credential rotation). Multi-agent systems, however, frequently instantiate ephemeral sub-agents that exist for a matter of seconds or minutes to perform a single isolated calculation before terminating. Static provisioning pipelines simply cannot operate at the speed of agentic lifecycle velocity.

Without an identity architecture designed specifically for the unique demands of agentic workflows, organizations deploying enterprise AI are exposing themselves to Excessive Agency, the root cause of many emerging AI safety and security incidents.

To solve this, we must establish a clear technical threshold that defines exactly when a workload stops being a standard NHI and becomes an autonomous agent requiring a dedicated, composite identity framework. 

The Threshold Test: When Does NHI Become an Agent Identity?

The Limits of Workload Identity Verification

In standard Zero Trust architectures, workload identity proves provenance and environment. Through mechanisms like SPIFFE/SPIRE, platform managed identities, or mutual TLS, an authentication layer verifies that a specific container, binary hash, or cloud instance is executing.

This verification answers a binary question: Is this software authorized to run?

For static automation, answering this question is sufficient. In autonomous systems, however, knowing the running binary does not reveal the execution path. A single agent instance, maintaining an identical cryptographic workload identity at startup, can be directed by prompt input or intermediate model reasoning to perform wildly divergent operations. Workload identity proves which software is running, but it cannot prove whether a specific action, within a dynamic context, under a specific delegation chain, should be permitted.

The industry requires a concrete boundary: a threshold test that determines when standard non-human identity management is sufficient, and when a system must transition to first-class agent identity controls.

The Three-Part Threshold Test

To determine whether an entity can remain managed as standard NHI or requires full agent identity governance, architects should apply the following three-part threshold test:

Test 1: Non-Deterministic Execution Paths

• Standard NHI: The code path is deterministic. While inputs vary, the branches and possible actions are strictly hardcoded into the application logic.
• Agent Identity: The software relies on non-deterministic reasoning (such as an LLM evaluation loop) to synthesize plans and choose actions. The specific sequence of operations cannot be predicted or exhaustively mapped prior to execution.

Test 2: Dynamic Capability and Tool Selection

• Standard NHI: Downstream API calls, database queries, and integrations are predefined during deployment. The required OAuth scopes or IAM roles can be statically declared and bound to the workload at startup.
• Agent Identity: The software dynamically queries a tool registry, evaluates schema descriptions, and decides which endpoints to call based on intermediate outputs. Privileges must be evaluated and bound at the point of action rather than statically granted at boot.

Test 3: Multi-Hop Delegated Authority

• Standard NHI: The service acts either entirely as its own principal (a backend synchronization daemon, for example) or completes a single-hop user action without further delegation.
• Agent Identity: The entity acts on behalf of a human user, retaining their authority while coordinating with subordinate agents or third-party platforms. It requires composite attribution that ties the resulting operation to both the initiating human and the specific agent instance.

If an entity meets these three conditions, continuing to treat it as standard NHI introduces systemic risk. It has crossed the threshold into requiring a dedicated agent identity model.

Architectural Realities of the Agentic Frontier

Managing agentic systems under traditional non-human identity frameworks is a category error with immediate security consequences. Workload identities, service principals, and API keys answer only whether a particular software container or binary is trusted to execute. They cannot evaluate non-deterministic reasoning, runtime tool selection, or multi-hop delegation chains where user intent must be preserved and bounded.

The threshold test provides a clear demarcation line. When an entity shifts from pre-compiled branching logic to runtime reasoning, selects its own tools dynamically, or acts across administrative boundaries on behalf of a human principal, standard workload controls fail. 

Attempting to fit these actors into static OAuth client registrations or blanket service roles guarantees either catastrophic operational failure from over-privilege or operational paralysis from artificial friction.

Solving this challenge requires IAM architecture to recognize the agent as a first-class entity. Trust must move away from static startup tokens toward dynamic, short-lived, and task-derived credentials. By binding the human initiator, the specific agent instance, and the declared task context into composite claims, identity teams can enforce segregation of duties and maintain least privilege in non-deterministic environments. The choice facing identity professionals is not whether to support autonomous agents, but whether to govern them with an identity plane built for agency or wait for excessive agency to define their threat model.

About the Author 

Victor Hernandez Guzman is a Principal Software Engineer at DocuSign, where he leads architectural strategy across the Identity organization, defining core authentication and authorization systems serving over one billion users globally. With over 20 years of engineering experience and 15+ years specializing in distributed systems and identity, Victor has designed and operated tier-0, hyperscale identity providers at DocuSign, Microsoft, and Salesforce. A pioneer in passwordless authentication, he led the first server-side implementation of WebAuthN for Microsoft Account, coordinating across Windows, Edge, and the W3C working group to deliver the industry’s first FIDO2 passwordless solution, and later served as the technical lead for Azure’s datacenter Secure Token Server (dSTS) across 500+ datacenters. Currently, he serves on the Leadership Team for the OWASP GenAI Security Project contributing to the Agent Control Standard (ACS), driving the extension of IAM governance, policy enforcement, and machine-to-machine trust into emerging agentic AI architectures.