Connect
It’s 3 a.m., and an AI agent is querying your production database. No ticket was raised. No one was paged. The credential it’s using was granted at setup eight months ago, so your privileged access management (PAM) dashboard shows a valid, authorized connection. That’s all it can show you, because your PAM program was built around people.
Agents are already doing this kind of privileged work. According to JumpCloud’s Agentic IAM Pulse Report, 72% of organizations have AI agents running in production. 31% are running them in business-critical environments such as financial reporting, HR provisioning, and access management.
Every mature privileged access program is built around four core questions: Who’s asking? How long do they get access? Who approved it? And what did they do?
For your human users, these questions are straightforward to answer. For AI agents, the answer isn’t as simple. Not yet. Here’s where each question breaks down for agents, and the control that addresses it.
Who’s Asking?
Traditional PAM assumes a human requester who can prove their identity. Agents work on their own schedule, often when no one is at the desk watching them run. This leads many teams to set their agents up through shared service accounts or as API keys in config files. Only 37% of organizations have fully integrated AI agents into IAM, according to the Agentic IAM Pulse Report.
These agents never get an identity of their own. They borrow one.
The solution to this is a dedicated identity for each agent: its own record, its own authentication, and a named human owner. Every action can then be traced to a specific agent and the person accountable for it. You can also shut the agent off without touching anyone’s employee account. This control comes first, because you can’t scope, approve, or audit an agent you can’t name.
How Long Do They Get Access?
A continuously running agent may need to monitor database capacity throughout the day. But it only needs elevated permissions occasionally. A permanent administrative credential gives it that power between tasks as well.
In JumpCloud’s Agentic IAM Pulse Report, 49% of surveyed organizations said they use long-lived API keys as their primary method of agent authentication. A long-lived credential becomes particularly risky when it carries broad privileges that remain available indefinitely.
Least privilege and just-in-time elevation address different parts of this problem. Least privilege limits which resources and operations the agent can access. Just-in-time elevation makes additional permissions available for an authorized task, with a defined end and a maximum duration.
Who Said Yes?
PAM assumes an approval step, where someone requests elevated access and a person or policy authorizes or denies it. Agents don’t work that way. They reason toward a goal and choose their own next action. If the agent also decides what it’s allowed to do, it’s effectively approving its own request.
Human oversight is already thinning out where it matters most. The Pulse Report found that 46% of organizations allow high-risk actions to proceed without prior human approval. Among business-critical deployers specifically, 24% let agents execute high-risk actions with no human supervision at all.
The MCPTox benchmark tested 20 agents against 45 real Model Context Protocol (MCP) servers and 353 authentic tools, hiding malicious instructions inside the tool descriptions agents read. The most susceptible agent followed the hidden instruction 72.8% of the time.
The point isn’t that agents get attacked. It’s that the same reasoning that makes an agent useful is what gets manipulated, which is exactly why an agent can’t also be the authority on its own permissions.
The solution is a policy that lives outside the agent. Run an external policy check on every privileged action. For actions you can’t take back, such as financial transactions, identity changes, and access provisioning, add a human-in-the-loop checkpoint, where a named person approves before the agent acts.
What Did They Do?
PAM assumes you can reconstruct what happened during a privileged session, and that offboarding closes the loop.
When a project ends, the agent’s credential often stays live, because there’s no clear agent offboarding step. The result is a zombie agent: still authorized, and no longer watched.
A log line that reads “service-account-42 modified the record” doesn’t tell an auditor who did what. Improper offboarding is the top risk on the OWASP Non-Human Identities Top 10.
The solution for this is an audit trail that names the agent, ties it to a human owner, and shows the policy that granted access. Compare the two entries:
- service-account-42 modified opportunity records at 03:14
- RevOps Agent, owned by the RevOps lead, wrote to Salesforce at 03:14 using access granted by the RevOps Agent group policy
The second entry tells you what to do next. You should test your own logs against four checks: which agent performed the action, with whose authority, with what access parameters, and which safeguards to stop it in place. Then make sure you can revoke an agent’s access across every connected system at once.
Make the Answers Part of Your PAM Program
Your next access review should show more than whether or not agents are taking privileged actions across your environment. (They are.) It should show which agents took action, why the operation was allowed, and whether the privilege ended afterward. When those answers are recorded and the limits are enforced, IT can expand an agent’s responsibilities with a clear understanding of the access involved.
Privileged access requests for humans and agents both need the same accountability, with authentication and access duration adapted to how each works.
Download PAM for Every Team and Every Agent to learn how to extend privileged access controls across human, non-human, and agentic identities. Explore JumpCloud PAM or schedule a demo with us to discuss how that approach fits your environment.
