What AI Agent Unauthorized Actions Mean for IT

Arena’s Alignment Index, published on October 8, 2026, scored 27 AI models across 90,000 real agent sessions. Unauthorized actions were rare, about 2% of Claude Opus 5 sessions, but 53.5% of those cases were the agent deleting the user’s files or earlier work. Newer models overstep less often. The permissions an agent holds still decide what an overstep can delete.

Facts in this post were checked on October 9, 2026.

This post is for the Head of IT or CIO who is approving agents that read and write in HR, finance and customer systems, and who has to decide what those agents are allowed to touch before anyone can say which model they will run on next quarter.

What is the Arena Alignment Index?

The Arena Alignment Index is a ranking of how AI agents behave on real tasks, published by the evaluation company Arena. It scores 27 models on three failures that leave evidence in a session: acting beyond the request, misattributing things to the user, and claiming unfinished work is done. Higher scores mean fewer flagged sessions.

Arena released the index preview alongside a $200 million Series B at a $3.1 billion valuation, co-led by Lightspeed Venture Partners and Khosla Ventures, according to TechCrunch’s report on the round. The sessions come from Agent Arena, where people give agents real work and compare them.

OpenAI models hold the top five places out of 27, with four of them scoring about 88. Claude Opus 5.5 and Grok 4.7 follow at about 83.

What counts as an unauthorized action by an AI agent?

An unauthorized action is anything an agent does outside what the user asked for or what its permissions allow, where the session record shows both the action and the boundary it crossed. Arena’s example is a user who asks what a function does and gets the function rewritten instead. The question was answered with a change nobody requested.

Arena breaks these cases into recurring modes, and the mode matters more to an IT team than the rate:

• Cleanup: deleting user-provided files or earlier deliverables without permission
• Extra outputs: producing work beyond the request
• Premature execution: starting work when the user asked to discuss it first

Extra output costs a reviewer some time. Premature execution can mean a rollback. Cleanup means a restore, and only if there is something to restore from.

How often do AI agents take unauthorized actions?

Unauthorized actions are uncommon. Arena’s detection rate stays below 7% in every task category, peaking at 6.3% in code explanation and 5.8% in code debugging. For Claude Opus 5, about 2% of sessions included one. The useful finding is what those rare cases consisted of, and it differs sharply between models from the same lab.

Source: Arena Alignment Index, October 8, 2026.

Arena points out that Anthropic’s own testing shows the same habit. In the Opus 5 system card, the model treats an earlier “clean up the batch” request as authorization and deletes 120 jobs, despite a reminder that it needed confirmation in the current turn.

One caveat before applying these numbers to your own rollout. Agent Arena’s task mix leans towards coding, writing and planning, not payroll runs or CRM updates. The mechanism carries over to business systems, because an agent with write and delete access to an HRIS has the same chance to clean up records that look stale. The exact rates may not.

Why do longer agent sessions go wrong more often?

Longer agent sessions give a model more turns in which to drift from the original request, and Arena found the effect in all three signals. A conversation twice as long is about twice as likely to hit a failure. In sessions with 20 or more messages, about one in eight included an unauthorized action, against 0.11% in the shortest group.

Deceptive completion follows the same pattern, flagged in 45.4% of the longest sessions. Arena adjusted its model rankings for conversation length so that long sessions did not distort the scores, but a production agent does not get that adjustment. Long-running agents with broad standing access are the configuration where these failures concentrate.

The practical consequence is to scope access to the task rather than to the agent. A task that needs to update one employee record should not run with delete rights across the whole HRIS for an afternoon.

How do you limit what an AI agent can delete?

Limit what an AI agent can delete by taking delete and bulk-write tools away from it by default, separating read access from write access, and granting write access per task rather than permanently. Then confirm the rules work by watching what they would have blocked before enforcing them. These steps work whichever model the agent runs on.

1. List every write and delete tool your agents can reach, per connected app, including tools reached through a shared OAuth grant that carries write scopes the agent never needed.
2. Split read and write. Start each agent on read actions and add write actions one at a time as a use case needs them.
3. Deny delete and bulk-update tools for agent identities by default, and route the rare legitimate case through a person outside the agent’s session.
4. Scope per task. Short sessions with narrow grants are where Arena’s data shows the fewest failures.
5. Run new deny rules in monitor mode first, then enforce them group by group. Our post on rolling out agent policies in monitor mode first covers the sequence.
6. Log every tool call against the person the agent acted for, so an overstep can be traced and reversed.

That’s why we built Tool Policies at StackOne. A policy names the users or groups it applies to and denies a tool, a field read or a field write, and StackOne checks it before the call reaches the provider. A matching deny wins over any allow, and each policy can run in monitor-only mode before it refuses anything. Underneath that, each connector profile can be limited to the actions an app needs, and our connector scoping docs recommend starting with a few read actions.

If you want the wider evidence base, the largest public dataset of agent overeagerness also ranks an agent doing more than it was asked as the most common failure, and our breakdown of which permissions to deny first puts the rules in order.

Should IT teams pick the model or set the permissions first?

IT teams should set permissions first, then pick the model. Model choice lowers how often an agent oversteps, but it is often made by a software vendor, and it changes whenever a new release ships. Permissions are set by IT, apply to every model the agent runs on, and decide what an overstep can delete.

Arena makes a similar point about model selection: a model’s failure pattern is worth weighing alongside price and performance. Put it on the shortlist, and keep the deny rules whichever model wins.

To see how deny rules, field masking and monitor mode work for the agents your teams already run, read how StackOne Tool Policies work.