An overprivileged AI agent is an agent whose credentials let it reach more systems and data than anyone explicitly approved — and according to new research published this week, that describes agents at 41% of the organizations in the study. 1Password surveyed 1,000 IT, security, and engineering professionals at U.S. companies with at least 250 employees (fielded May 26–June 3, 2026), and the headline finding is blunt: across the survey, agents touched roughly twice as much data as anyone had signed off on.

The rest of the numbers fill in how that happens. 46% of developers surveyed run AI agents in production today, and 71% of respondents said their agents can reach sensitive information — customer records, source code, HR files. 40% of developers grant agents persistent access to systems and secrets, so credentials stay live after the task that needed them ends. One senior network administrator described a major outage caused by an agent quietly using an expired credential — an incident that took ages to trace because, in their words, audit trails for non-human accounts were "basically non-existent."

The failures are already showing up in incident logs. Among developers who use agents, 33% said their company had a breach or security incident tied to overprivileged non-human identities. 47% have had an agent take an unintended action after following instructions buried in a webpage, document, email, or tool output. And when the survey asked who is accountable when an agent causes harm, the answers scattered across the org chart — 5% said the agent itself, which, as 1Password’s Jason Meller told Help Net Security, "means the conversation hasn’t happened yet."

Why do AI agents end up with twice the access anyone approved?

None of this is caused by careless teams. It’s caused by an architecture gap that repeats at almost every company shipping agents.

First, agent credentials are provisioned without scope limits. The fastest way to unblock an agent is to hand it a credential that already works — a service account, an API key from a config file, a token with the same permissions as the engineer who created it. The survey found about a quarter of developers hardcode credentials into scripts or config files. Every one of those credentials carries whatever access it was born with, not the access the agent’s task actually requires.

Second, identity tooling was built for humans. Access reviews, session monitoring, and DLP tools assume a person is behind the account. When a semiautonomous non-human identity starts opening doors on its own, those tools lose the thread — which is why the expired-credential outage above took so long to trace. There was no owner, no session, and no log designed for the actor that caused it.

Third — and most important — there is no pre-execution enforcement layer. Visibility tools can tell you, after the fact, that an agent read a system it shouldn’t have. Nothing in the default stack evaluates the action before it runs and blocks it when it exceeds approved scope. That’s the difference between the 2x figure being a dashboard alert and it being impossible by construction.

The 47% injection figure follows from the same gap. An agent steered by instructions embedded in a webpage isn’t malfunctioning — it’s faithfully doing what agents do. If nothing between the agent and the tool call checks the action against policy, the injected instruction executes with the agent’s full (over-provisioned) permissions.

What should teams check right now?

Before any tooling decision, three checks are worth running this week.

Inventory your non-human identities and their scopes. List every credential an agent can use — service accounts, API keys, OAuth grants, tokens in config files — and compare what each can reach against what the agent’s task requires. The survey’s 2x figure suggests most teams will find the gap larger than expected.

Expire what should have expired. 40% of developers grant persistent access; task-scoped work rarely needs standing credentials. Rotate anything hardcoded, and set expiry as the default for new agent credentials rather than an exception.

Log non-human actors as first-class citizens. If an agent-caused failure took your team days to trace, the problem isn’t the failure — it’s that your audit trail doesn’t record which agent did what, with which credential, and why. Make agent identity a mandatory field in your logging before the next incident, not after.

How Waxell handles this

The survey describes a gap between what agents are approved to do and what they can do. Waxell’s position is that this gap closes with enforcement, not observation — a dashboard after the fact is not governance, it’s an autopsy.

Waxell Observe instruments the agents you build with 2 lines of code and evaluates every action against policy before it executes. Its 50+ policy categories include Identity, Audit, Control, and Privacy — the exact axes the survey found unmanaged. A scope policy makes the 2x problem structural rather than statistical: an agent whose task touches the billing database simply cannot read HR files, whatever its credential technically permits. Enforcement runs at 0.045ms p95, so governance doesn’t tax the agent it governs, and every evaluated action lands in a durable audit trail keyed to the agent’s identity — the trail the survey’s respondents said was "basically non-existent" for non-human accounts.

For the assistants and tools your team didn’t build, the Waxell MCP Gateway puts one governed endpoint in front of 160+ upstream connectors. Identity resolution ties every tool call to a specific person and agent across three auth modes, and offboarding revokes all upstream OAuth grants in one transaction — closing the lingering-credential pattern the survey found among 40% of developers. Injected instructions hit a prompt injection scanner and human-in-the-loop approvals before a destructive action runs, instead of executing with whatever permissions the agent happens to hold.

Ungoverned, this failure mode has a name from the survey itself: scope creep, with agents touching twice their approved data and 33% of companies already paying for it in incidents. Governed, an agent’s reach is its approved scope — enforced before execution, recorded after.

FAQ

What did the 1Password 2026 AI agent survey find?

1Password surveyed 1,000 IT, security, and engineering professionals at U.S. companies with at least 250 employees, fielded May 26–June 3, 2026. Key findings: 46% of developers run AI agents in production, 71% say agents can reach sensitive data, agents touch roughly twice as much data as was approved, 40% of developers grant persistent access, 47% have seen an agent take an unintended action after following embedded instructions, and 33% report a breach or incident tied to overprivileged non-human identities.

What is an overprivileged AI agent?

An AI agent whose credentials allow it to access more systems, data, or actions than its task requires or than anyone explicitly approved. It usually results from reusing existing service accounts or human-scoped credentials rather than issuing task-scoped, expiring ones.

What is a non-human identity (NHI)?

A non-human identity is any account or credential that acts without a person behind it — service accounts, API keys, OAuth grants, and now AI agents. Traditional access tooling assumes a human actor, which is why NHI activity is often invisible to standard audit and monitoring.

Why can’t observability tools alone fix agent overreach?

Observability records what happened; it cannot prevent an action that exceeds approved scope. Closing the gap the survey measured requires pre-execution enforcement — evaluating each action against policy before it runs — plus scoped, expiring credentials and identity-keyed audit trails.

Who is accountable when an AI agent causes harm?

The survey found no consensus — respondents scattered accountability across the org chart, and 5% named the agent itself. 1Password’s Jason Meller argues accountability should sit with whoever authorized the agent’s access. Governance platforms make that answerable by recording which person approved which scope for which agent.

Sources

• 1Password (Elaine Atwell), 1Password’s research finds AI agent adoption is outpacing governance — July 28, 2026

• Help Net Security (Mirko Zorz), Your AI agents can reach data no one approved — July 29, 2026

Your agents are already touching twice the data anyone approved — the survey just measured it. See every agent, scope every credential, and enforce the boundary before execution. Start free with Waxell Observe — pip install waxell-observe, 2 lines of code, free during beta.