The scenario plays out in enterprise security teams with growing frequency. A company deploys an AI agent to help employees draft emails, update customer records and summarize documents. The agent works beautifully. Then the security team discovers that the agent’s account can also read the finance department’s spreadsheets, call payment APIs and browse the code repository, because the permissions it inherited came from a service account that a developer created in a hurry two years ago. Nobody granted those rights deliberately. They accumulated.
A blog analysis circulating in the security community this week argues that the products of Google, Anthropic and Nvidia, the companies building the most popular agent platforms and the hardware to run them, are turning AI permissions into the next major enterprise risk. The argument is straightforward: AI agents can call APIs and access data at a scale that traditional applications never could, but most enterprises have not built the governance systems to control what agents are allowed to do. Security researchers who study the problem call the gap between agent capabilities and agent controls the most dangerous mismatch in enterprise technology.
The technical difference is real. A traditional application has a fixed set of functions and a human user who initiates each action. An agent is different: it plans, it takes sequences of actions on its own, and it decides what to access based on context. Grant an agent broad permissions to be helpful, and it will use them, often in ways the requester did not anticipate. Grant it narrow permissions, and it fails at its job. The autonomy that makes agents useful is what makes them dangerous, and permissions models built for humans, who see a prompt and judge, do not translate to software that acts in milliseconds.
The products in question span the industry. Google’s agent tools connect to Workspace data, calendars, mail and third-party services through OAuth scopes that are often broader than a single task requires. Nvidia’s push to put agents on local machines, through RTX Spark and its OpenShell runtime, moves the problem from the cloud, where central security teams can at least see traffic, to desktops, where agent activity may be invisible. Each of these is a convenience feature and a potential hole.
The permission problem has a name in security circles: scope creep, applied to machines. Analysts said the core issue is that agents inherit permissions from the identities they run under, whether a human user’s account, a service account or an API key, and those identities were typically created before agents existed, with permissions granted for other purposes. An agent that runs as a user with admin rights inherits the admin rights. An agent connected to a data warehouse through a credential with read access to everything inherits read access to everything. The blast radius of a compromised agent, or a misbehaving one, is the blast radius of the identity it runs as.
The industry is scrambling to respond. Identity vendors and cloud providers are building agent governance features: least-privilege toolkits that let administrators define exactly which APIs an agent may call, session limits that cap how long an agent can operate, human-in-the-loop approvals for sensitive actions, and audit logs that record what an agent actually did. The concept of an agent identity, separate from the user who spawned it, with its own permissions and its own audit trail, is emerging as the standard answer. Security researchers said these controls are necessary but not sufficient, because agents are still new and the attack surface is still being mapped.
The enterprise reality lags the vendor messaging. Most companies, according to surveys cited by the blog analysis, have not yet assigned anyone to own agent permissions, and the tools to manage them are immature. The pattern is familiar from the cloud migration a decade ago, when companies moved workloads to AWS or Azure faster than they built the governance to control access, and the result was a wave of breaches. Security professionals who lived through that period say the agent wave is shaping up the same way, only faster.
The stakes are concrete. An over-permissioned agent can leak customer data, exfiltrate source code, trigger payments or destroy records, all while looking like normal activity. A coding agent with write access to production can deploy changes no human reviewed. A support agent with access to customer accounts can be manipulated into revealing information a malicious caller could not get from a human. The failure modes are not hypothetical; security researchers have already documented cases of agents being tricked by prompt injection into taking actions their operators never intended. Those incidents are the canary in the mine.
What worries security professionals most is the combination of autonomy and invisibility. Cloud workloads are monitored; agent activity often is not. A human clicking through a system leaves a trail; an agent moving through APIs can be configured to look like the user it impersonates. The enterprise tools that detect anomalous behavior, built around human patterns, do not yet model agent behavior well. Until they do, the blog analysis argues, the companies deploying agents are running an experiment with their own data as the variable.
The path forward, according to analysts, is boring but unavoidable: treat agents as users with identities, apply least privilege, require human approval for high-risk actions, and audit everything. The vendors that make this easy, that build permissions into their products rather than bolting them on, will win the trust of enterprises that are currently hesitating. The ones that treat permissions as an afterthought will find their products shelved after the first incident. In the race between agent capability and agent control, the control side is behind, and the gap is where the next enterprise breach will come from.
