Ask what your AI agent can access, not what it can do. Access is what turns a small mistake into an expensive one. Your agent doesn't need admin rights to your whole database to send one email. If your team can't answer the access question in ten minutes, you already have your answer.
Five months ago I said the AI security conversation was stuck on the wrong question. Everyone was worried about agents going rogue. Since then the numbers got worse.
Machine identities now outnumber humans 109 to 1, and 79% of those are AI agents, according to Palo Alto Networks' 2026 Identity Security Landscape. A year ago that ratio was 82 to 1. Your company hired a workforce it never interviewed.
Why is "what can this agent access" the better question?
"What can this agent do?" describes a job. "What can this agent access?" describes a blast radius. The second one is the number your board cares about, because it tells you how much of the business is exposed when an agent does something nobody planned for. A support agent that reads one order table is a small problem. The same agent with write access to billing is a very different afternoon.
Most teams scope the job and skip the access. The agent gets built to answer refund questions, and somewhere in the setup it gets handed a credential that opens far more than refunds. Nobody made that call on purpose. It happened because the credential was already sitting there and it worked.
You can't scope what you haven't counted. Most companies still can't say how many agents they run, which is the AI agent sprawl problem in one sentence.
How many companies have already been burned by this?
80% of companies say their AI agents have already done things they weren't supposed to do. That's from SailPoint and Dimensional Research. Agents reached systems that were never meant for them and shared data they shouldn't have shared. Some leaked credentials on the way through.
Only 44% have any policy in place for AI agents. 92% say governance is critical. Read those two numbers together and you have the whole picture. Almost everyone knows. Fewer than half have done anything about it.
Nobody's waiting on a product to ship here. This is a decision that hasn't been made yet.
What does it mean to treat an AI agent like a privileged user?
Treat every agent the way you'd treat a contractor with a badge. Four things: access scoped to the job, credentials that expire, a record of every action it takes, and a way to shut it off in seconds. If you can't name all four for an agent that's already running, you're handing over the keys and hoping.
You'd never give a new hire a master key on day one. You'd give them the doors they need, take the key back when they leave, and check the log if something goes missing. Most AI agents get less scrutiny than the summer intern, and they work all night.
Before an agent goes live, there's a shorter version of this check. Can you shut it off, and can you undo what it did? That's the two-question test, and it catches most of what a longer review would.
Why isn't a rogue AI agent the real threat?
The real threat is a perfectly obedient agent doing exactly what you let it do. Nobody scoped it down. It didn't break a rule, because there wasn't one. We didn't lose control of these systems. We gave them the keys and forgot to ask for them back.
Take the AI out of the sentence and this isn't a new security problem. It's identity, access, privilege, and governance. Those are the same problems we've been working on for years, now multiplied by machines that act at speed and scale. An agent can take thousands of actions before a person finishes reading the first alert.
That's also why the fix isn't a wall. Controls that block real work get routed around, even by your best people, which is the bypass problem most security teams learn the hard way.
How do you run the ten-minute access check?
Pick one agent and ask your security team what it can access right now. Time the answer. Ten minutes is generous for a system that's already touching customer data. If it takes longer, the problem isn't the agent. It's that nobody's holding the list.
A good answer sounds like this. "This agent reads from these two tables, writes to none, uses a credential that expires every 24 hours, and we can turn it off from this console." That's an answer. "It uses the service account" is not.
Run it on your customer-facing agent first. That's where a bad afternoon turns into a call from a regulator. And when you get the answer, check the other half: identity proves who the agent is, not whether what it believes is true. That's a separate audit, and it's covered in the belief audit.
What you can do this week
Pick the AI agent closest to your customers and ask what it can access right now
Time how long the answer takes, and write the time down
List every system that agent can read from and write to, on one page
Check whether its credentials expire, and set an expiry if they don't
Name the person who can shut it off, then confirm they can actually do it today
Key takeaways
Machine identities outnumber humans 109 to 1, and 79% of them are AI agents (Palo Alto Networks, 2026 Identity Security Landscape)
80% of companies say their agents have already done something they weren't supposed to do (SailPoint and Dimensional Research)
Only 44% have any AI agent policy in place, while 92% say governance is critical
Access sets your blast radius, so scope it to the job and let the credentials expire
If nobody can answer the access question in ten minutes, that's the finding
Frequently asked questions
Isn't this just normal access management?
Mostly, and that's the good news. You already have the practice and the people. What's different is volume and speed. AI agents outnumber your staff and they act far faster than any review cycle. The controls are familiar. The scale isn't, and that's what breaks a manual process.
Who should own the access question, security or the team that built the agent?
The team that built it should be able to answer it. Security should be able to verify it. If the builder can't produce the list of systems the agent touches, the agent isn't ready for production. Ownership sitting only with security is how the list goes stale within a month.
What if the agent needs broad access to do its job?
Then split the job. Most agents that "need" broad access are really doing several tasks with one credential. Give each task its own scoped credential and you'll usually find that no single path needs everything. If a wide credential really is required, put a human approval in front of the actions that use it.
How often should we re-check what an agent can access?
Quarterly for a formal review, and immediately after any change to the agent's tools, prompts, or connected systems. Access tends to grow quietly. Someone adds a connection to fix a problem on a Friday, and nobody takes it away. The re-check is what catches that.
Does this apply to agents we bought instead of built?
Yes, and vendor agents are often harder to answer for. Ask which systems the agent reads and writes, how its credentials get issued and rotated, who at the vendor can see your data, and how you shut it off without calling support. If they can't answer, that's a finding you can take to your board.
What's the fastest way to shut an agent down if something goes wrong?
Decide that before you need it. A working kill switch is a control you've actually tested, not a plan you wrote down. We've covered what a kill switch looks like and why the backup path matters as much as the primary one.
If you want to see where your own agents stand, there's a free self-assessment at verifiedagents.ai. Five questions, and it takes about four minutes.
So this week, ask your security team one question. What can this agent access right now? Know the answer before your agents decide what to do with it.