Presented by JumpCloud
Least privilege has always rested on a straightforward idea: give an identity only the access it needs to do its job. AI agents are making that harder. Their work can change quickly, their access can span multiple systems, and their actions may happen without a person at the keyboard.
There’s another challenge underneath the permission problem: being able to prove that access was appropriate in the first place.
Here at JumpCloud, we’ve done new research that found that only 12% of organizations describe their AI permissions as tightly scoped and easy to review, while nearly half say permissions are broad, difficult to review, or inconsistent. Even fewer, 14%, review AI permissions continuously or automatically.
Yet nearly every IT leader surveyed (99%) is confident in their ability to audit AI activity, while only 37% are fully prepared with the records, logs, and evidence an AI-related audit would require.
That gap points to a larger change for identity and access management. With AI agents, least privilege can’t end when a permission is granted. IT needs to know what an agent can access, whether that access is still appropriate, what the agent did with it, and whether there’s evidence to prove it.
Least privilege gets harder when the “job” is dynamic
Human access management has never been perfectly static. People change roles, join projects, and sometimes keep access longer than they should. But the basic model is understandable: identity is tied to a person, permissions generally follow a role, and access gets reviewed over time.
An agent’s job can be more fluid. Completing a workflow may require several applications, APIs, data sources, or infrastructure, with permissions evolving as new integrations are added or responsibilities change.
Authentication adds another challenge. Among organizations using agents, 63% use higher-risk approaches such as shared service accounts or long-lived API keys alongside stronger authentication methods. These can make it harder to reliably attribute activity to the agent responsible for it.
Least privilege starts with knowing which identity is acting, what it’s there to do, and who is accountable for it.
Periodic access reviews can only tell you so much
Traditional access governance often relies on periodic reviews. But agent access can change between them as integrations are connected, systems are added to workflows, and permissions evolve. Nearly half of organizations review AI permissions monthly or quarterly, while only 14% do so continuously or automatically.
The research also found that 61% of organizations with weaker or reactive review practices report broad or inconsistent permissions.
Periodic reviews still have value, but they provide a snapshot of an access model that may continue changing. Maintaining least privilege for agents means keeping identity, permissions, and purpose connected throughout the lifecycle.
Least privilege also has to be provable
Giving an agent the right permissions is one thing. Demonstrating later that those permissions were appropriate, and that the agent stayed within them, is another.
Only 36% of organizations surveyed can fully prove that AI had only the permissions it needed. Fewer than half can fully document what action an AI agent took, which identity authorized AI activity, or whether that activity complied with policy.
The stakes increase as agents gain autonomy. More than half of organizations surveyed use or test agents capable of changing systems, permissions, records, or workflows. Yet among organizations using agents, 59% haven’t fully integrated them into the IAM policies used for human users.
A permission policy tells IT what should have happened. The audit trail shows what actually did. IT needs both to establish which identity acted, what permissions it had, who owned it, and whether the activity stayed within policy.
Compliance can’t be a point-in-time exercise
Compliance has traditionally involved a lot of looking backward: gathering records, reviewing permissions, reconstructing activity, and assembling evidence that controls were in place. Agentic systems put pressure on that model because identities, permissions, and activity can change much faster than an audit cycle.
For agents, a more continuous model means maintaining visibility into identities and access, keeping permissions aligned with the work being performed, adjusting or revoking access as that work changes, and preserving evidence along the way.
In practice, that might mean giving each agent a distinct identity and accountable human owner, using scoped or time-bound permissions where appropriate, avoiding standing privileged credentials, and applying additional oversight to higher-risk actions.
The point isn’t to make every agent stop and ask a human for permission. It’s to make the controls reflect what the agent is actually doing.
Agentic IAM makes the identity model catch up
Agentic identity and access management (IAM) extends the identity disciplines IT already uses to a workforce that increasingly includes AI agents:
Discovery identifies the agents operating in the environment.
Registration establishes an agent as a distinct identity with a purpose and human owner.
Management connects that identity to the access required for its work.
Governance keeps permissions and activity under review as the agent’s role changes.
Discover. Register. Manage. Govern. That lifecycle gives least privilege something a one-time permission decision can’t: context over time. An agent’s access stays connected to what it is, why it exists, what it should be doing, and what it actually did.
The underlying principle hasn’t changed. AI agents still shouldn’t have more access than they need. What changes is what IT has to do to uphold it.
Granting the right access is only the beginning. Teams also need to keep it current, understand how it was used, and maintain the evidence to show that their controls held up.
In the agentic era, least privilege has to be continuous, and it has to be provable.
Greg Keller is CTO and Co-founder at JumpCloud.
Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. For more information, contact sales@venturebeat.com.