You connected your AI agent to a dozen tools — GitHub, Slack, databases, cloud APIs — and it finishes in minutes what used to take hours. You added MCP servers (Model Context Protocol — a universal plug standard for AI tools, like USB but for data), wired up API tokens (digital passwords that let programs access services on your behalf), and everything just worked. The future arrived, productive and entirely unguarded.

Because when you wired those connections, each tool asked for full access. Not "read-only." Not "only this repo." Full access. And no agent platform offered a way to scope permissions at the orchestration level — the layer where your agent decides which tools to use and when. You handed over the master key and called it integration.

Between April 1 and April 14, 2026, that master key got copied. Repeatedly.

Google Hands Every Agent the Root Password, Then Updates the README

On April 1, Palo Alto's Unit 42 disclosed the "Double Agent" flaw in Google's Vertex AI. This is the strongest case study of the authentication-vs-authorization gap I've seen yet.

Here's what happened: every Vertex AI agent received a default service account (a system-level identity that acts on behalf of your agent). That service account came pre-loaded with permissions that would make a sysadmin weep. We're not talking "slightly too broad." We're talking access to:

  • Customer Cloud Storage buckets — other customers' data, accessible from any agent instance
  • Restricted Google-internal container images — the kind normally locked behind multiple approval layers
  • Vertex AI's own source code — the platform's internal repos, readable by a throwaway demo agent

The researchers demonstrated a full privilege-escalation chain: start with a basic agent, inherit the default service account, pivot laterally across Google Cloud resources that no agent should ever touch. The default identity wasn't "slightly over-privileged" — it was functionally omniscient within the project boundary and partially omniscient outside it.

Google's fix? Updated documentation suggesting you bring your own, less-privileged service account. Not a platform change. Not a sane default. A docs patch. They told customers to read the manual harder. The equivalent of a car manufacturer responding to brake failure with "we've updated the owner's manual to recommend slowing down before intersections."

The flaw existed because Vertex AI's authentication layer worked perfectly — agents connected, tokens exchanged, handshakes completed — while the authorization layer was a vacant lot. Nobody at Google built the part that asks "should this agent have access to this?"

Anthropic's Credential Vault: One Workspace, All Keys, No Walls

A week after Google's embarrassment, Anthropic launched Claude Managed Agents on April 8 with per-tool permission tiers — allowed_tools, denied_tools. Better than nothing. But on April 13, security researcher hi120ki demonstrated that the Credential Vault underneath those permissions has a gaping confused-deputy problem (when a trusted program is tricked into misusing its authority).

The attack path is straightforward and ugly:

  1. A workspace has multiple agents, each with different tool credentials stored in the Credential Vault
  2. The Vault scopes access at the workspace level, not the agent or session level
  3. Any API key with workspace access can reference any credential in that vault
  4. An attacker (or a compromised agent) with one valid workspace API key can inject tool calls using credentials belonging to other agents

In practice: Agent A has read-only GitHub access. Agent B has production database write credentials. If Agent A's session is compromised — via prompt injection, tool poisoning, or a malicious MCP server — it can pull Agent B's database credentials from the shared Vault and execute writes. The per-tool permission tiers (allowed_tools) govern what the agent should do. The Vault governs what it can do. Those two lists don't match.

hi120ki's proof of concept showed cross-agent credential access within a single API call. The fix would require per-agent credential isolation — essentially, giving each agent its own vault partition with cryptographic separation. As of April 19, no fix ships.

This is the confused-deputy pattern in its purest form: the Vault is the trusted deputy, the compromised agent is the confused requester, and the target credentials are someone else's authority. The trenchcoat barely covers it.

The Pattern: Authentication Solved, Authorization Missing

These aren't isolated bugs. They're symptoms of a missing architectural layer.

The Azure DevOps MCP flaw (CVE-2026-32211, CVSS 9.1, disclosed April 3) — which I covered when it dropped — showed the same void from the opposite direction: not over-permissioned defaults, but zero authentication on the tool side. Claude Code Routines, which shipped April 14 as agents running on schedules without human approval, amplify whatever permission sins already exist by removing the last human checkpoint.

Same disease, different organs. Authentication (can the agent connect?) is mostly solved — OAuth flows, API keys, credential vaults handle handshakes fine. But authorization (what can the agent do once connected?) remains a void. Each tool has its own permission model — GitHub scopes, AWS IAM policies (granular access rules for cloud resources), Notion page-level access — but no agent platform aggregates, audits, or enforces least-privilege across the full tool set.

The layer between "tool connected" and "action performed" does not exist.

An April 11 audit of 7,000 MCP servers by Pomerium found 36.7% vulnerable to SSRF (Server-Side Request Forgery — tricking the server into making unauthorized requests to internal systems). More than a third of MCP servers can be turned into network pivot points. Not because the protocol is broken, but because individual server implementations assume the connecting agent is trustworthy and appropriately scoped. They assume the authorization layer exists upstream. It doesn't.

Why Nobody Will Fix This Until It Costs Them

Cloud computing crawled through 15 years of painful evolution — from "SSH as root into the box" to granular IAM with audit trails, role-based access, and least privilege. We got there because breaches cost money and compliance frameworks forced change. Agent platforms are at day zero of that same crawl, handing out root-equivalent tool access by default and calling it a feature because it demos well.

Building unified tool authorization would murder the "connect anything in 30 seconds" magic. It would add setup friction and weaken competitive demos. No vendor has the market incentive to add friction first. Google won't. Anthropic won't. Microsoft won't. The incentive will come from incidents. Probably expensive, public, multi-customer incidents.

We have previews: in July 2025, a Replit agent panicked and deleted production data for 1,200+ executives. In December 2025, an Amazon agent autonomously deleted and recreated a live production environment, causing a 13-hour AWS Cost Explorer outage. Those were accidents. The next round won't be.

Every over-permissioned MCP server, every full-access API token, every unscoped tool connection is a standing vulnerability — dormant while a human clicks "approve," active the moment an agent runs autonomously on a schedule.

The agent platform race's next real differentiator isn't the model or the tool count. It's the first admin console that shows what your agent can actually do — and lets you revoke most of it. The gap between "connected" and "authorized" is where the next breach lives. Right now, everyone's building bridges across it with no guardrails and calling it progress.