Your AI tools have more access than your employees. Do you know their reach?

Your AI tools have more access than your employees.

Do you know their reach?

Something has changed about the tools inside our organisations, and the security models built for the last generation have not caught up. These tools no longer just sit alongside our work, they act within it, faster and more widely than we’ve ever seen. 

In this post, we will share about:

1. The new risks to be aware of
2. The questions to ask around them
3. How to establish minimal viable agent governance.

The brief: Integrations, copilots, and autonomous agents all inherit the permissions of the humans who authorise them, but these can fail to lose those permissions when they should. The risk varies by type: a passive integration reads or writes data on demand; a copilot uses access to generate suggestions; an autonomous agent uses access to take actions, without waiting for explicit instruction at each step. Most organisations cannot produce a current list of which third-party tools have access to corporate data, what scope that access carries, or which have been compromised. The deeper issue is one of governance: organisations are giving non-human actors employee-level reach without the approval, ownership, and oversight they apply to people and suppliers.

What’s the risk of AI tools accessing corporate data?

On 19 April 2026, Vercel published a ++security bulletin++ reporting unauthorised access to certain internal systems, traced to a compromise of a third-party AI tool, Context.ai, used by a Vercel employee. The chain was straightforward and entirely permissioned. A Vercel employee had connected the AI tool to their corporate Google account with full read access to Google Drive. Two months earlier, this same AI tool was a victim of malware, which harvested their browser-stored credentials and session tokens. The attacker used those to get into the Context.ai, and from there into Vercel’s environment, where they were able to access and read environment variables — including API keys and database credentials. 

Two details are worth noting: 

1. First, no system was exploited in the conventional sense: every step used valid, granted access.
2. Second, Vercel’s security bulletin indicates that the incident came to light following a public disclosure from their third party AI tool, Context.ai.

Traditional software executes instructions. It does what it is told, when it is told, and nothing more. Agents pursue objectives: they interpret a goal, decide on an approach, and can keep going without a human confirming each step. The shift from executing commands to pursuing outcomes is what makes them genuinely useful, and it is also what makes them a new category of risk. 

“Traditional software executes instructions.
Agents pursue objectives”

Vercel shows the access problem at its simplest: a tool that could read more than it should. But the tools entering organisations now do more than read. The governance question is no longer only who has access to a system, but how much autonomy an organisation is willing to grant a non-human actor inside a critical business process. The next incident shows what that looks like when no one has drawn that line.

What’s the risk of AI tools acting on their own?

Five days later, via a public post-incident report, it became known that a software company, PocketOS, saw the same pattern play out — but with an agent that could act, not just read. During a routine task, an AI coding agent hit a credential mismatch and searched the codebase on its own for a way to keep going. It found an API token in an unrelated file that was scoped for every operation, including destructive ones. The agent used it and deleted the production database, along with every backup, in nine seconds. The only recoverable backup was three months old. The agent’s own documented guardrails and the project’s internal rules were all in place. None of them was designed to question an action the agent was technically authorised to take. 

Both come down to the same governance failure: no one had decided, in advance, how much these tools were allowed to reach or to do. These four questions are where that decision starts.

4 questions you should be able to answer about your AI tools

If the directive in 2024 was to know what software was running in your environment, the directive in 2026 is to know what AI is acting in it. There are four questions to start with.

For any AI integration — copilots, analytics tools, meeting transcribers.

1. Who is the agent acting on behalf of?

Most AI integrations authenticate as a specific user and inherit that user’s permissions. When the user changes roles, leaves the company, or loses access to a system, the agent often does not. Vercel’s compromise hinged on a single employee’s Google Drive scope, granted once and never reviewed.

2. What systems and data can it reach?

This is the inventory question, and it is the one most organisations fail at. OAuth grants are typically authorised by individual employees through self-service flows that bypass security review. The result is a sprawl of third-party tools with no central register: meeting transcribers and analytics integrations with read access to calendars and calls; coding assistants and sales copilots with read-write access to repositories and CRM records; and, increasingly, autonomous agents with the ability to send emails, modify databases, call external APIs — without further human approval.

For autonomous agents — systems that interpret tasks and take actions, rather than waiting for explicit instruction.

3. What decisions does it influence?

A read-only AI tool that summarises customer conversations into a CRM is shaping pricing and renewal decisions. A coding agent with destructive API permissions is shaping production infrastructure. Access is only half the question; the other half is what that access lets the tool influence, and whether anyone has weighed that influence on purpose.

4. Where does accountability sit when something goes wrong?

This is the hardest of the four. When an agent acts on its own and something breaks, responsibility is spread thin: the tool vendor points to its guardrails, the model provider points to its safety training, and the organisation points to its own rules — all of which were in place, and none of which prevented the outcome. If accountability is not assigned to a named owner before deployment, no one holds it when it matters.

What does minimum-viable agent governance look like?

The framing borrows from Forrester’s AEGIS guidance and CoSAI’s March 2026 paper on Agentic Identity and Access Management, but the practical core fits on one page:

Inventory. Maintain a current register of every AI tool with OAuth access to corporate systems. Include scope, the user who authorised it, and the last review date. Most organisations starting this exercise discover between two and ten times what they expected.

Scoping. Default to least-privilege. An AI tool that needs to read calendar invites does not need full Drive access. A coding agent managing custom domains does not need destructive scope on production volumes.

Revocation. Tie agent access to the employment lifecycle. When an employee changes role or leaves, their authorised AI tools should lose access at the same time as their other credentials.

Logging. Treat agent actions as auditable events. The PocketOS deletion was a single API call. Whether it would have been caught in time depended entirely on whether the call was visible to anyone watching.

Escalation. Define which agent actions require human confirmation before execution, and which can proceed autonomously. The directive should be written down, owned by a named person, and rehearsed.

None of this is new, but it is identity and access management applied to a new class of actor that most IAM programs were not designed for.

 

---

What this means

The challenge is not that AI tools have access to data. The challenge is that organisations are introducing more systems that can read, decide, and act inside critical business processes. Most governance models were designed for people, not AI agents.

The organisations that adapt first may not be the ones with the most advanced AI, but they will be the ones that understood its reach, defined its boundaries, and governed it accordingly.

→ Invest in your cyber resilience today. Start a free NIS2 maturity assessment

 

---

 

Frequently asked questions

What is shadow AI and why is it a security risk?

Shadow AI refers to AI tools authorised by individual employees without security review — typically through OAuth or API integrations. The risk is twofold: the tool itself may be compromised, and the access scope is rarely tracked, meaning the organisation cannot answer who or what currently holds read or write access to its data.

How are AI agents different from regular software integrations from a security perspective?

AI agents act on their own initiative. A traditional integration executes a defined function on demand. An agent interprets a task, decides on an approach, and can take actions its operator never explicitly sanctioned — including searching for credentials, calling unrelated APIs, or modifying systems outside the immediate scope of its task.

Does NIS2 cover AI tool governance?

The Cybersecurity Act, which implements NIS2, does not name AI tools specifically. It requires proportionate cybersecurity measures under management responsibility, and incident reporting within 24 hours of early awareness. An AI-driven incident that affects service availability or data confidentiality falls within scope. Management responsibility means leadership needs visibility into how AI tools are introduced, governed, monitored, and retired within the organisation.

Where should an organisation start if it has no inventory of authorised AI tools?

Start with the OAuth grants in Microsoft 365 and Google Workspace admin consoles. Both expose a list of third-party applications that have been authorised against corporate accounts, with scope details. This is incomplete — it will miss tools authorised through other identity providers or via API keys — but it is the fastest way to surface the largest category of unknown access.