When AI gets access: OAuth, connectors, and agentic AI

how AI gets access

AI tools reach your data through the same connection mechanisms as any other software. There is nothing exotic underneath. What is new is how broad the requests tend to be and how little they are reviewed. There are three common paths.

The OAuth grant. When an AI tool is connected to Google Workspace or Microsoft 365, it asks for permission to do specific things with company data. Read your mail. See and edit your files. Access your calendar. An employee clicks Allow, and the tool receives a token. That token is standing access to company data, tied to the employee's identity, held by the AI tool until someone revokes it. The access it carries is defined by its scopes. A scope like Mail.Read or gmail.readonly gives read access to a full mailbox. A scope like Files.ReadWrite.All or drive gives read and write access across what the user can reach. AI assistants often request the broad ones, because a general assistant is built to touch a lot.

The integration into a SaaS app or repository. An AI tool is added to a code repository, a ticketing system, a CRM, or a chat platform. The integration receives access to read and sometimes write inside that system. A coding assistant connected to a source repository can read the code and, depending on the grant, open pull requests. An AI added to a customer system can read records and act on them.

The API token. An AI tool or workflow is given an API key or service credential to call into a system directly. The token carries whatever permissions it was issued with, and it does not belong to a person. It sits outside your password policy and your MFA, and it persists until it is rotated or removed.

In all three cases the pattern is the same. The grant is standing access under a user's identity or a service credential. It is often broadly scoped, because the tool is built to be useful across many tasks. And it is often unreviewed, because the connection happens inside the tool's own flow, not inside your IT process. IT frequently learns an AI integration exists only when it runs an inventory.

agentic AI and the blast radius

Where a copilot waits for a person to accept its suggestion, an agent goes ahead and does the work. That is the shift worth understanding. An AI agent is built to carry out multi-step work without a human approving each step. It reads a system, decides what to do, writes to another system, and moves on. To do that, it holds access across the systems it works in, either through its own credentials or through a grant delegated to it by a user.

The access an agent holds is the sum of its scopes. If an agent can read your mailbox, write to your file store, query your CRM, and post to your chat platform, then its reach is all of those at once. That combined reach is its blast radius. It is what the agent can touch if it works as intended, and it is also what an attacker can touch if the agent is compromised or manipulated.

Two properties make an over-scoped agent worth particular attention. It is a high-value target: an agent that holds broad, standing access across several systems is a single credential that opens many doors, and an attacker who reaches that credential reaches everything behind it. And it is a single point of failure: because the agent acts on its own, a mistake or a manipulation propagates without a human in the loop to catch it. An agent that can be steered through its inputs, for example through content it reads as part of a task, can be pushed to act outside its intended job using the very access you granted it. The damage is bounded by its scopes, not by its instructions.

None of this is an argument against agents. It is an argument for scoping them deliberately. An agent that can only read free and busy time and draft a meeting invite has a small blast radius. An agent with full mailbox, full drive, and directory read has a large one. The difference is a design decision you make when you connect it, and it is far easier to make narrowly at the start than to walk back later. There is a wider pattern here: attackers are already using AI in their own operations. In one analysis, 16% of breaches involved attackers using AI (IBM, 2025). As AI agents take on standing access inside companies, they become part of the attack surface as well as a tool in the attacker's hands.

governing AI's access: a practical method

You govern an AI tool's access the same way you govern any third-party app's access. The actor is different. The discipline is not. Here is a method you can run with the admin consoles you already have.

Step one: find what AI tools hold. List the AI assistants, copilots, and integrations connected to your environment, and capture the scopes each one holds. In Google Workspace, the connected apps and their scopes are visible under Security, then API controls, then App access control. In Microsoft Entra, they are under Enterprise applications, where you can open each app and read its permissions. Capture the tool name, its scopes, the number of users who authorised it, and the publisher. One row per tool is enough to start.

Step two: read the scopes against the job. For each AI tool, ask whether its access matches what it is for. A meeting assistant needs to read calendars. It does not need to read every email. A document assistant needs the file it is working on. It does not need write access across the whole drive. When the scope is far broader than the task, that is a flag worth raising, regardless of how well known the vendor is. Pay closest attention to data scopes, the ones that read or change mail, files, and the directory, and to any grant that includes offline access, which lets the tool keep working after the user has gone.

Step three: apply least privilege. Where an AI tool holds more access than it needs, narrow it. Prefer a narrowly scoped connection over a broad one when both will do the job. Where a tool offers read-only and read-write versions of a connection, choose read-only unless writing is genuinely required. The goal is to make each AI tool's reach match its purpose, so its blast radius is as small as the work allows.

Step four: restrict who can grant broad access. Configure your tenant so that connections requesting broad data scopes require an administrator to approve them. Let employees consent on their own only to sign-in level scopes from recognised publishers. This keeps the easy path open for low-risk tools and routes the broad AI grants through a person who can see them before the access goes live. Pair the restriction with a simple request path, so an employee who wants an AI tool can ask and get a quick decision rather than working around the control.

Step five: treat an agent's credentials as a privileged identity. An AI agent with its own credentials and standing access is a privileged identity, and it deserves the same handling as one. Give it the narrowest scopes that let it work. Rotate its credentials. Know who owns it and who is accountable for it continuing to hold access. Record what it can reach. An agent's credential that nobody owns and nobody rotates is exactly the kind of standing access that turns into a problem later.

Step six: set a review cadence. AI tools and their grants accumulate continuously, so a one-time review ages quickly. A quarterly review of the broadly scoped, widely used AI tools, with a half-yearly pass over the rest, is a defensible baseline. Tie an AI grant check into offboarding as well, so a departing employee's connected AI tools are reviewed when their account is disabled rather than months later.

This is the same workflow you would run for any connected app. What changes for AI is the emphasis. AI tools tend to request broad scopes, they spread fast because they are useful, and agents add standing access that acts on its own. So the scope-against-job test and the cadence matter more, not less.

the honest scope note

A directory and OAuth review is a clear view, and for most companies it covers a part of the AI access surface that has never been looked at. It is worth being precise about what it sees and what it does not.

A directory and OAuth view sees the AI apps connected through OAuth and through your single sign-on, and the scopes they hold. That includes the assistants and integrations wired into Google Workspace or Microsoft 365, which is where a large share of the standing access lives. It does not see everything. It does not see a personal AI account that an employee uses outside the directory, because nothing was connected to your tenant. It does not see a browser extension running on someone's laptop, because that lives on the endpoint, not in your directory. Those need other signals: endpoint or mobile device management gives visibility into what runs on company devices, and a browser-security tool gives visibility into extensions and into what people sign into in the browser.

An OAuth review tells you what AI tools hold standing access through your directory. It does not tell you about the AI someone is using on a personal account or through an extension. Knowing the boundary means you do not mistake a clean OAuth list for a full picture of every AI tool in use.

the connection to identity discipline

The point worth holding onto is that none of this is a new category of problem. An AI tool with an OAuth grant is a third-party app with standing access to your data. An AI agent with delegated access is a non-human identity with scopes. You already have a discipline for both. It is access governance.

The questions are the ones you already ask of any connected app. What does it hold. Does the scope match the job. Who approved it. Who owns it. When was it last reviewed. The questions stay the same. AI deserves attention because AI tools have spread quickly, they tend to ask for broad access because that is what makes them useful, and agents add a kind of actor that acts on its own. Those properties make the existing discipline more valuable, applied to a fast-growing part of your access surface.

This sits inside a wider pattern that is not specific to AI. Third-party involvement appeared in 48% of breaches, up from 30% a year earlier (Verizon Data Breach Investigations Report 2026). Connected apps are one of the most direct forms of third-party access into your data, and AI tools are now a growing share of them. Treating AI access as part of your identity and access governance, rather than as a separate AI problem, is how you keep it in view.