topicsthe AI3 numbers3 guides

agentic AI and over-access

Agents act with their users' permissions, which usually exceed the task. What over-access exposes once software starts doing things.

in one lineAgentic AI over-access is when an AI agent holds permissions far beyond what its task requires.

the numbers

  • 79%of organizations run or test AI agents in productionPwC, 2025
  • 47%of deployed AI agents are actively monitored or securedGravitee State of Agentic AI, 2026
  • 47%of security leaders saw AI agents act outside intentSaviynt / Cybersecurity Insiders CISO AI Risk Report, 2026

all the numbers →

1what agentic AI is, and what over-access means in this context

An AI agent is a system that takes actions autonomously, often in sequence, to complete a task. Unlike a conversational AI tool that generates text for a human to act on, an agent acts directly. It sends emails, creates calendar entries, writes and executes code, interacts with files, calls APIs, and performs tasks in connected business applications.

Agents operate with a set of permissions. Those permissions are typically granted either at the user level (the agent acts with the credentials of the user who set it up) or at an application level (an OAuth grant that defines what the agent can access).

Over-access in agentic AI means the agent holds permissions that exceed what its designated tasks require. An agent that was set up to draft email responses holds read and write access to the user's entire mailbox. An agent that was set up to summarize documents holds access to the entire file storage system. Least privilege was not applied. The gap between task scope and permission scope is the risk.

2why AI agents are routinely granted more access than they need

The over-grant is rarely a decision anyone made consciously.

OAuth scopes are often granted in bulk. When an employee connects an AI agent to work systems, the authorization flow presents a list of requested scopes. Most users accept what is requested. The agent then holds those scopes whether or not it ever needs them all.

The access request is made by the vendor, not negotiated by IT. AI vendors configure the default OAuth request for their product. A vendor that defaults to requesting broad access will receive broad access from every user who connects the tool without IT intervention.

Agents are deployed by enthusiastic users, not by IT. Many AI agents in enterprise environments were set up by people outside of IT who found a useful workflow. They did not assess the access implications before deploying. The governance question was not raised because IT was not in the room.

3what over-access in agentic AI exposes

The blast radius of an AI agent operating with over-access is bounded by its permissions. That boundary is often much wider than the intended use case.

Accidental actions. An agent instructed to "clean up my inbox" but granted full mailbox write access might delete or archive emails the user wanted to keep. An agent instructed to "schedule my meetings" with calendar write access might modify or cancel existing meetings. Autonomy plus over-access plus imprecise instructions produces unpredictable outcomes.

Exploitation through prompt injection. An agent that processes external content (emails from outside parties, web pages, documents) and holds broad permissions is a prompt injection risk. Attacker-controlled content that reaches the agent can include instructions to take actions with the agent's full permission scope.

Credential and data exposure. An agent that holds read access to a full mailbox or document system holds access to everything in those systems. If the agent's connection is compromised, or if the agent itself leaks data through its external model connection, the exposed data set is the full scope of what it can reach.

what it looks like when it goes wrong

Three ways this tends to go, each one taken from a real case.

your company
the gap nobody seesAn agent inherits every permission of the account that connected it.an AI that acts on whatever it reads
  1. howAn email with hidden instructions reaches an assistant that reads every inbox.
    what leavesanything the assistant can seewho ends up with itthe stranger who sent the email
    it happenedEchoLeak / Microsoft 365 Copilot, 2025
  2. howA tool description tells the agent to send files somewhere else.
    what leavesfiles the agent can openwho ends up with itwhoever wrote the tool
    it happenedMCP tool poisoning, 2025
  3. howAn agent with production access ignores the instruction to change nothing.
    what leavesthe live database, deletedwho ends up with ityour customers, who notice first
    it happenedReplit agent database deletion, 2025

4what works

Governance starts with an inventory, and the IdP already holds most of it. The OAuth grant view lists every agent connected to the directory, the scopes each one holds, and the account that authorized it, covering agents configured by IT and those set up by individual employees alike. A short team-level survey catches the informal deployments that never touched the directory. With the list in hand, the useful comparison is task against permission: what each agent is supposed to do, what it can actually reach, and how wide the gap is. Agents holding full mailbox read, document system write, or admin-level directory access deserve the first look, because their gap is the blast radius of any error or injected instruction.

Scoping down is usually possible without breaking the workflow. Most IdPs allow administrators to modify or revoke OAuth grants made by individual users, and a grant that exceeds the task can often be replaced with a narrower-scoped alternative: read-only instead of read-write, one folder instead of the whole document store, a shared mailbox instead of a person's own. The organizations that keep agent access narrow over time pair this cleanup with a simple gate: agentic AI that touches company systems goes through an IT review before go-live, and the review answers what the agent does, what access that task requires, and who is accountable for its actions.

Action-level logging closes the loop. An agent that does something unexpected can only be investigated if every action it took was recorded, and many agent platforms ship with that logging off or partial. Where it is enabled, an incident becomes a log query; where it is absent, an incident becomes guesswork.

on the record

← all topics

your turn

what you can do about it

  1. this week

    List your AI agents and the accounts they act as.

    Then cut each one down to what its task needs, starting with any that can write or delete.

  2. go deeper

  3. if you're not sure where to start

    Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.

    open the checklist →

the letter · every two weeks

one access gap in your inbox, with the fix.

Every issue takes one way access creeps in, shows a real incident where it went wrong, and ends with one thing to check that week. Written for the people who run the tools, without a security team behind them.

  • 1one mechanism, explained plainly
  • 2one real incident, taken apart
  • 3one step you can take on Monday

get the next issue

One email every two weeks. Your address stays here and is never passed to vendors. One click to unsubscribe. Privacy.