Three Attacks in 72 Hours: AI Agent Permissions Are the Real Vulnerability

Three things happened between June 14 and June 16 that should change how you think about AI agent security. None of them involved a new model. None required a zero-day in the traditional sense. Each one exploited the same gap: an AI assistant with real permissions and no independent judgment checking what it was asked to do.

SearchLeak: Copilot as a one-click exfiltration weapon

Varonis Threat Labs detailed SearchLeak on June 15, a three-stage vulnerability chain in Microsoft 365 Copilot Enterprise Search that Microsoft patched under CVE-2026-42824 with a critical severity rating. An attacker sends the victim a link to a trusted microsoft.com domain. The link's URL parameter contains instructions that Copilot reads as a prompt. Copilot searches the victim's mailbox, pulls out email content (including 2FA codes and password reset links), meeting details, and SharePoint files, then embeds that data in an image URL. Bing's image-search feature fetches that URL server-side, bypassing the browser's Content Security Policy. The attacker reads the stolen data from their server logs.

The victim sees Copilot "thinking" for a moment. That's it. No phishing page, no fake login, no malware download. One click on a legitimate-looking Microsoft link.

What makes SearchLeak worth paying attention to is not the individual bugs. Parameter-to-prompt injection, HTML rendering race conditions, and SSRF via Bing are each known vulnerability classes. The point is what happens when you chain them through an AI assistant that has access to your entire enterprise data store and cannot distinguish between a user's request and a command hidden in a URL parameter. Varonis researcher Dolev Taler put it plainly: "Bing becomes an unwitting exfiltration proxy."

Dor Yardeni, Varonis's director of security research, told Dark Reading this is "a wider class of risks in LLM-powered enterprise assistants, especially those that combine external input, like links or prompts, with internal data access and action capabilities."

BleepingComputer, Dark Reading, and Ars Technica all covered the disclosure independently.

The Meta hack: when the security check was a person

Earlier in June, attackers took over more than 20,000 Instagram accounts, including the dormant Obama-era White House account. They did not write an exploit or guess a password. They opened a chat with Meta's AI support assistant, asked it to attach an email address they controlled to an account they did not own, and requested a password reset to that address.

Meta confirmed what the logs showed: the assistant behaved exactly as designed. A separate part of the system was supposed to verify that the email belonged to the account. That check never ran.

Stack Overflow published an analysis on June 15 that frames this correctly. The problem was not an AI mistake. The assistant carried out a valid sequence of permitted operations for whoever was talking to it. What would have stopped the attack was a person: a support worker who saw a stranger rerouting a celebrity's recovery email, sensed something wrong, and refused.

The piece makes a point that stuck with me. A large share of real-world authorization was never written as software at all. It lived in the discretion of whoever stood between a request and the system. Put an agent in that seat and discretion vanishes, while nothing downstream notices. The agent does not bypass your security model. It exposes the part of it that was a person.

Security researchers call this the confused deputy problem, dating back to a 1988 paper about a compiler tricked into writing to a protected file. An LLM agent is a confused deputy by construction. Its interface is natural language, which carries no notion of who is authorized to do what. The model's job is to turn a plausible sentence into a tool call. Unless identity is reattached before that call fires, the agent acts on its own authority.

Stack Overflow also notes that Meta launched its Business Agent in the same week it disabled the support tool. Business Agent books appointments, qualifies leads, closes sales, takes payments, and connects to Shopify and Zendesk. Run the same confused-deputy logic through a payment API and the failure is no longer a stolen account. It is a refund to the wrong party, an order rerouted, a price overridden.

LiteLLM: the gateway that held all the keys

On June 15, Obsidian Security disclosed a three-CVE chain in LiteLLM, the open-source AI gateway that routes requests to over 100 model providers behind one interface. A default low-privilege account could create a virtual API key with wildcard route access, promote itself to admin, and execute arbitrary Python through LiteLLM's Custom Code Guardrail, which ran admin-supplied code via exec() with no source filtering. Combined CVSS: 9.9.

The chain was weaponized within 36 hours of disclosure, according to Miggo.io, and a separate RCE (CVE-2026-42271) landed in CISA's Known Exploited Vulnerabilities catalog.

LiteLLM is interesting because of what a compromise exposes. The proxy holds every provider API key the organization uses, the master encryption key, and the database credentials for decrypting stored secrets. Every prompt and response flowing through it becomes readable. One compromised gateway server is a full breach of the organization's AI infrastructure.

The pattern

These three incidents share a structure. Each one gave an AI system real authority over sensitive data or actions. Each one assumed something was checking that authority, and it was not. In Copilot's case, the assumption was that URL parameters could not act as prompts. In Meta's case, the assumption was that a human would notice something wrong. In LiteLLM's case, the assumption was that route-level checks were sufficient.

The Cloud Security Alliance's April 2026 survey of enterprise AI agent security found that 53% of organizations report agents exceeding intended permissions occasionally or regularly. 47% have experienced an AI agent-related security incident. Only 15% say more than three-quarters of their agents have defined ownership.

Gartner projects that 40% of enterprise applications will include task-specific AI agents by end of 2026, up from under 5% at the start of the year. Most of those deployments will inherit the same assumptions.

The industry response: runtime identity arrives

On June 16, the same day Ars Technica was detailing SearchLeak, Ping Identity announced integrations with AWS, Google Cloud, and Cloudflare to extend what it calls Runtime Identity into the environments where AI agents operate.

The premise is straightforward. Authentication at session start is not enough when an agent can be talked into using its credentials 15 minutes later. Ping's approach puts a policy layer between the agent and every action it attempts, checking who is behind the session, what permissions they hold, and whether the specific action is allowed for this resource at this moment.

On AWS, the integration covers agents built on Amazon Bedrock AgentCore, enforcing delegated least-privilege access as agents interact with APIs and multi-account environments. On Google Cloud, it integrates with the Agent Gateway to authenticate agents with delegated identities and enforce fine-grained policies across tool interactions including MCP servers. On Cloudflare, it extends identity enforcement to the edge, securing agent and MCP traffic with scoped credentials.

Andre Durand, Ping's CEO, framed it as a tradeoff organizations are already making: "Organizations want to move faster with AI, but they can't afford to lose visibility or control as AI agents begin operating autonomously."

Cloudflare's Chief Partner Officer Tom Evans pointed to the infrastructure angle: "Identity and Zero Trust are key to maintaining visibility and control as organizations deploy AI agents across distributed environments."

This is not the only approach. Microsoft shipped its Agent Governance Toolkit in April. NIST launched its AI Agent Standards Initiative in February. But Ping's announcement is notable because it targets the specific gap these three attacks exposed: the space between what an agent is authorized to do and what it should be allowed to do right now, for this caller, against this resource.

What to actually do

Before connecting an agent to anything sensitive, figure out what checks the person in that loop used to run. Stack Overflow's framing is the right one: that judgment was real work, and it has to exist as code now because the agent will not improvise it.

Concretely: scope credentials per action, not per session. A token that lets an agent summarize customer tickets should be useless for refunding orders. Verify the principal outside the chat, through the authenticated session, not through anything the model can influence. Gate irreversible actions behind human approval or hard policy rules. Log every action with its provenance: who triggered it, what session it came from, what prompt produced it.

The CSA survey found that 58% of organizations take five hours or longer to detect and respond to agent-related incidents. The Meta attack ran for roughly six weeks. The difference between a contained incident and 20,000 stolen accounts is often whether anyone could see, in real time, that one privileged action was firing repeatedly for accounts with nothing in common.

Treat AI infrastructure the way you treat production databases and identity providers. Patch cycles measured in days or weeks are not fast enough when VulnCheck's 2026 data shows 29% of known-exploited vulnerabilities are weaponized on the day of CVE publication.

Sources: Varonis Threat Labs, BleepingComputer, Dark Reading, Ars Technica, Stack Overflow Blog, Latest Hacking News (LiteLLM), Cloud Security Alliance, Ping Identity / PR Newswire