Think about the last time you onboarded a new employee. You set up their accounts, figured out what systems they needed access to, and provisioned the right permissions. When they changed roles, you updated the access. When they left, you revoked it.
Now think about the last time you deployed an AI agent. Did you do any of that?
Most organizations haven’t. Agents get stood up quickly, given broad access to get the job done, and left running—often with no clear owner, no defined scope, and no process for ever reviewing what they can touch. It’s the same mistake enterprises made with service accounts and API credentials a decade ago. Just faster, and with systems that can actually make decisions.
Identity security was never really about people to begin with—or at least, not mostly. Human identities are a small slice, maybe one or two percent. The rest is machines: cloud workloads, DevOps pipelines, SaaS integrations, automation scripts, service accounts. All of them authenticate. All of them need access. And most of them exist outside whatever identity governance program the security team is actually running.
AI agents don’t create a new problem here. They just turn up the pressure on one that’s been building for years.
Agents That Act Like Employees, Without the Accountability
I’ve made this comparison before and I’ll keep making it: AI agents work like a team reporting to you. When you’re the CEO, you don’t do everything yourself. You tell the VP of Finance to handle the budget, the head of IT to manage infrastructure, and the sales director to run the pipeline. They do their work, report back, and you make decisions based on what they surface. AI agents are the same model—just available to everyone, not just executives.
The difference is that a human employee has context. They’ve been around long enough to know that “clean up the records” probably doesn’t mean delete the production database. An AI agent doesn’t have that. It does exactly what the permissions allow—and if those permissions are broader than the task requires, there’s nothing stopping it from using them.
There’s already case law on what happens when this goes sideways. An airline deployed an AI chatbot for customer service. The chatbot made a pricing commitment to a customer. When the airline tried to say “that was the AI, not us,” a court disagreed. You deployed it. You made it your proxy. You own what it does.
The Question That Keeps Getting Skipped
Security leaders ask a lot of questions about AI. Is the model safe? Is the training data clean? What happens if someone manipulates the prompt? All worth asking. But there’s a more basic one that tends to get skipped: what does this agent actually have access to?
In practice, the answer is usually “more than it needs.” An agent set up to summarize customer data ends up with read access to the whole database. An agent tasked with scheduling ends up with write access to calendars it was never meant to touch. Precise access is harder to configure than broad access, so broad access is what happens.
Least-privilege isn’t a new concept. It’s been a cornerstone of identity security for decades—any identity, human or machine, should only have access to what it actually needs for the task at hand. Applying it to AI agents is harder because the scope of “what they need” can shift, especially when an agent is chaining together complex, multi-step workflows. But harder isn’t the same as impossible, and “it’s complicated” isn’t a governance strategy.
Danny Brickman, co-founder and CEO at Oasis Security, has worked extensively on the non-human identity problem. He framed it simply when we spoke. “When we’re working with agents, we need to scope them as well as we can,” he told me. “Give them permission only on what we need—or give a protection mechanism so something funky cannot happen.” His example was concrete: if you want an agent to read a database and summarize it, give it read permissions only. Not write. Not delete. Read is enough.
The catch is that scoping isn’t how most people naturally think about delegation. We say “handle this” and move on. We don’t say “handle this, but only with read access to these three tables, and no permissions outside this service boundary.” Getting to that level of precision—before the agent runs, not after something breaks—is a real organizational shift.
The Governance Gap Is Already Open
Agents are already running in enterprise environments—in customer support, DevOps, finance, and HR. This isn’t a future problem to plan for. It’s a current exposure to manage.
Cloud adoption outran cloud security by years. SaaS sprawl created identity and data governance problems that organizations are still cleaning up. Every time a new wave of technology moves faster than the programs designed to manage it, the same thing happens. And the response is always some version of “we’ll secure it once we understand it better.”
Brickman said it directly: “Right now, what we’re hearing is innovate first, secure later. We know the result of those statements.”
AI agents are more capable, more autonomous, and more deeply embedded in business processes than the automation technologies that came before them. The exposure compounds faster.
What To Actually Do About It
Security organizations don’t need to build something entirely new here. The disciplines already exist—identity security, access management, lifecycle governance. The work is extending them to cover non-human identities, including agents.
The first question to answer is how many agents are running, what identities they’re operating under, and what they can actually reach. A lot of organizations can’t answer that right now. That’s the gap to close before anything else.
From there, the same controls that apply to any privileged identity apply here. Define the scope before deployment. Enforce least-privilege access. Monitor for behavior that falls outside the expected pattern. Have a process for revoking access when the agent’s purpose ends—because, unlike employees, agents don’t resign.
None of this needs to wait for some future generation of AI governance tooling to mature. The framework is there. Most organizations are just still treating agent deployment as a software decision rather than an identity decision—and those are not the same thing.
