Beyond Human Identity: A Runtime Governance Model for Autonomous AI Agents in the Enterprise Cloud

Enterprise identity management was built around people. Identity and Access Management (IAM) platforms started with employees, contractors, and partners, then stretched to cover service accounts, APIs, and machine identities. Every one of those extensions kept a quiet assumption intact: the identity itself does not make decisions.

AI agents break that assumption. Organizations are deploying coding assistants, customer support agents, security copilots, and workflow agents that plan tasks, choose tools, call APIs across multiple systems, and adjust their behavior based on context and objectives. They are not executing a fixed script. The Cloud Security Alliance's research on agentic identity reaches the same conclusion: IAM approaches built around OAuth, OpenID Connect, and SAML assume stable, predictable principals, and agents are neither [1].

Identity Governance and Administration (IGA) answers two questions well. Who is requesting access, and what permissions were assigned. Agents force a harder set of questions. What objective is the agent pursuing right now? Is the requested action still aligned with its business purpose? Has the context changed since access was granted? Should access continue if behavior starts to drift?

Lifecycle governance cannot answer these, because they are runtime questions. This article proposes Runtime Identity Governance (RIG), a model that evaluates an agent's identity, delegation chain, intent, context, and behavior continuously through its operational life, not just at provisioning time.

Modern IGA platforms handle the identity lifecycle well: joiner, mover, and leaver processing, access requests and approvals, role management, certifications, and segregation of duties. These controls remain necessary. They govern who receives access. They say almost nothing about how access is exercised once granted.

Consider an AI procurement agent authorized to purchase cloud infrastructure. At 9:00 AM the request is legitimate. By 11:30 AM the budget has changed, the project has been cancelled, the vendor is different, or an upstream prompt has quietly altered what the agent is trying to do. The original approval is still technically valid. The business context that justified it is gone. Traditional governance has no mechanism that notices.

The instinct in most organizations has been to file agents under service accounts, because that was the nearest existing category. The comparison does not hold.

Characteristic	Human User	Service Account	AI Agent
Decision making	Human	None	Autonomous
Business objective	Human-driven	Fixed	Dynamic
Permission usage	Predictable	Predictable	Context dependent
Task execution	Manual	Scripted	Adaptive
Governance requirement	Lifecycle	Credential	Continuous

A service account that does something new is itself a security signal. An agent doing something new is Tuesday. Agents select tools, change execution order, and generate actions nobody enumerated in advance, so novelty cannot serve as the alarm.

The scale of the gap is already documented. In CSA survey research on non-human identity, 51 percent of organizations reported no clear ownership for AI identities, 47 percent of non-human identities had gone unchanged for more than a year, and 16 percent were not tracking the creation of new AI credentials at all [2]. That population is growing faster than anyone is watching it.

1. Verified identity and credentials

Every agent needs its own enterprise identity. Not a shared team API key, not the credentials of the developer who deployed it, and not the identity of the user it happens to be helping. Shared credentials make agents indistinguishable from each other and invisible to audit. Workload identity standards already provide the primitives, including OpenID Connect federation for workloads and SPIFFE for service identity [9].

The registry entry behind that identity should carry a business owner, an application owner, a stated purpose, a trust level, assigned tools, approved data domains, and a lifecycle state. Ownerless agents are the new orphaned service accounts, except they act with more autonomy.

Credentials deserve equal discipline. The pattern to move toward is just-in-time issuance: the agent authenticates with its workload identity, receives short-lived credentials scoped to the task at hand, and holds nothing worth stealing between tasks. OWASP's guidance for securing agentic applications makes the same recommendation [7].

 

2. Governed delegation

Agents rarely act alone. A user asks an assistant, the assistant asks an orchestrator, and the orchestrator dispatches sub-agents. By the third hop the original user is invisible unless their context was deliberately carried along.

Two rules keep chains governable. Record the chain: token exchange (RFC 8693), with the act claim carrying the acting party, lets a downstream service see both the agent making the call and the user it represents [8]. Attenuate scope at every hop: a sub-agent receives a subset of the orchestrator's authority, never a copy of it. An orchestrator that passes its full authority downstream turns every sub-agent into a privilege escalation waiting for a prompt injection to trigger it. OWASP's agentic threat taxonomy catalogs this failure family under tool misuse and privilege compromise [3].

 

3. Intent validation

Identity establishes who is acting. It says nothing about why. Before a privileged operation proceeds, the requested action should be checked against the agent's registered business purpose. An agent registered for billing dispute resolution that starts exporting customer records for what looks like segmentation analysis has valid permissions and invalid intent. Purpose is only enforceable if the authorization layer can see it, which is why purpose belongs in the agent registry and in the decision request, not in a design document.

 

4. Context-aware authorization

Static permissions should define the outer boundary of what an agent could ever do. Whether a specific request is appropriate right now is a separate decision, informed by workload identity and location, device and environment posture, data classification, transaction sensitivity, time, and current behavioral risk. This is the zero trust model applied to agents: NIST SP 800-207 describes access as a per-request decision made by a policy decision point using dynamic context, and nothing in that architecture assumes the requester is human [4].

 

5. Continuous trust evaluation

Trust should move during execution. Unusual API usage, unexpected tool invocation, excessive data retrieval, repeated authorization failures, and abnormal execution patterns are all reasons for it to fall. The response does not need to be binary. Depending on risk, an organization can narrow permissions, require step-up verification, pause execution pending human approval, or revoke outright. Graduated responses keep agents useful while containing them.

A practical implementation separates into layers that most enterprises can map onto existing investments.

1. Agent registry: ownership, purpose, metadata, lifecycle state, approved capabilities.
2. Identity provider: authenticates agents with enterprise identity standards and issues workload identities.
3. Credential service: issues short-lived, task-scoped credentials on demand.
4. Intent evaluation service: checks requested actions against registered purpose.
5. Policy decision point (PDP): evaluates each request using identity, delegation chain, intent, and context.
6. Context providers: feed risk signals from cloud platforms, security tooling, and data classification services.
7. Policy enforcement point (PEP): applies decisions before tool execution or API invocation.
8. Audit and monitoring: records every decision, policy version, and verdict.

Figure 1 shows how these fit together: a governance plane that records who each agent is, who owns it, and what it is for, feeding a runtime plane that enforces those facts on every request.

Figure 1. Runtime identity governance architecture: registry, credential risk scoring, and lifecycle controls in the governance plane feed per-request policy decisions in the runtime plane.

Figure 2 traces a single request through the model, from the user's task through delegation, just-in-time credentials, the policy checks, and the decision log.

Figure 2. Decision flow for one agent request: delegation with scope attenuation, just-in-time credentials, per-request policy evaluation, and logging of every verdict.

The audit layer matters more than it first appears. Every consequential agent action should be attributable to the agent, its owner, the delegating user, and the policy that allowed it. That traceability is the same accountability thread the NIST AI Risk Management Framework asks organizations to maintain through its Govern and Manage functions [5]. When an auditor asks why an autonomous system touched customer data, a decision log is an answer. "The model decided to" is not.

None of this requires waiting for new products. A realistic first quarter: inventory the agents already running in your cloud, including the pilots nobody registered. Assign each one an owner and a purpose, and disable the ones nobody claims. Replace shared and static credentials with per-agent workload identities, starting with agents that touch regulated data. Record delegation wherever one identity acts for another. Then pick one high-value agent and move its authorization decisions out of code and into policy. Teams that want a control framework to measure against will find that the identity and access management domain of CSA's AI Controls Matrix maps cleanly onto the five pillars [6].

Agents are no longer passive workloads executing predetermined instructions. They are participants that make operational decisions across cloud environments, and their population is growing faster than the governance around it. The question identity teams must be able to answer is shifting from who received access to how access is being exercised, why it was requested, and whether it should continue. Runtime Identity Governance is a practical frame for that shift. Organizations that adopt it now will onboard the next wave of agents safely. Those that keep filing agents under service accounts will eventually learn, during an incident review, how much authority accumulated in identities nobody was watching.

 

[1] Cloud Security Alliance, "Agentic AI Identity and Access Management: A New Approach," 2025. https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach

[2] Cloud Security Alliance, "Securing Non-Human Identities in the Age of AI Agents," 2025. https://cloudsecurityalliance.org/artifacts/securing-non-human-identities-in-the-age-of-ai-agents-rsac-2025

[3] OWASP GenAI Security Project, Agentic Security Initiative, "Agentic AI Threats and Mitigations," 2025. https://genai.owasp.org/initiatives/agentic-security-initiative/

[4] NIST, "Zero Trust Architecture," Special Publication 800-207, August 2020. https://csrc.nist.gov/pubs/sp/800/207/final

[5] NIST, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)," NIST AI 100-1, January 2023. https://www.nist.gov/itl/ai-risk-management-framework

[6] Cloud Security Alliance, "AI Controls Matrix," 2025. https://cloudsecurityalliance.org/artifacts/ai-controls-matrix

[7] OWASP GenAI Security Project, "Securing Agentic Applications Guide 1.0," 2025. https://genai.owasp.org/resource/securing-agentic-applications-guide-1-0/

[8] IETF, "OAuth 2.0 Token Exchange," RFC 8693, January 2020. https://www.rfc-editor.org/rfc/rfc8693

[9] SPIFFE Project, "Secure Production Identity Framework for Everyone." https://spiffe.io