Enterprises are deploying AI agents into production faster than most can answer a basic operational question: what can this agent reach? Ask a security team leader how many agents are already live inside their company’s environment, and the honest answer is usually an estimate, not a count.
One Gartner analysis projects that Fortune 500 companies will run more than 150,000 AI agents each by 2028, up from 15 or fewer in 2025. Alarmingly, only 21% of organizations report a mature governance and monitoring program for Agentic AI already in use, and even those are falling short.
This gap sits at the center of the adoption story, not beside it. The decision to deploy an agent and the decision to scope its access happen on different timelines, made by different people, and the second decision often doesn’t happen at all.
AI adoption and access control shouldn’t run as two separate tasks, but they regularly do. The mistake underneath that split is that many treat agents like software you ship, when it’s really an identity that can act across your environment from its first task, with whatever permissions it inherited on the way in. That distinction sounds academic until an agent hired for one narrow job turns out to have the run of everything around it.
Agents inherit access, they don’t earn it
Non-human identities, including AI agents, now outnumber human users by an average of 45:1across enterprise environments and up to 144:1 in cloud-native environments, with many of them operating with access far beyond what their role requires.
Agents typically inherit the permissions of the systems, service accounts, or humans that provisioned them, rather than getting scoped individually to the task at hand. For example, an agent built to summarize support tickets can, by inheritance, end up with reach into billing systems, customer records, or admin consoles nobody intended it to touch.
An agent treated as software ships the moment it works, and that inheritance creates countless potential risks, none of which are flagged as a problem until they become one.
The reason is structural, not accidental. The team that ships the agent and the team that owns its access are rarely the same team working the same timeline.
The harm doesn’t require a new attacker, only an existing one finding a new lever
Security teams have spent the past years bracing for AI-driven attacks, as attackers ramp up their use of AI. An emerging, and no less immediate exposure is what happens when an organization’s own agents, running continuously and at machine speed, get manipulated into acting against it. In one early-2026 incident, attackers poisoned log entries inside a monitoring platform with hidden instructions, causing its AI assistant to misread the text as a command and exfiltrate data through a rendered image link. Reviewing that case alongside similar ones from the same quarter, the Cloud Security Alliance traced the blame to the default, broad permissions granted to the agents, as opposed to the sophistication of the attack itself. No novel exploit was required, only an agent that already had more standing access than its one job called for.
OWASP’s GenAI Security Project called this pattern excessive agency, the risk created by granting a model or agent more standing permission than any single task requires. Closing that gap does not call for a model that reasons more carefully. It calls for the same access discipline missing at deployment, namely an owner who scopes the agent’s boundary before its first task runs, not a monitoring layer bolted on after deployment or following an incident.
Why this keeps getting filed as a technical backlog instead of a leadership problem
Gartner predicts that by 2027, 40% of enterprises will demote or decommission autonomous AI agents, not because the underlying model failed, but because these gaps only surface after a production incident forces the issue. This prediction is based on the above-mentioned pattern where leadership is forced to face the “they have access to what” question only after deployment and under incident pressure, instead of before it as a condition of shipping.
The sequence is not a coincidence. When adoption and access run separately, the team launching the agent is rarely the team accountable for what it can reach, they just care that it can perform the task they requested.
A 2026 Data Breach Investigations Report found that ransomware, which depends on reaching and locking down an organization’s valuable systems once an attacker is already inside, was present in 48% of all breaches. Attacks will never end, but what it can reach once it’s in is still what decides the damage. Enterprises are slowly, but painfully, relearning that lesson with agents instead of intruders. While the entry points keep evolving, the size of the impact still comes down to what was left reachable in the first place.
Boundaries need to be built in before or during deployment, and built where access actually lives, not in the agent’s prompt, and not in identity rules on their own. What an agent can reach is a function of identity and network paths together, scoped to the functional minimum and enforced at the infrastructure layer, through the controls a company already runs and not inside the model’s instructions. An owner should be able to see what every agent can touch, narrow it to what the task actually needs, and prove the change is safe against a model of the real environment before any of it ships.
The reasoning inside agents will keep improving. It will also keep being unpredictable, a target for manipulation, or plainly wrong in ways no amount of prompt engineering can erase, so protections need to be set from the start, not from the day after a crisis or one luckily avoided.
What leadership can decide today has little to do with how well an agent reasons but everything to do with how far that agent can go the moment its reasoning fails.
