Verizon's 2026 Data Breach Investigations Report landed on a number that should bother any technology leader: 83% of privilege escalation cases in the dataset exploited no technical flaw at all. The attacker didn't need a sophisticated vulnerability. They just used access that was already granted — only far wider than the task it was meant to cover.

The same report measured how long companies take to fix that: excessive permissions and misconfigured access take a median of nearly eight months to resolve. And 26% of organizations still carry privilege escalation gaps open since 2021. This isn't a new problem. It's a problem most companies decided to live with.

That habit didn't start with AI, but corporate AI is where it keeps repeating now. When a team connects an assistant to an internal system, the question is rarely "which of this system's hundred functions does the team actually need." It's "can we connect this somehow." And the fastest way, almost always, is opening everything.

A debt that AI is reactivating

The principle behind this has a name, and it isn't new: NIST's zero trust model, in its reference document SP 800-207, treats minimum necessary access as one of its pillars — granting privilege per session, on a time-bound basis, elevated only when the task genuinely requires it. No company disagrees with the principle in theory. The difficulty is applying it when someone needs to ship something today, and opening everything is faster than configuring it properly.

With systems used by people, that shortcut is already costly — it's exactly what NIST's model tries to correct. With AI agents, the risk grows in another direction: Microsoft's 2025 Digital Defense Report notes that system, application, and automated agent identities already outnumber human identities across much of the enterprise, and that these identities tend to carry more privilege than needed, with weaker controls than a person's account. An agent connected to an entire tool through a single credential that unlocks every function in it is exactly that pattern — except now it talks to anyone on the team in plain language.

Why "connect everything" looks like the simple way out

Why 'connect everything' looks like the simple way out

When a technology team needs to connect an AI assistant to a business system, the integration's documentation usually lists dozens of functions: query, create, edit, approve, cancel, export. The team that requested the integration may need two of them — check orders and see delivery status. Configuring exactly those two takes work: mapping what each function does, deciding who gets what, keeping it current as the team changes. Opening the entire credential solves it right away.

The problem shows up later, and it never shows up alone: it shows up when someone asks, during an audit or after an incident, "who could cancel orders through this." If the answer is "everyone who had access to the assistant, because that's how the integration was set up," there's no trail to reconstruct who used what. That's exactly the pattern Verizon's report describes: the problem is rarely a sophisticated security flaw. It's access left too wide, that nobody reviewed.

This kind of decision doesn't scale either. Every new tool connected the same way multiplies the surface that a single compromised credential — or a single agent misconfiguration — can reach. At some point the list of "what this assistant could technically do" grows larger than anyone can explain from memory.

What has to be in place

A well-designed access environment for AI rests on concrete mechanisms, not on good intentions to "configure it properly when there's time."

Function-by-function access, not the whole tool. If an integration exposes thirty functions and the support team uses two, those two get granted. The rest stays available for whenever — and if — another team genuinely needs it, not by default.

Layered scope. Not every access needs to start permanent and company-wide. An access can start personal, for a one-off test or task, and only later "grow" into official team or company access — by a decision from whoever approves it, not by inertia.

Its own credential per tool and per person. Nobody shares a single access key across several people or several agents. When a credential disappears from the picture — because the person left, because the agent was retired — it disappears on its own, with no one needing to remember to revoke it.

Approval whenever an access asks for more scope. Requesting more permission than the original grant isn't automatic: someone decides, and that decision gets recorded. That's the difference between access growing because it made sense to grow, and access growing because nobody was paying attention.

A record of who has what, reviewable at any time. If answering "who can cancel orders through the assistant" needs a two-week investigation, the access design has already failed — regardless of whether an incident ever happened.

That's how Skyller was designed: function-by-function permissions within every connected tool, layered scope across company, agent, team, and person, and its own credential per tool instead of a single shared key.

What changes for whoever decides access

What changes for whoever decides access

When access is granted function by function, whoever approves a new integration stops signing a blank check. The question stops being "can I trust this AI tool" — too broad a question to answer safely — and becomes "do these two specific functions make sense for this team." That's a much easier decision to make, and a much easier one to defend later.

The gain also shows up in reaction speed. When someone changes roles or leaves the company, adjusting their access stops being a manual review project across several different tools and becomes a direct consequence of changing one role in one place. And when an AI agent needs a new function, the technology team doesn't have to choose between "open everything again" or "block the team," because granting exactly that function is now the fast path, not the hard one.

A checklist for reviewing your first connected assistant's access

  1. List every tool already connected to an AI assistant in the company. If the answer is "not sure," that's the first finding — and the reason to start here.
  2. For each one, ask how many functions the assistant actually uses today. Compare that to how many the current credential allows. The gap between the two numbers is permission sitting there unused.
  3. Check whether a single credential is shared across people or across agents. If it is, that's the first thing to fix — it's what blocks reconstructing who did what.
  4. Confirm who approves when an access asks to grow. If the answer is "no one, it's automatic," AI's reach in the company is growing without anyone deciding it should.
  5. Ask how long it's been since each access was reviewed. An access granted two years ago, for a task that has since changed, is exactly the kind of gap Verizon's report describes as taking months to fix.

Discover Skyller