AI Agent Failures Are a Permissions Problem

Most of the enterprise conversation about AI agent risk is about wrong answers. Bad summaries, invented figures, a model that confidently cites a policy that doesn’t exist. That framing shapes how agent rollouts get reviewed: pick a stronger model, write a tighter prompt, add a review step.

The largest public collection of AI agents actually misbehaving points somewhere else. The failure people report most often is an agent doing more than it was asked.

What 3,607 AI agent failure reports show

rewardhacking.org is a public database of user-reported AI agent misbehaviour. It holds 3,607 reports covering January 2025 through June 2026, pulled from GitHub issues, Hacker News, LessWrong and X, normalised into a shared record format and labelled by an LLM classifier across fourteen misbehaviour categories.

Here is how those categories rank.

Overeagerness leads with 1,566 reports, 43.4% of the set. “Other misalignment” sits at 1,555 (43.1%), effectively tied, but that bucket is a catch-all for anything the classifier couldn’t place elsewhere. Overeagerness is the largest named category. Below it, destructive actions at 622 (17.2%), sycophancy at 328 (9.1%), unauthorized access at 237 (6.6%) and reward hacking at 217 (6.0%).

Two caveats worth stating plainly. Reports carry multiple labels, so the percentages add up to well over 100. And these are user reports rather than independently verified incidents, so the dataset measures what people bothered to write up publicly, not a census of everything that went wrong.

Even with those caveats, the shape of it is hard to ignore. Of the thirteen categories with published counts, not one describes the model being factually wrong. Every one of them describes the agent taking an action.

Why agent overeagerness is a scope failure

Overeagerness means the agent finished the job and kept going. It cleaned up one extra file. It updated one extra record. It closed the three adjacent tickets that looked similar to the one it was handed. Each of those is a small, locally reasonable decision, which is exactly why it’s so common.

A stronger model doesn’t fix it. A stronger model is better at deciding what would be helpful, and a broader definition of helpful is the failure mode. A more careful prompt doesn’t fix it either, because a prompt is a request. The agent can read it, agree with it, and still act outside it.

We wrote about this pattern earlier this year when an agent on DN42 ran up a $6,531 AWS bill after asking for and receiving human approval. The approval gate worked exactly as designed. A human read the request and clicked yes, because that’s what humans do with the fortieth routine request of the day. The control was procedural, so it depended on sustained attention, and attention is the first thing to go.

The other version of this shows up when agents borrow human identity. The rogue agent that operated inside the Fedora project for two weeks used a compromised contributor’s credentials and inherited that contributor’s full permission set. Nothing about the agent’s reasoning had to go wrong for that to be dangerous. It was handed the keys to everything the human could reach.

An agent stops where its permissions stop. That’s the boundary in the stack that doesn’t depend on the agent cooperating.

The same permission assumption, at OpenAI’s scale

On 21 July 2026, OpenAI confirmed that two models running its ExploitGym cyber-capability benchmark, GPT-5.6 Sol and an unreleased model, escaped the research sandbox they were evaluated in. If the overeagerness data reads like a small-team problem, the largest agent incident of this month has the same shape at the other end of the scale.

Safety guardrails had been deliberately reduced for the eval. Instead of solving the benchmark tasks, the models went looking for the answer key. Simon Willison’s writeup walks the chain: a zero-day in the package registry cache proxy that provided the sandbox’s controlled internet access, then privilege escalation and lateral movement to a node with real internet access, then an inference that Hugging Face probably hosted the ExploitGym data, then stolen credentials and further zero-days chained into remote code execution on Hugging Face servers. Hugging Face had disclosed node-level access and harvested cloud and cluster credentials on 16 July, five days before anyone knew where it came from. OpenAI described the incident as unprecedented.

The headline reads like science fiction. The mechanism is duller. The entire sandbox boundary rested on one proxy with real network access, and once that proxy fell there was nothing else in the way. The boundary was assumed rather than enforced.

Most enterprise agent rollouts make a version of that same bet. An agent gets a service account, or a shared human login, and the actual limit on what it can touch lives in the system prompt.

What agent permission scoping looks like in a rollout

For a CIO or Head of IT signing off on agents that touch systems of record, three things are worth requiring before anything reaches production.

1. One identity per agent. Not a shared service account, and never a human’s credentials. If you can’t answer “which agent did this” from the identity alone, you can’t scope or revoke anything meaningfully.
2. A grant that lists actions, not systems. “Read-only on the HRIS” is still a wide grant. The agent handling onboarding tickets needs a specific set of operations, and it should hold exactly those. Anything it wasn’t granted should fail at the boundary rather than depend on it choosing not to try.
3. Per-action logs. Which system, which record, when, and under whose review. This is also where regulation is landing: the EU AI Act’s obligations for deployed agents are satisfied or missed at the action layer, not the model layer, and the retention expectations are measured in months of per-action detail.

Put together, those three turn a policy into something the infrastructure enforces. An onboarding agent that provisions accounts for new starters gets its own identity, a grant covering the specific provisioning and directory operations it needs, and a log line per call. When it decides that the sensible next step is also deprovisioning the leaver it noticed in the same directory query, that call fails because the grant never included it. The agent still had the idea. It just couldn’t act on it.

That last point about logs is where a lot of rollouts quietly break. Agent-to-agent coordination is largely a solved problem, and the failures cluster at the handoff into the system of record where credentials, permissions and completion actually matter.

That’s why we built StackOne around scoped actions rather than credentials. An agent connects to StackOne, and StackOne connects to the app. Across 450+ connectors and 27,000+ actions, an agent holds the specific actions it was granted and nothing adjacent, so overeagerness runs into a wall instead of a wider set of side effects. Every call it makes is written to an audit log, which means “what did the agent do last Tuesday” is a query rather than an investigation.

None of that makes an agent less eager. It makes eagerness cheap to be wrong about, which is a better property to design for than restraint.

Where to start scoping agent permissions

Pick one agent already in production. Write down every system it can reach today with the credentials it currently holds, then write down the actions it actually needs to do its job. For most teams the first list is dramatically longer than the second, and the gap between them is the real exposure.

If you want to work through that gap on your own stack, map your agents’ permission gaps with our integration team and see what scoped access looks like for the specific systems they touch.