Your AI Agent Has a Login. Can You Prove What It Touched?
Ask a security team a simple question this morning: which AI agents can reach your finance system? Most will answer in seconds. Now ask them to prove what those agents actually touched last Tuesday at 14:07. That silence is the story.
JumpCloud's Q4 2026 Pulse Report, built on a survey of 250 IT decision-makers across the US and UK, puts a number on that silence. 72% report a moderate-to-large gap between what their AI may access and what they can prove it accessed. Only 4% say there is no meaningful gap. And 99% of the leaders surveyed said they were confident they could audit AI activity, while just 37% were actually prepared to.
Confidence is not evidence. Every day of our client work confirms it.
The three gaps nobody budgets for
The report frames the problem as three overlapping failures, and the framing is worth stealing for your next board deck.
The identity gap. 55% of organisations now run or test agents that can change systems, permissions, records or workflows. Of those, only 41% have fully folded their agents into the same identity and access management policies that govern human staff. The other 59% manage agents partially, or through a separate set of policies and tools. 63% of agent environments still mix in shared service accounts and long-lived API keys, which is exactly the thing that makes tracing an action impossible six weeks later.
The proof gap. 72% cannot fully reconstruct what an AI touched. Only 34% can fully prove how AI interacted with sensitive data. In the past 12 months, 92% reported at least one AI-related incident or exposure, and 36% investigated a concern without ever learning what the AI had accessed.
The readiness gap. Only 20% of organisations sit in the highest tier of auditability maturity. 64% are moderate: the controls exist, but coverage is uneven and the holes only appear during an audit or after an incident. 30% report shadow AI they cannot fully monitor, and only 14% review AI permissions continuously or automatically.
Read those three together and the conclusion is uncomfortable. The controls are usually present. What is missing is coverage: controls that stop at the sanctioned tool and never reach the connected system, that cover the employees and skip the agents.
Why this is harder than normal IAM
An agent is a badly behaved user by design. It runs on someone's behalf, holds credentials that outlive the task, reaches across ticketing, CRM, finance, endpoint management and identity, and changes behaviour as its prompt or model changes. The evidence of what it did is scattered across three places at once: the AI tool's own console, the system it touched, and the directory that holds the identity. Reconstructing one action means joining all three, and most organisations have never done that join once.
The report also found that organisations run an average of 2.7 AI tools, each reaching into roughly three categories of company system, and that one in three say AI can reach the identity and access management layer itself. That last one should stop the conversation. An agent that can reach IAM is not a productivity tool. It is an administrative principal with a chat window.
The autonomy question has a number
46% of organisations allow high-risk agent actions automatically. Only 18% require human approval before the agent acts. If your agent can pay an invoice, rotate a key or reset a password without a human in the path, you have automated the part of the process where judgement used to live.
We are not arguing for approval fatigue on every click. We are arguing that high-risk needs a written definition, and that the definition should be encoded where the action happens, not in a policy PDF that nobody reads during an incident.
What mature teams actually do
The report closes with a four-stage agentic IAM lifecycle: discover every agent, including the ones IT was never told about; register each one with a purpose, a scope and a named human owner; right-size access so it expires when the work does; and govern continuously, because agent permissions drift faster than quarterly reviews can catch.
Most teams stop at stage one, sometimes two. Here is the version we run with clients, in the order that produces evidence fastest.
- Inventory agents like you inventory SaaS. Pull every OAuth grant, API key and service principal, then map which ones belong to an agent and which human owns it. No owner, no access.
- Kill the shared accounts. An agent on a shared service account cannot be attributed to anything. Give each agent its own identity and short-lived credentials, and the proof gap starts closing the same week.
- Define high-risk in code. Payments, permission changes, data exports, production writes. Anything on that list gets a deterministic gate, not a model's opinion about whether it seems fine.
- Send agent activity to the SIEM you already have. The AI vendor's console is not your audit trail. Keep evidence where your investigators already look.
- Review continuously, not quarterly. Automate the permission review, and treat an agent permission change like a firewall change: logged, reviewed, reversible.
None of this requires buying a new platform on day one. It requires treating agents as a second identity population with the same discipline you applied to humans, and it requires doing it before the incident, not during the investigation.
The takeaway for your team
The uncomfortable number in this report is not 72%. It is 99% versus 37%: the gap between how confident leaders feel and how prepared they are. Confidence that is not backed by logs, scopes and named owners is a liability, because it is what keeps the problem off the roadmap until an auditor or an attacker finds it.
Start with one question this week, and make it concrete: pick your most privileged agent, name its owner out loud, and try to reconstruct its last ten actions from your own logs. If you can, you are ahead of most of the market. If you cannot, you now know exactly where the next quarter of security work goes, and you have a number to justify it.
That is a far better Monday than discovering it mid-breach.