Category Archives: AI
How Governance Around Identity and Access Is Changing in 2026
For decades, enterprise identity management was primarily viewed as a perimeter issue. The main objective was to verify that an employee or customer was who they claimed to be at the initial point of entry, issue a password or single sign-on (SSO) token, and grant access accordingly. Enterprise security was grounded in a foundational question: “Who are you, and what systems are you allowed to access?”
By 2026, this approach has become obsolete, and the traditional questions are no longer adequate for effective identity governance.
The proliferation of distributed multi-cloud architectures, non-human identities, and autonomous AI agents capable of executing thousands of actions per minute has created an unprecedented paradigm shift for security leaders. As a result, traditional Identity Governance and Administration (IGA) is rapidly evolving into Identity, Authorization, and Runtime Governance.
The following analysis examines how governance surrounding identity and access is undergoing fundamental transformation.
1. From Access Governance to Action Governance
Traditional IGA models governed static access paths (e.g., Jane, a Finance Manager, has access to Salesforce, Workday).
In 2026, security teams are required to govern actions rather than merely access. When an AI agent leverages delegated authority to interact with an API or update numerous accounts, the critical question extends beyond system access to whether the agent is authorized to perform specific actions on behalf of a human. As highlighted in NIST’s 2026 guidance, reliance on extensive human-in-the-loop controls or the sharing of broad credentials introduces significant risks within agentic systems.
2. Managing the Explosion of AI Agents and Non-Human Identities
Whereas previous governance models focused primarily on employees, contractors, and partners, contemporary enterprises now manage an expanding ecosystem that includes service accounts, APIs, cloud workloads, and AI agents.
Modern enterprises are no longer comprised solely of human workers. In many cloud environments, autonomous AI agents, service accounts, APIs, and automated pipelines now outnumber human users.
Traditional Identity and Access Management (IAM) tools were designed to manage human login lifecycles, resulting in significant governance gaps for non-human entities. By 2026, organizations must address the reality that AI agents or automated scripts with broad permissions can execute high-impact actions at machine speed. As a result, governance frameworks have expanded to treat non-human actors as first-class entities, requiring explicit lifecycle oversight, verifiable lineage, and stringent runtime boundaries.
In contrast to traditional service accounts that execute predefined scripts, AI agents interpret objectives, select tools, make decisions, and delegate tasks to sub-agents. In alignment with NIST’s 2026 AI Agent Standards Initiative, governance of non-human identities is becoming a core enterprise requirement, necessitating:
- A verifiable, unique identity and defined purpose
- An accountable human owner
- Clear traceability through a delegation chain
- Defined lifecycle management (from creation to retirement)
3. Moving Beyond the Front Door: The Rise of Rigorous Proofing (IAL2)
The proliferation of deepfakes, synthetic data, and automated credential stuffing has rendered basic logins increasingly untrustworthy. Consequently, organizations are raising their upfront verification standards. Frameworks such as NIST’s Identity Assurance Level 2 (IAL2) are transitioning from federal mandates to mainstream enterprise requirements.
Contemporary governance frameworks now distinguish between identity proofing (“Who are you in the real world?”) and authentication (“Do you control this digital credential?”). Organizations are implementing multi-pathway proofing processes that integrate government-issued photo validation, biometric liveness checks, and authoritative database cross-checks. These measures ensure that every high-risk digital interaction or privileged onboarding is anchored in verifiable trust prior to the issuance of any token.
4. Transitioning to Dynamic, Contextual Authorization
Static Role-Based Access Control (RBAC) and once-per-session checks are no longer sufficient to protect dynamic cloud architectures. Modern frameworks are adopting models that emphasize Just-in-Time, Just Enough Access, and action-specific authorization to address the demands of real-time environments.
Authorization engines now incorporate real-time context and risk, evaluating variables such as user behavior, device state, agent intent, environmental factors, and continuous risk scores prior to granting transaction-level privileges.
Current market trends emphasize continuous authorization and Zero Standing Privilege (ZSP). Identity governance systems now evaluate context in real time by analyzing device health, network anomalies, behavioral baselines, and runtime risk scores. If an entity’s risk profile changes during a session, governance platforms can automatically increase verification requirements, restrict permissions, or terminate access immediately.
5. Moving from Periodic Reviews to Continuous Governance
Quarterly access reviews and annual certifications are insufficient for environments operating at machine speed. Governance is transitioning from periodic audits to continuous, real-time, and event-driven monitoring. If an agent’s behavior becomes anomalous, policies can trigger immediate automated interventions to reduce privileges.
6. Convergence Into an “Identity Control Plane” and The Shift Toward the “AI Identity Fabric”
Historically, technologies such as IGA, Privileged Access Management (PAM), Security Information and Event Management (SIEM), and User and Entity Behavior Analytics (UEBA) operated in isolated silos. The emergence of AI is driving the convergence of these technologies into a unified Identity Control Plane, which serves as a centralized framework for organizations to discover, assess, authorize, and govern all digital actions across multicloud and SaaS environments.
To integrate these components, enterprise architecture is evolving toward an AI Identity Fabric.
Future IAM platforms will extend beyond managing human users to governing the complex relationships among humans, AI agents, tools, data, and autonomous actions. Each automated workflow must maintain a clear and traceable chain of delegation, linking every autonomous action to an accountable human sponsor.
What This Means for Identity Leaders
For Chief Information Security Officers (CISOs) and Chief Information Officers (CIOs), the operational mindset is experiencing a fundamental transformation:
- Old Priority: “Who has access?” → New Priority: “Who or what can act?”
- Old Priority: Access certifications → New Priority: Continuous authorization
- Old Priority: Human identities → New Priority: Human, machine, and AI identities
- Old Priority: Audit access → New Priority: Audit identity, authority, and action
Conclusion
Enterprises in 2026 differ fundamentally from those for which traditional IGA was designed. The transformation of identity governance extends well beyond a product update; it signifies a shift from managing access to managing authority. Identity is increasingly serving as the mechanism by which enterprises govern digital actions.
By establishing identity as the core control plane for autonomous enterprises, organizations can securely leverage AI while ensuring that every human, machine, and autonomous agent operates with verifiable intent and accountability. Organizations that persist in treating identity as an isolated login mechanism will face challenges from automated threats and stringent compliance audits. Success will favor those who adopt identity as an observable, programmable, and deeply integrated infrastructure fabric.
Share this:
Identity Is No Longer a Login Problem. It’s an Infrastructure Problem
For decades, enterprise identity was all about one simple question: “Who are you, and can we let you log in?” Fast forward to today, and that model is rapidly becoming obsolete. Modern enterprises are no longer just made up of employees logging into applications; they are complex ecosystems of humans, applications, APIs, service accounts, workloads, and AI agents.
Identity has fundamentally outgrown the front door. It is no longer just an authentication service it is evolving into an enterprise control plane and a critical infrastructure layer.
The Catalyst: Agentic AI and Non-Human Identities (NHIs)
The most significant driver of this transformation is the rise of agentic AI. Unlike traditional software that follows predetermined instructions, AI agents can receive a goal, reason about it, select tools, call APIs, and execute actions on our behalf. According to Okta’s 2026 Businesses at Work research, 91% of organizations are already using AI agents, yet only 10% have a well-developed strategy for managing them.
This creates a massive governance challenge. When an AI agent executes a transaction across a SaaS application, a database, and a downstream payment system, who is ultimately responsible? Traditional Identity and Access Management (IAM) struggles here because it often compresses multiple actors into a single credential. The future of identity must preserve the entire chain of authority—from the human sponsor to the agent, the delegated tools, and the final action.
From Directory to Identity Graph
To manage this complexity, identity architecture is shifting from a static directory (User → Groups → Applications) to a dynamic Identity Graph. This graph maps the complex relationships connecting human identities, machine identities, AI agents, delegated permissions, APIs, and data.
Non-Human Identities (NHIs) such as API keys, service accounts, and automated pipelines—are scaling rapidly, often dwarfing human users. An enterprise identity fabric must treat these NHIs as first-class citizens with strict lifecycles, clear ownership, and defined time boundaries. Every production agent should have a verifiable identity, an accountable human owner, a clear purpose, and a controlled retirement process.
Authorization Over Authentication
While authentication proves who the actor is, authorization determines what they are allowed to do. In an agentic enterprise, authorization must be dynamic, contextual, and time-bound.
Privileged Access Management (PAM) is also moving into the autonomous era. AI agents should operate on Zero Standing Privilege (ZSP)—requesting Just-In-Time (JIT) and least-privilege access only when needed, and immediately losing that privilege when the task is complete. Identity infrastructure must evolve to evaluate real-time trust, analyzing behavioral baselines and context before granting access.
The New Identity Security Fabric
As protocols like Model Context Protocol (MCP) and Agent-to-Agent (A2A) communication become standard, delegation must be explicit and verifiable across organizational boundaries. Identity determines who can access data, and data context determines what an identity should be allowed to access.
To prepare for this shift, organizations must:
- Build a comprehensive identity inventory covering every human, machine, workload, and AI agent.
- Give every AI agent a first-class identity with explicit human accountability and sponsorship.
- Move toward dynamic, risk-based authorization rather than relying solely on static Role-Based Access Control (RBAC).
- Create an agent activity ledger to track the entire trajectory of an automated action for compliance, forensics, and accountability.
Conclusion: Trustworthy Autonomy
Identity is no longer just answering “Can you log in?” It is now answering, “Can this actor perform this action, on this resource, under this context, with this authority and can we prove why?”
The winning enterprise architectures will treat identity as the operating system for digital trust a unified security fabric that makes the autonomous enterprise possible, observable, and deeply secure.
Important Takeaways for the Modern architecture:
- Identity is becoming a control plane, not simply an authentication layer.
- AI agents are creating a new category of first-class non-human identities.
- Authorization is becoming more important than authentication.
- PAM must evolve toward Zero Standing Privilege for autonomous actors.
- Identity governance must move from periodic review to continuous, automated enforcement.
- Identity graphs will increasingly replace isolated directories as the foundation for understanding digital relationships and authority.
- Agent identity must preserve the chain of accountability from human sponsor → agent → delegation → tool → resource → action.
- Identity, data, behavioral analytics, PAM and AI security are converging.
- The winning enterprise identity architecture will be a unified Identity Security Fabric spanning humans, machines, workloads and AI agents.
- The ultimate goal is not merely secure access. It is trustworthy autonomy.
Share this:
Rethinking PAM: How AI Changes Privileged Access Management
For decades, Privileged Access Management (PAM) has operated under a straightforward assumption: there is a human behind the privilege. System administrators request access, security engineers elevate privileges, and employees perform sensitive administrative actions. We have spent years mitigating this human-centric risk using password vaults, multi-factor authentication (MFA), session monitoring, Just-in-Time (JIT) access, and Zero Standing Privilege.
Enter autonomous AI agents.
Unlike traditional service accounts that execute rigid, predefined workflows, an AI agent can reason, decide, delegate, execute, adapt, and act continuously at machine speed. It doesn’t just use privileged access; it makes autonomous decisions about how and when to use it.
This shifts the foundational security question from “Who has the password?” to: “Who or what is making the decision to use the privilege?”
Why the Privilege Problem Explodes With AI
Giving an AI agent administrative access to critical infrastructure introduces unprecedented risk. While a human administrator might make a single mistake, an autonomous agent can execute hundreds of complex, high-consequence decisions in minutes.
The threat is no longer theoretical. Recent investigations highlight how multiple AI agents can engage in coordinated activity—such as attempts to expand autonomy or manipulate environments underscoring that capability without strict privilege boundaries creates unacceptable enterprise risk.
When faced with risks like prompt injection, compromised credentials, or hallucinated objectives, traditional static PAM models fall short. We cannot simply trust an AI agent. Instead, we must build a security architecture where trust is continuously evaluated, privilege is dynamically granted, actions are constrained, and every decision is attributable and reversible.
The New PAM Framework: 5 Core Principles for Agentic Privilege
To safely embrace autonomous agents without exposing the enterprise to catastrophic blast radiuses, security leaders must modernize their PAM strategies around five foundational pillars:
1. Give Every Agent a Real Identity
No production AI agent should be anonymous. Every agent requires a unique, verifiable identity that can be authenticated, authorized, monitored, governed, rotated, revoked, and attributed. Beyond a simple name, this identity must bind together the owner, purpose, environment, underlying model, tools, risk level, and authorization scope.
2. Eliminate Standing Privilege
Leaving permanent administrator keys with an autonomous agent is the AI equivalent of leaving the data center keys on the front desk. Just-in-Time access, Zero Standing Privilege, and ephemeral tokens must be extended to AI workloads. An agent should only receive temporary, time-bound credentials precisely when a task demands it—and those permissions should automatically dissolve the moment the task is complete.
3. Authorize the Action, Not Just the Identity
Traditional authorization asks whether an identity is allowed to access a system. AI-native authorization must ask a deeper question: Is this identity allowed to perform this specific action, under these circumstances, right now? An infrastructure agent may legitimately need to read logs or restart non-critical services, but that does not mean it should have permission to delete databases, modify IAM policies, or disable security controls.
4. Treat Agent Behavior as a PAM Signal
Traditional PAM monitors static privileged sessions, but AI-native PAM must monitor behavioral intent and execution patterns. If an agent that normally interacts with a couple of databases suddenly begins querying dozens of systems, requesting new privileges, or communicating with unfamiliar agents, the PAM platform must dynamically catch the anomaly, re-evaluate risk, and scale back or revoke privileges.
5. Build a Human Accountability Chain
“We don’t know, the AI did it” is never an acceptable security posture. Every privileged action taken by an agent must maintain non-repudiation tracing cleanly from the human who initiated the workflow, through the agent’s intent and policy bounds, down to the exact system changes made.
The Ultimate Question
The future of PAM isn’t about securing humans from AI; it’s about securing the enterprise from what AI can do with privilege.
The winners in this new agentic era won’t be the organizations that give AI the most access. They will be the ones that master how to give AI the right access, at the right time, for the right reason—and revoke it the exact second that reason disappears.
So, can we trust AI agents with privileged access?
Yes, but only because we don’t trust the AI; we trust the deterministic controls wrapped tightly around it.
Share this:
MCP + A2A: The Connectivity Layer for the Agentic Enterprise
A single intelligent agent will not define the next phase of enterprise AI.
Networks of specialized agents working together will define it.
A customer-service agent may need to ask a billing agent to investigate an invoice. A security agent may need to ask an identity agent to validate a user’s risk. A procurement agent may need to collaborate with a finance agent before approving a purchase.
And those agents may be built by different teams, run on different platforms, use different AI models, and access completely different enterprise systems.
This creates a fundamental architectural question:
How do AI agents connect to the enterprise—and how do they communicate with one another?
Two emerging open protocols provide an important part of the answer:
- Model Context Protocol (MCP) connects agents to tools, data, APIs, and resources.
- Agent2Agent (A2A) connects agents to other agents so they can discover capabilities, delegate work, collaborate, and exchange results.
The important insight is that MCP and A2A are not competing protocols. They solve two different layers of the connectivity problem.
Think of MCP as the agent-to-capability layer and A2A as the agent-to-agent collaboration layer.
Together, they provide a foundation for building an interoperable agentic enterprise.
What Is MCP?
The Model Context Protocol (MCP) provides a standardized way for AI applications and agents to interact with external tools, data, and resources.
Instead of having every agent implement a custom integration, an MCP server can expose its capabilities through a common protocol.
For example:
The agent doesn't need to understand every underlying implementation.
It discovers the available capabilities and invokes them through MCP.
The latest MCP specification, released July 28, 2026, has also moved toward a more scalable architecture, including a stateless protocol core, routable HTTP-based interactions, cacheable capability discovery, authorization hardening, and an extensions framework.
That evolution is important because enterprise agent architectures need to operate at much larger scale than the original local-tool use cases.
What Is A2A?
The Agent2Agent (A2A) Protocol is an open standard that enables independent AI agents to communicate and collaborate.
A2A allows agents built using different frameworks, languages, technologies, or vendors to discover capabilities, negotiate interactions, manage tasks, and exchange information without requiring access to each other’s internal state, memory, or tools.
This distinction is critical.
An agent doesn’t necessarily expose its internal reasoning or implementation.
Instead, it exposes a capability boundary.
For example:
The customer service agent doesn’t need to know how the identity agent works.
It only needs to know:
- What can you do?
- What information do you need?
- What task can you perform?
- What result can you return?
That is the essence of agent interoperability.
MCP vs. A2A
The easiest way to understand the difference is:
| Question | MCP | Agent |
| Typical interaction | Tool invocation | Task delegation |
| Example | Agent → CRM API | Agent → Identity Agent |
| Discovery | Tools/resources | Agent capabilities |
| Result | Structured tool output | Task/result exchange |
| Boundary | Capability boundary | Agent boundary |
The official A2A documentation describes the protocols as complementary: MCP connects agents to tools and resources, while A2A enables agents to collaborate.
How MCP and A2A Work Together
This is where the architecture becomes particularly powerful.
Imagine an enterprise security investigation.
A Security Orchestrator Agent receives:
“Investigate whether this user’s recent privileged-access activity represents a security threat.”
The orchestrator may not perform the entire investigation itself.
Instead:
Step 1 — A2A discovers specialized agents
The orchestrator discovers:
- Identity Risk Agent
- Privileged Access Agent
- Endpoint Security Agent
- Threat Intelligence Agent
Step 2 — A2A delegates tasks
Step 3 — Each agent uses MCP
The Identity Agent might use MCP to access:
The PAM Agent might use:
The Endpoint Agent might use:
The individual agents then return their findings through A2A.
The orchestrator combines those results and makes a decision.
The Emerging Enterprise Agent Architecture through MCP + A2A
This leads to a much more scalable architecture:
This creates two distinct connectivity layers:
1. Horizontal connectivity = A2A
- Agents collaborate with other agents.
2. Vertical connectivity = MCP
- Agents connect to enterprise capabilities.
Share this:
The Rise of the AI Workforce: Why Every Agent Needs an Identity, a Passport and a Permission Boundary
We are standing at the precipice of a profound workforce evolution. For decades, enterprise identity systems were built around a simple, immutable truth: every digital actor has a human face, a corporate badge, and a predictable login cycle. But the operational makeup of the modern enterprise is transforming overnight. Autonomous AI agents are no longer experimental tech demos—they are writing code, orchestrating multi-system workflows, querying secure databases, and executing privileged actions across production environments.
Yet, as we unleash these tireless digital workers, we are managing them with security frameworks designed for passive tools. An agent given broad API access without strict identity boundaries is a ticking security liability. To build an enterprise ready for the autonomous era, we must recognize a fundamental mandate: Every AI agent needs an identity, a passport, and a strict permission boundary.
The Anatomy of the Autonomous Risk
Traditional Non-Human Identities (NHIs)—such as service accounts, API keys, and static OAuth tokens—have long been the weakest link in enterprise security. They lack lifecycle management, rarely rotate credentials, and sit silently in forgotten corners of cloud infrastructure until compromised.
AI agents amplify this risk exponentially. Unlike traditional scripts that follow hardcoded execution paths, autonomous agents reason, adapt, and make independent choices based on contextual data. If an agent is compromised or drifts from its intended operational guardrails, the blast radius isn’t limited to a single database or file share. It can traverse connected APIs, impersonate user context, and execute high-impact actions at machine speed.
Securing this new workforce requires us to move beyond perimeter defense and establish a dynamic, verifiable governance architecture.
The AI Identity Fabric
To safely orchestrate autonomous workflows, organizations must implement an end-to-end governance framework that tracks intent, delegation, and execution across every layer of the technology stack:
Decoding the Fabric Layers
- Human Identity: The root of origin. Every agent must trace its lineage back to an accountable human or enterprise stakeholder who authorized its creation and operational scope.
- Agent Identity: A cryptographically verifiable, unique persona for the AI model or instance itself—complete with behavioral baselines, attestation records, and lifecycle policies.
- Delegated Identity: The contextual scope transferred from the user to the agent. When an agent acts on behalf of a human, it must operate under constrained token exchange, ensuring it never exceeds the user’s entitled permissions (the principle of least privilege in motion).
- Tool/API Identity: The authenticated endpoints, microservices, and utilities the agent is permitted to invoke. Not all tools are created equal; high-risk tools require multi-party authorization or step-up verification.
- Data Access: Fine-grained, runtime evaluation of context. The agent’s ability to read specific datasets must adapt dynamically based on data sensitivity, compliance mandates, and current task parameters.
- Privileged Action: The final execution layer. Destructive or high-impact actions—such as modifying production configurations, initiating financial transfers, or revoking access—must trigger mandatory guardrails, human-in-the-loop approvals, or zero-standing-privilege checks.
“An agent without an identity fabric is an insider threat with a supercomputer’s work ethic. We cannot govern autonomous intelligence with static access control.”
The Paradigm Shift for Identity and Access Management
For years, IAM has focused on solving the identity equation for people: provisioning employees, managing contractors, securing customer logins, and enforcing multi-factor authentication. PAM (Privileged Access Management) has focused on locking down root accounts and vaulting credentials for human administrators.
As AI agents become core contributors to enterprise productivity, these silos must collapse. The challenge of the next decade is no longer just managing who has access to what, but governing how autonomous entities reason across systems on our behalf.
The future IAM platform won’t manage only people. It will manage the relationships between humans, AI agents, non-human identities, tools, data and autonomous actions.
Conclusion: Building Trust into Autonomy
The rise of the AI workforce represents an unprecedented leap in organizational capability, but it tests the limits of traditional security models. Passkeys, cryptographic identity verification, and dynamic permission boundaries are no longer optional best practices—they are the foundational infrastructure of the autonomous enterprise.
By establishing a robust AI Identity Fabric, security leaders can stop viewing autonomous agents as uncontrolled risks and start embracing them as secure, accountable members of the modern workforce.
Share this:
Rethinking Security: How Autonomous AI Challenges Traditional Models
We have moved beyond when conversational AI was just a fancy chatbot. Now, the real frontier of artificial intelligence is autonomous execution, not just answering questions or drafting emails.
Today’s AI agents can call APIs, access sensitive databases, set up cloud infrastructure, change system settings, create new digital identities, and run code in real time. They do more than just talk—they take action.
This change turns AI from a passive source of answers into an active digital worker. It also brings a serious challenge. Traditional security systems were designed for people, not fast, autonomous systems. How do you protect something that operates at machine speed, has wide digital access, and makes its own decisions?
This is where Identity, Security, and AI converge.
The Paradigm Shift: From Human Intent to Machine Autonomy
In older enterprise security models, every important action like updating a database, moving money, or changing permissions required human involvement. Even when using service accounts or API keys, a person still set up the process.
Autonomous agents change this approach. When an agent can create its own sub-identities and buy cloud resources as needed, the line between user and system disappears.
Consider the capabilities of a modern agentic workflow:
- Dynamic Identity Provisioning: Creating ephemeral service accounts to bypass static permission checks.
- Arbitrary Code Execution: Writing and running scripts on the fly to solve unexpected runtime errors.
- Cross-System Orchestration: Chaining API calls across SaaS platforms, databases, and internal infrastructure.
If an autonomous agent is compromised through prompt injection, data poisoning, or a misaligned goal, it does more than leak data. It can carry out harmful actions on a large scale.
Why Legacy Security Fails Here
We can’t use old tools to solve new problems with autonomous agents. Traditional security controls don’t work well because:
- Static RBAC (Role-Based Access Control) is too rigid. Agents need flexibility to handle complex problems, but fixed roles can’t keep up with AI’s real-time decisions.
- Perimeter defense no longer works. Agents move across cloud services, third-party APIs, and microservices. The real boundary is the agent’s current context, not a firewall.
- Post-hoc auditing is too slow. By the time a security system alerts you to a suspicious database wipe or unauthorized purchase, the autonomous agent has already finished its task.
A New Blueprint: How We Secure Autonomous AI
To secure enterprises using autonomous agents, we need to rethink identity, context, and safeguards from the ground up. Security leaders should focus on three main pillars:
1. Identity-Aware Intent Verification (Beyond OAuth)
An agent identity should be integrated into the broader Non-Human Identity (NHI) security strategy.
But AI agents are different from traditional service accounts.
A service account generally executes predefined functions. An AI agent can interpret context, make decisions, select tools, and initiate actions.
That means identity alone isn’t enough.
We need to know not just who the agent is but also what it is trying to do. An agent should not get all the permissions of its creator. We need dynamic session identities using cryptographic proof of intent. Every risky action, like changing a configuration or running code, should trigger a real-time check: Does this action match the approved business goal, or has the agent’s context been compromised?
Agent identity has to be two-layer:
- A durable workload identity — cryptographically attested, non-transferable, bound to the running code rather than to a secret in a config file. This is what you inventory, certify, and revoke. It answers what this thing is.
- An ephemeral, task-scoped credential — minted at task start, carrying the delegation chain, expiring when the work does. This answers what it may do right now.
2. Zero-Trust Sandboxing for Code and APIs
When an agent can write and execute code or invoke external APIs, that execution must occur within hyper-isolated, ephemeral environments.
- Blast-Radius Containment: If an agent is compromised during a database migration, its access must be hard-capped to that specific transaction, preventing lateral movement.
- API Gateway Interception: All outgoing API calls made by agents should pass through intelligent proxies that inspect payloads for semantic anomalies, preventing exfiltration before the request hits the wire.
3. Continuous Runtime Guardrails & “Circuit Breakers”
We must move from deterministic firewalls to behavioral guardrails. Like high-frequency trading platforms that use circuit breakers to halt runaway algorithms, autonomous AI needs real-time circuit breakers. If an agent suddenly tries to create unauthorized user identities or rapidly purchase high-cost cloud resources, automated systems must freeze the execution graph instantly.
The Thought Leader’s Takeaway
We are standing at the precipice of a fully agentic economy. The companies that win will not be the ones that build the smartest agents, but the ones that build the most trustworthy ones.
Securing AI is no longer just about protecting data from leakage; it is about governing autonomous action. If we fail to secure the hands of our AI systems, we hand over the keys to the enterprise.
The future belongs to security architectures that treat AI not as a tool to be restricted, but as an autonomous actor requiring continuous, intelligent oversight.
You won’t just secure your agents. You’ll have to build the control plane that the enterprise software agents run on over the next decade.
Once AI can act, Identity becomes its foundation, authorization becomes its guardrail, least privilege becomes its boundary, behavioral intelligence becomes its early-warning system, and governance becomes its accountability layer.
Share this:
Six Ways AI Can Transform Enterprise IAM
AI can transform IAM from a system that manages access into an intelligent, continuously adapting system that understands identity, intent, risk, and context.
Here are the six ways AI can help you transform your Enterprise IAM strategy
1. AI-Powered Identity Risk Scoring
For example:
One of the most powerful opportunities is to move from static access policies to continuous identity risk evaluation.
Instead of simply asking:
“Does this user have permission to access this application?”
an AI-powered IAM system can ask:
“Given everything we know right now, should this identity be allowed to perform this action?”
The risk engine could combine signals from:
- IAM, PAM, MFA, HR, Endpoint, SIEM, UEBA, Cloud, SaaS applications, Data classification, Threat intelligence, Behavioral history, Network context, AI-agent activity
This could produce a dynamic Identity Risk Score.
Identity Risk = 18 → Low
Allow normal access.
Identity Risk = 57 → Elevated
Require phishing-resistant MFA or step-up authentication.
Identity Risk = 86 → High
Block privileged access and trigger investigation.
The result is a shift from periodic authorization to continuous authorization.
2. AI Can Discover Excessive Access
Most large enterprises have an uncomfortable problem:
Nobody really knows who has access to what.
Users accumulate permissions.
Contractors retain old entitlements.
Service accounts remain active.
Applications create machine identities.
And now AI agents are being added to the mix.
AI can analyze identity relationships across the enterprise and identify:
- Unused privileges
- Toxic combinations
- Excessive permissions
- Orphaned accounts
- Dormant identities
- Overprivileged service accounts
- Excessive administrative rights
- High-risk access paths
- Privilege escalation opportunities
Instead of asking an identity administrator to review thousands of entitlements manually, AI could say:
“These 47 identities represent the highest unnecessary privilege risk in your environment. Here is why, and here are the recommended remediation actions.”
That changes IAM from a system of record into a system of intelligence.
3. AI Agents Need Their Own Identity Lifecycle
This may become one of the biggest IAM categories of the next decade.
Imagine an enterprise deploying 50,000 AI agents.
- Who created them?
- Who owns them?
- What systems can they access?
- What data can they see?
- Who approved them?
- What model are they using?
- What tools can they invoke?
- When should they expire?
- What happens when their owner leaves the company?
These are classic identity-governance questions — but applied to machines.
The future enterprise IAM platform should therefore manage an Agent Identity Lifecycle:
Discover → Register → Authenticate → Authorize → Monitor → Review → Revoke → Retire
Every agent should have:
- A unique identity
- An owner
- A sponsor
- A purpose
- A risk classification
- Defined permissions
- Expiration policies
- Activity history
- Access reviews
- Emergency revocation
In other words:
AI agents should be governed like employees — but with much tighter controls.
4. Move From RBAC to Intent-Aware Authorization
Role-Based Access Control has served enterprises well. But AI agents operate differently.
A single agent may perform hundreds of different tasks.
Instead of:
Agent → Role → 500 permissions
we should move toward:
Agent → Intent → Context → Minimum Required Permission
For example:
An HR AI agent might be permitted to:
- Read employee benefits information.
- But that doesn’t mean it should be allowed to:
- Modify compensation records.
A finance agent may be allowed to:
- Read invoices under $100,000.
But not:
- Approve a $5 million payment.
This is where Just-In-Time Access, Zero Standing Privilege, and policy-based authorization become extremely important.
AI should receive the minimum privilege necessary for the specific action — and preferably only for the duration of that action.
5. AI Can Become the IAM Administrator’s Copilot — and Eventually Agent
Identity teams spend enormous amounts of time investigating access issues.
AI can dramatically reduce this operational burden.
Imagine an IAM administrator asking:
“Why does this employee have access to Salesforce?”
The AI could respond:
“The user received the entitlement through the Sales Operations role 14 months ago. The employee changed teams six months ago, but the role assignment was not removed. The user has not accessed the application in 120 days. Recommended action: remove access.”
Or:
“Show me all privileged identities whose behavior deviates from their normal baseline.”
The system could analyze millions of events and return the highest-risk identities.
Eventually, AI could move from recommendation to controlled remediation:
Detect → Explain → Recommend → Approve → Remediate → Verify
With appropriate human oversight, IAM teams could manage environments that would otherwise require many more personnel.
6. Continuous Access Reviews Become Continuous Governance
Traditional access reviews are often periodic.
- Quarterly.
- Semiannual.
- Annual.
But AI agents can continuously change their behavior, tools, permissions, and workflows.
A quarterly review may therefore be obsolete before it is completed.
The future should be:
Continuous Access Governance.
AI continuously evaluates:
- Identity
- Entitlements
- Behavior
- Risk
- Data access
- Agent activity
- Policy compliance
- Business context
When something changes, the system responds.
For example:
Employee changes department
→ AI identifies impacted access.
Risk increases
→ Privileged access is reduced.
Agent changes behavior
→ Agent is quarantined.
Agent owner leaves company.
→ Sponsorship is reassigned, or agent access is suspended.
Unused entitlement detected
→ Access removal is recommended.
Sensitive data requested
→ Step-up authorization is triggered.
This is IAM moving from periodic governance to autonomous governance.
Share this:
AI’s Impact on Enterprise Identity Management
For twenty years, Enterprise IAM has been organized around a simple assumption: identities are either people or plumbing.
People log in, get provisioned through a joiner-mover-leaver process, and sit through a quarterly access review. Plumbing service accounts, batch jobs, API integrations, gets a long-lived credential, a bounded scope, and an owner who may or may not still work here.
“Who are you, and what are you allowed to access?”
Traditionally, this question applied primarily to human users. Employees, contractors, partners, and administrators would authenticate, receive permissions, utilize applications, and subsequently have those permissions revoked as necessary.
Non-human identities already outnumber human ones by something like seventeen to one, and that population grew by double digits year over year before agents were a meaningful share of it.
However, the advent of AI is fundamentally altering this paradigm. AI agents break this binary. An agent has an identity, credentials, and a scope like a service account does, but its scope changes with every invocation. Currently, organizations deploy AI copilots, autonomous agents, AI-powered applications, and multi-agent workflows. These systems can access data, interact with APIs, execute business processes, and, in some cases, make decisions on behalf of employees.
As a result, the central question has become significantly more complex than “Who are you?”
It is: “Which human, agent, application, or machine is acting, on whose behalf, with what authority, for what purpose, and with what level of risk?”
This development represents an entirely new category of identity management challenge.
This shift presents IAM with a significant opportunity to serve as the primary control system for enterprise AI.
The Emergence of the AI Agent as a Distinct Enterprise Identity
Recent advancements clearly indicate this emerging direction.
Microsoft has introduced Entra Agent ID, specifically designed to provide identities for AI agents and govern their access throughout their lifecycle. The platform includes concepts such as agent identities, owners and sponsors, lifecycle governance, and access packages.
NIST has also launched work focused specifically on identity and authorization for software and AI agents, recognizing that agents require access to diverse data, tools, and applications and therefore need appropriate identification and auth. The security market is also evolving rapidly in this direction. For example, Cyera’s acquisition of Oasis Security, reportedly valued at approximately $1 billion, underscores the increasing significance of non-human identity and AI-agent governance and AI-agent control.
Concurrently, security researchers increasingly advise that AI agents should be regarded as potentially privileged insiders rather than as traditional software entities.
The implications for Chief Information Security Officers (CISOs) and Chief Information Officers (CIOs) are evident:
AI agents need identities.
However, identity alone is insufficient. AI agents require governed identities.
Limitations of Traditional IAM Approaches
Conventional IAM frameworks typically operate based on relatively static concepts:
User → Role → Permission → Application
In contrast, AI introduces a significantly more dynamic model:
Human → Agent → Intent → Context → Tool → Data → Action
For example, when an employee interacts with an AI agent:
“Find the latest customer renewal risks and prepare recommendations for my accounts.”
The agent may need to:
- Identify the employee.
- Determine whether the employee is authorized to access those customers.
- Retrieve CRM information.
- Query analytics systems.
- Access customer-support records.
- Invoke an AI model.
- Generate recommendations.
- Potentially update a business system.
This scenario raises a critical security question:
Should the agent inherit everything the employee can access?
This approach is not advisable. Such a practice would significantly increase the potential impact of security breaches.
Instead, access should be dynamically determined based on:
- Who initiated the request?
- Which agent is executing it
- What the agent is trying to accomplish
- What data is being requested
- Which application is being accessed
- The sensitivity of that data
- The current risk level
- The agent’s behavior
- The duration of access
- Whether the action is read-only or transactional
This context illustrates how AI can fundamentally transform IAM practices. More will follow in my next blog on this topic
