No AI Agent Without Identity (Part 1): Why IAM Comes Before Autonomy

Series Context This is the first part of a 5-part series on agentic AI governance. As organizations deploy AI agents that can act across enterprise systems, traditional approaches to governance are proving insufficient. In this part, we examine why AI agents can no longer be treated as invisible automation and why identity and access management must come before autonomy. Zero Trust cannot govern actors it cannot identify. If an AI agent can read data, call tools, trigger workflows, or act on enterprise resources, then identity is the minimum requirement for access control, supervision, auditability, revocation, and accountability. Requiring proper identity for AI agents is not just another layer of governance overhead. While performance, complexity, and development effort are real and valid concerns, they are secondary to a more fundamental requirement: without identifiable agents, enterprises cannot enforce access control, supervision, auditability, revocation, or accountability. These are not optional controls — they are the baseline for operating agents responsibly inside enterprise systems. Note: This article series is intentionally detailed. Agent identity is not a slogan-level problem. The operational and architectural details matter because the failure modes live in those details: borrowed human identities, generic service accounts, untraceable replicas, context refreshes with no lineage, agent-to-agent handoffs with broken attribution, MCP tool calls with weak identity, revoked access that keeps retrying, and audit logs that cannot reconstruct what actually happened. The principle is older than AI: any actor that can access systems, trigger workflows, affect resources, or make operational decisions must be identifiable. Humans already have identities. Services, workloads, devices, applications, and automation accounts increasingly have identities. AI agents should not become the invisible exception. The rise of agentic AI has created a dangerous asymmetry. Enterprises are rapidly deploying systems that can access APIs, update records, generate tickets, approve steps, summarize incidents, and sometimes decide the next action — often without direct human involvement. This is not a criticism of agentic AI. It is the opposite: the more capable these systems become, the more important identity becomes. For years, most enterprise AI was used primarily for analysis, correlation, prediction, and generating insights. In that model, governance focused mainly on controlling data access and managing output quality. Agentic AI represents a different category. An agent does not only analyze data or produce recommendations — it can call tools, trigger workflows, update records, connect systems, and perform actions that directly affect business operations. This moves AI from research and analytical support into operational execution across the enterprise. That change raises the governance bar significantly. When AI mainly analyzed data, it was already necessary to govern what information it could access. When AI can act, the organization must also ensure that every meaningful action is traceable, attributable, revocable, and auditable. This is why identity becomes a foundational requirement rather than an optional control. This imbalance exists because much of the current discourse around agentic AI still comes from environments where the main priority has traditionally been model capabilities, experimentation, and performance. As a result, infrastructure-level controls such as identity, authorization, and auditability have received significantly less attention than model-level concerns like alignment, prompt injection, and output filtering. Today, regulatory, legal, and operational expectations around AI governance extend well beyond traditional regulated industries. Almost any organization deploying AI agents in production environments now faces increasing pressure to ensure those agents are identifiable, auditable, and subject to proper access control and oversight. If AI agents are expected to act inside enterprise workflows, assist human decisions, operate under delegation, call tools, or perform increasingly autonomous tasks, then they are no longer simple resources. They must be treated as identifiable actors. Identity is not an obstacle to autonomy. It is the foundation that makes responsible, governable autonomy possible. There is a clear contradiction in how many organizations approach agentic AI. They promote agents as capable of taking over meaningful human work — analysis, decisions, approvals, and operational actions — while simultaneously treating identity as unnecessary governance friction that slows development down. These two positions cannot both be true. If an agent is considered capable enough to replace human work, even junior or assisted work, then it should also be considered important enough to be properly identified as an actor. Pretending otherwise is either inconsistent or intellectually dishonest. But many of those agents are still being identified with patterns designed for another era: borrowed human sessions, shared service accounts, generic API keys, runtime tokens with no stable enterprise attribution, or just a workflow name in an application log. That may be convenient for a prototype. It is not a governance model. The core thesis is simple: No AI agent without identity. Without stable and attributable identity, enterprises cannot reliably answer basic but critical questions: Which agent acted? Under whose authority? With which permissions? Based on which context? After which policy decision? With what audit trail? Human-in-the-loop (HITL) cannot be used as an excuse to delegate credentials. Zero Trust cannot reason about an actor it cannot identify. This is not a proposal for a brand-new IAM category. It is an argument that agentic AI makes existing non-human identity patterns insufficient unless they become more granular, dynamic, context-aware, and auditable. Not because identity solves every AI safety problem. Because without identity, everything else becomes unenforceable. The agentic wave is not a post-identity era. It is a higher-stakes continuation of the same identity and access discipline enterprises have refined for decades — only now the actors move faster and reach further. Agents Are Not Just Resources Enterprises already assign identities to many non-human entities — servers, workloads, CI/CD systems, SaaS integrations, and automation accounts. Even relatively simple devices like printers often have clearer identity, ownership, and audit records than the AI agents now being deployed to make decisions and take actions. It makes little sense to treat AI agents as the exception. AI agents are not only another class of automation. They are being designed to become key operational actors in IT management, resource planning, workflow execution, and service orchestration. Over time, agents will become one of the largest sources of interactions with enterprise systems and some of the most frequent holders of access to sensitive data, sensitive tools, and sensitive services. They will act through APIs, automation platforms, SaaS connectors, and MCP servers. Treating an agent as invisible application logic is a category error. When an agent acts through a human’s credentials, the audit trail shows the human identity, not the agent’s role in the action. The agent may have selected files, summarized evidence, called tools, ranked options, opened tickets, queried systems, or executed intermediate steps. Those intermediate actions also need attribution, because the human may have delegated the task without directly performing every step. When organizations delegate tasks that involve interpretation, summarization, classification, ranking, or decision-making to AI agents — even when those tasks remain supervised — the agent must be treated as an actor with its own identity. Ignoring that agent layer is not only incomplete from a governance point of view. The reason is not only accountability. It is also operational diagnosis. Enterprises need to understand where friction appears, where failures happen, which step was missing, how decisions were made, and whether the problem came from the human, the agent, the tool, the policy, the data, or the handoff. That visibility is also needed to justify budgets and improve IT operations. That is why first-class identity is not a future enhancement. It is a prerequisite for the enterprise AI future. If agents are going to operate beside humans, act on behalf of humans, and eventually perform many actions that human approval cannot scale to review one by one, then they need identities with the same seriousness we apply to human users — and in some cases more. As I argued in ' Human Approval Will Never Scale as AI Infrastructure ', human review cannot be the only control layer for agentic systems at scale. If autonomous or semi-autonomous agents become the default operating behavior, identity and revocation must be designed before autonomy is expanded. Ultimately, any AI agent that can touch enterprise resources must become a first-class identity subject in the enterprise control plane. This Is Not a New Identity and Access Management Category The originality of this approach lies not in creating a new identity category for AI agents, but in refusing the assumption that every AI problem requires a completely new governance paradigm. The goal is not to build a separate identity universe for agents. The better path is to extend the existing enterprise identity foundation where agentic systems create new technical pressure — exactly as IT has done with each major technology wave. In much of the AI conversation, novelty is treated as a virtue by default: new agents, new protocols, new guardrails, new orchestration layers, new governance models. But enterprise security has already learned, across decades of infrastructure change, that any actor able to access systems, trigger workflows, affect resources, or make operational decisions must be identifiable, governable, revocable, and auditable. AI agents do not invalidate that discipline. They increase its importance. Thus, this is not a new Identity and Access Management (IAM) category. It is a new pressure on existing identity and access management systems. The idea of non-human identity is not new. Enterprises already use service accounts, workload identities, machine-to-machine authentication, CI/CD identities, cloud roles, and automation credentials. The mistake would be to treat AI agents as if they fit cleanly into those older patterns without change. Traditional non-human identities usually represent deterministic systems: a service calls another service, a pipeline deploys code, a scheduled job runs a known task, or an integration synchronizes records. AI agents are different because they may interpret context, choose tools, call different systems, generate intermediate decisions, and operate under partial human delegation. In identity and access management terms, an AI agent may need to be treated as a user: an identifiable entity that consumes resources, requests access, holds credentials, belongs to policy groups, and performs actions. It is not a human user, but it behaves like a user in the access-control sense. That distinction matters. Agent identities may carry implications closer to human identities than to traditional service accounts. They may require additional attributes, groups, or claims to represent properties such as supervision state, delegation mode, risk tier, autonomy level, approved tools, and review requirements. The issue was never that identity and access management lacks a foundation for this. The uncomfortable truth is simpler: many organizations are not applying the same identity discipline to AI agents that they already apply to other actors. Using the existing identity system is the minimum required step. Scaling it, adding agent-specific attributes, and making it more dynamic and context-aware are the next steps. Agentic AI does not replace workload identity. It requires stronger identity and access management, forcing workload identity, audit, policy, and supervision to become more granular, more dynamic, more context-aware, and more auditable. New Pressures Do Not Justify Weakening Identity Software engineering must operate inside real-world boundaries — permissions, identities, policies, failure modes, ownership, and audit requirements. Agentic AI does not remove these boundaries. It only makes them more dynamic and harder to ignore. Those pressures on identity and access management do not justify weakening, bypassing, or postponing identity controls. Governance remains a hard constraint: if scale, speed, and dynamism exceed what can be properly governed, the deployment must be limited until it fits within accountable boundaries. What This Part Establishes This part establishes that AI agents are active enterprise participants, not passive resources. It demonstrates why relying on human-in-the-loop approvals and prompt-based instructions is inadequate for production environments and introduces the core thesis that stable, attributable identity is a prerequisite for governed autonomy. Next in the series: → Part 2: Building the Layered Identity Model