One of the core topics throughout 2026 has been that of Identity & Access Management (IAM) for agents.
We’ve watched agent adoption take off, especially for use cases such as coding, leveraging agentic coding tools but also for broader knowledge work (e.g. cowork) and of course agents in the cloud and SaaS environments as well.
The industry is grappling with what I’ve been framing as the Security vs. Utility tradeoff. Agents need access to be useful but that access is also what makes them risky, and organizations are striving to find a balance between the two, and as we know in security even in prior technological paradigms pre-AI, security often loses that battle.
We already know we have best practices such as least-permissive access control, or proper identity lifecycle management, the challenge is we already did poorly at these with on-premise identities and in the cloud and now AI and agents are adding strain to an area of security we already struggled with.
In this piece I will be discussing some of those challenges, where the industry is headed, what primitives are emerging and how some teams, such as Resilient Cyber partner Token Security, are tackling the problem.
So, let’s spend some time at the intersection of agents and IAM!
If your organization is putting AI agents into production and you can’t yet say which agents exist, what they can reach, or whether their access matches what they actually do, that’s the gap Token Security was built to close. Resilient Cyber partner Token Security gives teams an inventory of their AI agents and the identities behind them, maps that access in context, and helps right-size permissions so agents get only what their work requires.
From NHIs to Agents, What Changed
Identity has already been undergoing significant changes in recent years. As we moved to cloud, microservices, Kubernetes, containerized workloads and more, we saw increased focus on what the industry called “Non-Human Identities” (NHI).
I’ve covered NHIs previously in pieces such as:
We even saw a new OWASP Top 10 for NHI, which I previously covered, because who doesn’t love an OWASP Top 10.
NHIs include identity types such as service accounts, system accounts, IAM roles and other machine-based identities used to facilitate activities in the enterprise with authentication activities oriented around API keys, tokens, certificates and secrets.
NHIs were estimated to outnumber human users 10:1, and now agents are poised to add to that surplus while also inheriting all of the challenges of both human users and NHIs and the industry has been wrestling with how to handle, secure and govern IAM for agents.
I previously laid a lot of those challenges out in my blog titled “Identity is the Agentic AI Problem Nobody Has Solved Yet”, where I used the Coalition for Secure AI’s (CoSAI) excellent Agentic IAM whitepaper as a guide.
As I mentioned then, agents inherit all of the challenges of human users and NHIs such as improper offboarding, secret leakage, overprivileged identities, long-lived credentials and cross-environment reuse while adding new issues as well, such as the fact that access doesn’t automatically equate to authorization, meaning just because an agent has access to something doesn’t mean it is authorized to do specific activities, or that what they are doing in a given moment with that access is appropriate given the context.
Agents also introduce additional security challenges related to IAM, such as their non-determinism, autonomy and delegation. Many of these challenges have begun to be addressed by groups such as CoSAI in their paper above, as well as by others, such as OWASP in their Agentic AI Top 10, where I serve on the distinguished review board.
These challenges manifest at runtime in scenarios such as agents with the same permissions taking fundamentally different actions depending on the prompt they receive, what’s ingested into their context window, or even the overall non-deterministic nature of agents and most notably the LLMs that function as their brain. We also simply aren’t used to governing and securing software that acts or has autonomy. Historically software could be triggered or invoked, but it didn’t necessarily “act” on its own or make decisions that weren’t pre-programmed and bounded, so the concept of least-autonomy is a new one for the security community to adapt to as well.
The industry has largely collectively agreed that agents don’t fit neatly into either category of human user or NHI and that is why we’re seeing papers published with new takes on best practices, new frameworks and emerging protocols for agentic IAM as well, such as updates to OAuth, and the introduction of Agent Auth, which I’ve discussed previously with industry leaders such as Karl McGuinness in a conversation titled “Identity-as-Infrastructure in the Agentic Era”.
Agency Isn’t Authorization
As I mentioned above, the community has begun approaching Agentic IAM from trying to ensure they can understand and govern who an agent is, what it can reach and what it should be doing right now for this task.
This includes defining its authority and on who and what authority are agents acting, as I discussed with Karl, as well as the reality that agency isn’t authorization, as my friend Rock Lambros, Co-Lead of the OWASP LLM Top 10 put it. Just because an agent has the agency and access to do something doesn’t mean it is authorized to do so for a specific scenario or active in a given moment. Rock’s quote is below:
“Agency’s not authorization, period, authorization tells you whether it can do the thing, while agency tells you whether the thing that the agent is doing is appropriate or allowed.”
CoSAI joined the fray with their excellent Zero Trust for AI Systems whitepaper which I previously covered, where they rightfully take the stance that authorization can’t live inside the model. They show a conceptual reference architecture demonstrating that the AI threat boundary is anything within the bounds of the model given it is a non-deterministic system.
Karl made an argument in the discussion with me months ago, which is now becoming an industry consensus, which is that you need “survivable correctness”, where you have enough security controls so that the blast radius is survivable even if the initial sort of mandate or intent for an agent is not 100% correct.
What the Industry Frameworks Say
While I already mentioned the CoSAI paper above, I did want to lay out some of the fundamental concepts and controls it advocates for.
This includes approaching agentic IAM through a three phased adoption path, from visibility through contextual access controls, to full agentic IAM with runtime enforcement. They also provide a capability-impact risk matrix to classify agents from low capability-FAQ bots to high-risk financial or admin agents with consequential permissions to impact production systems.
They also advocate for leveraging short-lived OAuth tokens and on-behalf-of (OBO) chains with scope attenuation at every hop, which ties back to the need to securely govern delegation from human users to agents and even from agents to sub-agents.
While some of these are of course aspirational and protocols and tooling are evolving to help organizations meet them, it is a good indicator of the direction of where things are headed and how enterprises should think about it.
The Uncomfortable Track Record
That said, if we’re being honest with ourselves, the frameworks describe where we need to go much more clearly than they describe where we’re starting from.
In my recent Resilient Cyber podcast episode I sat down with Token Security Co-Founder Itamar, and I mentioned we’ve had twenty plus years to get least privilege right for human users and another fifteen or so for cloud identities, and our track record in large enterprises is not great.
Palo Alto Networks’ 2026 Identity Security Landscape found that 96% of respondents report human identities operating with access far beyond what their roles require, even as machine identities, including AI agents, now outnumber humans 109:1. We have struggled with least permissive access control, lifecycle management and governance for the identities we understand best, and now we’re adding identities that are more numerous, more ephemeral and autonomous on top of them.
If we’ve struggled this much with the identities we understand best, how do we expect to do better with agents that are more numerous, more ephemeral and autonomous? That’s the question I wanted to put to the Token Security team, and it’s where the second half of this piece picks up.
Now for the uncomfortable part when it comes to our history on doing what we know is best. Best practices such as “least-permissive access control” have existed for decades, and were a big part of the earlier Zero Trust movements.
Yet, we performed absolutely terribly at them including recently in cloud, where up to 99% of permissions users/identities had were not necessary or used, meaning accounts were very overly permissive. This is problematic for various reasons but among them is the fact that credential compromise remains one of the leading attack vectors. As the saying goes, hackers don’t hack in, they log in.
When they can use credentials with access, they don’t need to “exploit” anything, just compromise an account or get access to a credential and the malicious actors get broad access.
Now throw agents into the mix when NHIs were already outnumbering human users and the problem is poised to be far worse, especially since agents unlike NHIs have autonomy, the ability to take actions, use tools and make an impact in real production environments on their own.
As we’re seeing with recent incidents, agents don’t even need to be compromised to be problematic, they can simply be “rogue” or put a better way, behave in a way the user didn’t plan or intend for them to.
These challenges are already starting to show up in the enterprise, such as in the Cloud Security Alliance (CSA) report “Autonomous but not Controlled”, which CSA did in partnership with Token Security. It found 82% of organizations had shadow agents in their environments, often with poor monitoring and visibility and 65% of those surveyed had at least one agent-related incident in the past year.
So this begs the question, why would least permissive access control get any better in the age of agents than it was in prior tech waves?
Trends say it won’t, but let’s hope that’s wrong, and there are teams building solutions to try and ensure we get it right this time, including Token Security, which I’ll be discussing next.
Token Security’s Approach
As I mentioned, I recently had a chance to sit down with both of Token Security’s Co-Founders, including a Resilient Cyber podcast episode with Itamar. So let’s take a look at what their stance is on this problem and how they’re approaching it.
Origin and Thesis, Identity as the Control Point
Token’s origin story is a good illustration of why that track record looks the way it does. Itamar Apelblat, CEO and Co-Founder of Token Security, spent over a decade on the defensive side of Unit 8200, where he met his co-founder and CTO Ido Shlomo on their first day of service.
Years later, stuck waiting hours on access approvals during reserve duty, he remembered a service account his team had created roughly seven years earlier, along with its password, and tried it. During the podcast he mentioned “and all of a sudden I was an admin in one of the most secure networks in the entire world.” When he asked why nobody had changed it, his former colleagues said they were scared of what might happen if they touched it.
I know I’ve seen similar situations myself in the DoW and U.S. Federal agencies, where folks didn’t want to touch an account or system because they didn’t want it to break something despite no one being completely clear who it belonged to or what it even did.
Token started in classic NHI security, and about two years ago, while trying to understand who was consuming those NHIs, the team kept finding AI agents on the other end. That led Itamar to a risk model built on two dimensions, the level of autonomy an agent has and the level of access it holds, and his view is that what ultimately matters is what the agent actually does in the target applications.
The risk model he describes has a lot of parallels to the principles in the CoSAI IAM and ZT papers I mentioned above, as well as the conversations I had with industry leaders such as Rock and Karl.
Discovery and the Context Graph
One of Itamar’s points that resonated with me is that traditional IGA treats the IdP as the source of truth, while agents live almost everywhere else, on local machines, inside SaaS applications and across the cloud. As I told him, vendors who started from machine identities are better positioned here than those retrofitting human IAM, given they were already building towards securing machine identities, and while NHIs aren’t a 1:1 to agents due to the novelty of autonomy, there are a lot of similarities.
When Token’s second Co-Founder Ido walked me through the platform, discovery started from the identity side, looking at which identities and data an agent actually touches. Token’s platform deck cites more than 1,000 enterprise integrations feeding an inventory that maps each agent to the NHIs it uses, its permissions, its consumers and a risk rating, and Ido described a context graph tying agents to service accounts, secrets and the human owners who prompt them and remain accountable for them.
What discovery turns up will look familiar to anyone who has read the OWASP NHI Top 10. Itamar described ungoverned agents connecting directly into production with secrets or API keys, inactive agents left over from early experiments, and agents whose owners have left.
During my conversations with the team they highlighted how often agents don’t have a formal owner, or perhaps they left the organization but the agents continue to run and no one has a good answer to who is actually responsible for that agent.
The Token team’s research found that over 16% of its enterprise customers already have Personal AI (PAI) agents such as Muse running locally and interacting with mail and other enterprise resources, and the reality is most organizations have little to no visibility over these types of rapidly emerging agents, let alone any runtime governance or enforcement.
Ido also told me that tracking sub-agent invocations is still a work in progress, which is the delegation chain problem CoSAI flags and part of why I called agent identity the problem nobody has solved yet, and a topic Karl brought up, because the industry is still figuring out how to handle delegation across sub-agents and multi-agent activities when it comes to IAM security.
Intent-Based Access, Scoping by Purpose
This is where the agency versus authorization distinction from earlier gets practical.
When I asked Itamar how identity helps when an agent with legitimate access takes actions that look authorized but may not be appropriate, his answer started with how agents behave. They follow a goal or an intent, almost like they’re possessed as he put it, and will use whatever access they can find to reach it. So instead of trying to catch the moment an agent goes wrong, Token scopes its permissions up front, in the authentication moment, to what its purpose actually requires.
While this makes sense to me in terms of defining access up front, I also know this can be challenging, given agents are non-deterministic and we don’t always know the specific path and actions they will take to accomplish a given task.
Token calls this intent-based access management, and intent-analysis is a topic you’ve likely seen me write about before.
Itamar described two mechanisms, with the first being defining an agent’s purpose, which he says should be crisp and concise, and then restricting its static permissions in each application to match, using the example of an agent built to send a weekly report on customer trends, which for example shouldn’t have deletion capabilities to a database. Since most organizations never wrote those purposes down, Token infers them from the agent’s settings and activity and then verifies them with its owner.
I like this approach because it reminds me of hygiene for agent identity and permissions, being able to clean up scopes and permissions based on what the agents truly use, rather than it just staying what was originally provided to them, especially since we know the latter tends to be overly permissive. The second mechanism analyzes the intent of each specific action against that purpose and the agent’s broader goal.
Mapped back to Rock’s framing, the first mechanism governs what an agent can reach, and the second governs whether what it is doing right now is appropriate and allowed. It also resembles Karl’s idea of authority tied to a mission, and the CoSAI Agentic IAM paper’s call for task-scoped access. Ido showed me the right-sizing side of this, with least-privilege policies generated from actual usage and scope and exported as JSON or YAML for AWS or Terraform.
In my coverage of CoSAI’s Zero Trust paper I noted they acknowledge Zero Trust alone doesn’t stop misaligned reasoning, and intent analysis is an attempt to close that gap.
That said, it is easier said than done of course, as it requires the firm to be actively engaged in verifying an agent’s assigned permissions and activity as authorized and appropriate to facilitate the right-sizing of those permissions.
That aside, proactively monitoring the agent’s activity and encouraging the users to help clean up overly permissive access is the sort of activity that can clean up permissions now, rather than later after an incident exploits them, or an agent goes rogue.
Enforcement, Remediation and the Human in the Loop
That brings me back to the track record question I put to Itamar.
His answer was automation, since IGA and CIEM processes stayed largely manual and never scaled, and agents will far outnumber the humans those processes already struggled with. Token’s approach has two parts, continuously restricting and updating an agent’s permissions in the target applications without a person in the loop, and an inline layer that decides whether to block or allow each action.
When Ido walked me through the inline piece, it took the form of an agentic gateway sitting between agents and the services they call, enforcing policy with context about the environment and the identity involved.
The rule builder evaluates conditions such as department, the role an agent requests and the role it’s using, with actions to allow, monitor, shadow-deny or deny. Ido described the same idea in a recent BleepingComputer piece under Token’s byline, where for the same developer and session “the agent’s call is denied on admin and allowed on read-only,” which is CoSAI’s point about keeping authorization decisions outside the model put into practice.
On remediation, Ido explained that Token requests write permissions so playbooks can de-provision identities, revoke authentication and rotate API keys, with customers mostly starting on the lowest-hanging fruit. Paired with modeling the attack paths an agent can reach, this starts to look like Karl’s survivable incorrectness, bounding the blast radius when an agent gets it wrong.
Human approval in this model is a dial set per resource. Itamar described a customer policy that coding agents never touch production, so an agent that connects to a production Snowflake project gets blocked and an access request goes to a person, and where the crown jewels sit drives whether to block, require approval or allow. In the CSA’s “Autonomous but Not Controlled” survey I mentioned above, 38% of organizations require human approval for risky agent actions while only 11% automatically block them, which suggests approval fatigue is a live risk.
This is indeed a difficult dichotomy, where we want to escalate to humans for critical agent actions that introduce risk, but doing it too frequently can lead to fatigue of the Human-in-the-Loop (HITL) or even blanket approvals, which come with not actually reviewing what is being requested.
Ownership and Where Security Starts
Then there’s the organizational question of who owns all of this.
Itamar’s view is that because agents exist to automate work our employees and workloads already do, the IAM team should manage their lifecycle, with an AI security committee or department influencing the approach and AppSec and data security teams sharing responsibility for the risks those agents introduce.
On where to start, he agreed visibility comes first but said the security teams seeing the most success are the ones adopting agents themselves, and his advice was to have security deploy agents themselves, this way they better understand where the risks are.
This is a perspective I strongly agree with, as I’ve spent this year arguing that security is almost always a late adopter and laggard with each tech wave, and we can’t make the same mistake with AI and agents, and it is much harder to secure something we don’t understand, so it is key that we get exposure to these tools and technologies ourselves.
Ownership will likely look different across organizations as each organization’s teams and governance models are unique. However, I think finding the right model for your organization and ensuring you have effective tooling coupled with proactive governance is key.
Closing Thoughts
Agents are forcing the industry to treat access and authorization as the separate questions they always were.
Token’s bet is that identity is the control plane, and that knowing who an agent is, scoping what it can reach to its purpose and checking what it does at runtime gives us a better shot at least privilege than we’ve managed before, though delegation chains and attribution when agents share human credentials remain open problems.
That said, the principles I discussed above from groups such as CoSAI along with industry leaders and teams like Token provide an opportunity to ensure we get some of the fundamental aspects of agentic IAM correct and avoid perpetuating the problems of the past where we struggled with effectively securing IAM in the cloud and on-prem.
Stay resilient.