The Real AI Agent Risk Isn't Failure — It's Access

Every Team Has an Agent Now. Almost None Can Tell You What It Can Touch.

Every founder I have spoken to in the last quarter has an AI agent live, in staging, or half-built on someone's laptop. Sales teams have one drafting outreach. Ops teams have one triaging tickets. A few have agents writing directly to production databases because "it was faster than building the approval flow." When I ask what that agent is actually allowed to do — which tables it can write to, which APIs it can call, what happens if it decides to do something nobody asked for — the answer is almost always a pause, then a version of "we haven't gotten to that yet."

That gap is not a rounding error. A new report from Opsin Labs found that enterprise workforce interactions with AI agents grew 14x between January and June of this year, and that 60 percent of those agents are over-permissioned relative to what their actual job requires. Separately, industry research puts production agent adoption at 72 percent of enterprises with at least one agent live, against a governance gap of roughly the same size. The agents shipped. The access controls did not.

The Growth Number Is Real. That Is What Makes This Dangerous.

I am not here to argue that agent adoption is overhyped. It is not. Gartner expects 40 percent of enterprise applications to ship with task-specific agents by the end of this year, up from under 5 percent last year. Banking and insurance already have agents in production at nearly half of surveyed firms. The tooling has genuinely gotten good enough that a small team can wire an agent into a real workflow in days, not quarters.

That is exactly why the permissioning gap matters more now than it would have two years ago, when agents were toy demos with no real access to anything. A slow-moving pilot with bad access scoping is an embarrassment. A production agent with standing write access to customer records, billing systems, or internal tooling, built by someone outside the engineering org because it was faster than waiting for a ticket, is a different category of risk entirely.

What "Over-Permissioned" Actually Looks Like

The Default-to-Admin Pattern

The fastest way to ship an agent is to give it the same credentials the person building it already has. That person usually has broad access, because humans need broad access to do their jobs across a messy week. An agent does not have a messy week. It has one job, run thousands of times a day, and it inherits permissions sized for a human generalist rather than a narrow, repeatable task. Nobody sits down and decides this is correct. It is just what happens when the fastest path to a working demo is reusing an existing API key.

The Ownership Gap

Roughly two-thirds of agents now being built inside large companies are built by people without an engineering background — people in GTM, customer success, and operations who have real domain knowledge and access to tools like Zapier, low-code platforms, and increasingly capable AI builders. That is a genuinely good thing for speed. It is also why security and platform teams are structurally behind: the agents are being created faster than any central team can review them, in places that were never on the provisioning checklist to begin with.

We saw a version of this ourselves earlier this year, building an internal support-triage agent for a client. The first working version had read-write access to the entire ticketing database because that was the credential already sitting in the environment. It worked fine in every demo. It was also one bad prompt away from closing tickets it should never have touched. Scoping it down to read access on the queue and write access to exactly one status field took longer than building the agent's core logic — and it was the part of the project that actually mattered for going live.

Where This Breaks First

Access debt does not show up evenly. Banking and insurance are furthest along in production deployment, at close to half of firms, precisely because they already had access review processes from decades of regulatory pressure — the agent had to fit into an existing scoping discipline rather than invent one. Healthcare and government trail badly, at under a fifth, not because the technology is worse but because there is no existing muscle for reviewing what a new automated actor is allowed to do inside a system that touches regulated data.

This is the same failure mode I wrote about in our post on why most agents never make it to production — the gap between what looks impressive in a demo and what survives contact with a real system. Reliability and access are different problems, but they fail the same way: quietly, in the deployment nobody was watching closely enough.

The Three Scopes Every Production Agent Needs

The fix is not a six-month governance initiative. It is a discipline you can apply to any agent before it touches anything real, and it holds up whether the agent was built by an engineer or by someone in ops who has never opened a terminal.

None of this requires slowing down adoption. It requires treating agent access with the same seriousness most teams already apply to who gets a production database password — a discipline that the projects that actually ship tend to build in from day one rather than bolting on after something goes wrong.

Delegation Was Always the Real Story

I wrote earlier this year about how India's AI story is shifting from adoption to delegation — handing real decisions to systems, not just using new tools. The permissioning gap is what delegation looks like once you get specific about it. Every agent granted write access to a system is a small act of delegation, and right now most companies are delegating faster than they are deciding what they are comfortable delegating. The 14x growth number and the 60 percent over-permissioning number are the same story told from two different angles: adoption is a decision teams are making deliberately, and access is a decision most teams are making by default.

That gap closes one of two ways. Either teams build the scoping discipline in now, while the agents doing real work are still few enough to review individually, or they build it later, after an agent with default access does something a postmortem has to explain. The companies leading production adoption today — banking, insurance — are ahead because they already knew how to do the boring part. Everyone else still has time to learn it before it becomes expensive.

If you are building AI agents that need real access to real systems — not just a demo that looks good in a meeting — that is exactly the problem we solve at Will of Dawn Labs. We scope access as part of the build, not as a fix after launch. You can also book a 30-minute strategy call directly if you want to talk through what a specific agent should and should not be allowed to touch.

— Kaushal Malhotra
Founder, Will of Dawn Labs
willodawn.com/contact