Most organizations are rolling out AI faster than they’re securing the identities it runs on. In Delinea’s research, 87% of IT and security leaders say an AI tool or agent exceeded its intended scope in the past year, and 46% admit identity governance is deficient around non-human identities.
The gap is where the risk sits, and it’s why Delinea launched the AI Identity Security Briefing Series.
One idea ran through every session. An AI agent rarely has to break into your environment; it logs in with access you already granted and moves at a speed no human attacker could ever match. The incidents we walked through weren’t new kinds of attacks. They were the same identity failures teams have always faced, exploited at machine speed.
Part 1 just wrapped after six weekly sessions on the first of security’s two jobs with AI: defending against AI-driven attacks. There’s a lot of noise around AI right now. These six sessions stayed grounded, showing how the attacks unfold, the gaps they exploit and what actually stops them.
Jason Mitchell, EVP of Product and Technology
I opened the series with the attack on Hugging Face. OpenAI had put a set of test agents in a sandbox, handed them a benchmark and told them there were no rules. The agents escaped the sandbox, found the answers hosted on Hugging Face and broke into the platform to get them. Thirteen hours after first touching Hugging Face’s public site, they had full cluster administration. By the time the security team shut them down, two and a half days later, they’d taken 17,000 actions.
The agents moved freely wherever the credentials were exposed. They found cloud keys, a database password and a platform token sitting in plain text on the cluster. One credential had been tagged as a cluster admin on both clusters, a mistake any DevOps engineer could make. But they were stopped wherever they hit an actual control.
A role refused a change they attempted, and when they reached the one credential store where least privilege was configured properly, all 84 of their requests were denied. That is the case for limiting blast radius: the attack spread exactly as far as the weakest controls allowed.
Ravi Parathasarathy, VP of Product Management
Ravi Parthasarathy, VP of Product Management, opened with a different kind of incident. At Vercel, a third-party AI tool had been given a persistent OAuth grant into an employee’s workspace. Somebody had approved it once, and nobody thought about it again. When that employee’s desktop was compromised, the cyber criminal didn’t need an exploit, because the grant was live, the environment was reachable, and the credentials were sitting where they’d always been.
That is standing access: access that exists whether or not anyone is using it. It rarely gets granted on purpose; it just piles up. Hand an AI agent that person’s work, and it inherits all of it.
Least privilege helps, but it only limits what an agent can reach. The access is still there. Zero standing privilege (ZSP) goes a step further: there’s no baseline access at all, so an agent gets whatever it needs for one task and nothing after. In practice, the requester never actually holds the credential. They connect through a broker that checks each request against policy and injects the credential along the way, then keeps evaluating the session and revokes access the moment something drifts. As Parthasarathy put it, nobody, human or agent, should be holding the credentials to your critical systems.
David McNeely, CTO
David McNeely, Delinea’s CTO, took on one of identity’s difficult questions: what does multi-factor authentication mean when the requester isn’t a person? A machine can’t approve a prompt or scan a fingerprint the way a person can. It usually gets its identity straight from a credential, often a shared secret that can be stolen, copied or replayed. People are different.
A broad role is usually safe in human hands because nobody wants the HR conversation that comes with abusing it. An agent has no such instinct, and it will use the full reach of a credential to finish the task. McNeely compared it to a summer intern you’ve just hired. You don’t hand over the keys and walk away. You watch everything they do.
The answer isn’t a second factor; it’s a clean identity. Every agent gets its own, tied to proof of where it’s running and a named person its activity traces back to. Static shared secrets are replaced by short-lived, federated credentials. When a customer asked whether rotating these credentials every 90 days was enough, McNeely’s answer was no, not even close.
A credential issued to an agent should live just long enough to log in, then expire. And since an agent usually acts under its user’s credentials, the two can be told apart by which process opened the connection, so the agent runs with a tighter set of rights than the person who launched it.
David McNeely, CTO
McNeely also led the session on the accounts nobody owns. The numbers he sees in customer environments are hard to manage before agents even enter the picture. Organizations routinely carry tens of thousands of service accounts, some reach hundreds of thousands, and one customer has more than half a million.
According to the Delinea 2026 Identity Security Report, machine identities outnumber humans by about 82 to 1, and agents make that worse in a way a count can’t capture. Agents will come and go faster than any inventory can follow. An inventory would be ideal, but shadow AI makes it nearly impossible, so the better first move is making sure no human or agent holds the credentials to your critical systems.
You still need an owner for every account. The ones that cause trouble are the service accounts that someone set up and left behind, still running with no one to explain them. Give every account a named owner who can say why it exists and what it’s allowed to do, and every agent a sponsor whose rights are the ceiling and who can be found when something goes wrong. As McNeely put it, put a person inside every log entry.
Pierre Mouallem, CISO
Pierre Mouallem, Delinea’s CISO, started where attackers do: with what’s already misconfigured, because logging in is easier than breaking in. The gaps are familiar. In the identity provider, it’s the conditional access policy nobody tightened or an MFA exception granted for one account and one task. In the cloud, it’s a permission that was supposed to be temporary and never got narrowed.
In SaaS, it’s the integration somebody connected two years ago that still has a token and no owner. An agent doesn’t go looking for those gaps; it just uses them, running every permission it has with no idea the exception was meant for someone else.
A stricter prompt wouldn’t change that. A prompt can shape what an agent tries to do, but it can’t enforce what the agent is allowed to do once the access is already there. That job belongs to the identity layer. And the fixes, Mouallem noted, aren’t new: posture checks across your identity provider, cloud and SaaS, an owner for every non-human identity (NHI), and reducing standing access so an agent only ever gets what a task needs.
Jason Mitchell, EVP of Product and Technology
For the field notes, I looked back at the past six months of customer and prospect conversations. The concern now at the top of the list wasn’t there a year ago: third-party and vendor access into production. A contractor or managed service provider logs in from a machine no one controls, and everything they reach is suddenly exposed through a door the security team can’t see.
The rest are the gaps these sessions keep circling back to, standing admin rights, service accounts no one remembers owning, and secrets sitting in pipelines where they’re easy to find.
The breaches in the headlines follow the same pattern. The Binance attack traced back to overprivileged standing access and a single high-risk command that ran on a server with nothing to check it. It’s the same shape as the Hugging Face and Vercel incidents. A known vulnerability opens the door, and an over-permissioned credential someone left lying around does the rest. AI hasn’t invented a new kind of attack; it has made the old one faster.
Each speaker closed with their own next steps. Pulled together, they came down to five things:
Find out what can reach your critical systems. You can’t catalog every agent, but you can map every credential and NHI that can touch your production databases and sensitive data. Sort them by how much power they hold and how old they are, fix the top 10 first, and run posture checks across your identity provider, cloud and SaaS.
Get credentials off the endpoints. Find and remove saved keys and passwords on developer workstations and agent hosts, and be explicit about which credentials an agent may use. For the systems themselves, route access through a broker that injects the credential, and use short-lived credentials wherever the target supports them.
Reduce standing privilege where the risk is highest. Apply ZSP to your most sensitive systems first, so access exists only for a task and disappears when the task is done.
Give every NHI a person. Service accounts need a named owner who can say why they exist. AI agents need a human sponsor whose rights set the ceiling and who gets the call when something goes wrong. Local admin accounts need an owner and a rotation schedule.
Watch the session, not just the login. Turn on attribution so your tooling can tell an agent’s actions from the user’s and apply tighter policy to the agent, then keep checking what it does once it’s in and end the session the moment it drifts. Build detection baselines from agent behavior, not human.
Across all six sessions, the answer kept coming back to identity. These attacks succeed on access that’s already there, and the defense is the discipline you already know, with far less standing privilege. That’s the first of security’s two jobs with AI. The next six sessions take on the second, adopting AI safely, starting November 18, 2026.
Watch the Part 1 recordings and takeaways, and register once for the AI Identity Security Briefing Series to get all sessions.