Three AI Tool Exploits in Five Days: The Attack Surface Is the Tools

Between May 31 and June 3, 2026, three separate security disclosures landed on Hacker News within 72 hours of each other. None of them are about the AI model's behavior. All of them are about the tools the AI model can reach.

This is not a coincidence. It's a pattern.

The five-day exploit sequence

May 31 — Instagram account takeover via AI tool OAuth (HN #4, 1,892 points)

A disclosed vulnerability allowed an AI agent with Meta OAuth integration to access Instagram DMs at god-permission scope. The attack surface wasn't a bug in the AI model. It was the OAuth token the AI agent held — a token scoped to everything the user's account could do, granted before anyone thought about what an AI agent might do with it.

The HN comment that landed hardest: "When thinking about the security of AI agents, one should ignore the agent entirely. Consider only the tools that the agent has access to. Assume that, if the attacker can interact with this agent, they have full and unfettered access to these tools."

June 1 — ChatGPT Sheets exfiltration via MCP-style tool relay (HN #13, 243 points)

A researcher demonstrated that a malicious MCP server — or a compromised relay — could intercept and exfiltrate data from Google Sheets sessions attached to a ChatGPT agent. The attack surface: the MCP tool relay layer, where tool calls pass through infrastructure that has access to the call arguments. If that relay is untrusted or compromised, every tool call is a data leak.

June 3 — GitHub OAuth token theft via VSCode browser (HN #4, 485 points)

A disclosed VSCode vulnerability allows a 1-click OAuth token exfiltration from the browser-embedded VSCode editor — which, when signed into GitHub, holds a live OAuth token at broad scope. The attacker surface isn't the model. It's the credential that the tool (VSCode) holds on behalf of the user.

The thread's most-upvoted technical comment: "A huge vulnerability surface arises from that original sin" — signing the web-embedded IDE into GitHub at god-permission scope.

What these three have in common

Three different vendors, three different AI integrations, three different exploitation techniques — and in every case, the root cause is the same: an AI tool holds a credential at a scope that exceeds what the task requires, and that credential is reachable from a position the attacker can interact with.

The model is never the vulnerability. The tool access is.

The scoped infrastructure argument

The answer to "the attack surface is the tools" is not "use a better model." It's scoped AI infrastructure — where the AI agent doesn't hold raw credentials; it holds virtual keys issued by a governance layer that enforces what those keys can reach.

With a governed MCP gateway:

• The GitHub token is held by the proxy, not the agent. The agent can call a governed MCP tool that writes to a specific repo branch, scoped to that branch — not god-scope GitHub access.
• The Google Sheets API key is held by the proxy. The agent calls a governed MCP tool that reads a specific sheet tab, bounded by content policy on the call arguments.
• The OAuth token is a Trimio virtual key with an explicit permission scope. Revoked in one click. Not a secret sitting in an agent's memory that an attacker might extract via prompt injection.

Why deny-by-default matters here

The MCP gateway pattern — specifically a 5-level deny-by-default permission model — is the architectural response to these three disclosures. The permission model works at two layers:

1. At listing time: an agent's `tools/list` call returns only the tools it has explicit permission to see. A GitHub token tool not in the permission grant is invisible — not accessible by name, not discoverable.
2. At invocation time: even if an agent somehow knows the name of an unpermitted tool, the execution layer re-enforces the permission check before dispatching. The tool call returns `tool_denied` — not a 404, not a silent passthrough.

This breaks the attack chain at the infrastructure layer, before the attacker can reach the credential.

The audit trail is the other half

The third piece — and it's not secondary — is the audit trail. Every tool call, granted or denied, writes a record to the request log: caller identity, virtual key, tool name, timestamp, args (content-policy-scanned for PII before logging), result, cost. If an attacker probes the boundary, you see it in the log. If a tool call exfiltrates data, you have the call trace.

The Instagram exploit worked partly because there was no visibility into what the AI agent was doing with the OAuth token once it held it. Scoped AI infrastructure with full audit logging would have surfaced the DM access pattern as anomalous on first use — before the attacker established a foothold.

The three things every team running AI agents needs now

If you're running AI agents in production — especially agents with OAuth integrations, tool call MCP relays, or any credential-scoped access — three controls are non-negotiable in 2026:

1. No raw credentials in agent memory. Any credential an AI agent holds should be a scoped virtual key issued by a governance layer, not a raw API key or OAuth token sitting in the agent's context. The virtual key is revocable in one click. The raw token is not.
2. Deny-by-default at the tool level. A tool not in the explicit permission grant is invisible and un-invokable. This is the architectural property that breaks the attack chain — not the model, not the agent, the infrastructure.
3. Full tool-call audit logging. Every call — granted or denied — logged to a system you control. Not to the vendor's system. To yours. With caller identity, tool, args (PII-scanned), result, and cost.

The bottom line

Three disclosures in five days. All about tool access, not model behavior. The security community is converging on the same answer: the agent's judgment doesn't matter, what matters is what tools it can reach.

Scoped AI infrastructure — where credentials live in the proxy, not the agent; where tool access is denied by default and logged end-to-end — is the architectural answer. It's not a future requirement. It's a current one, evidenced by three security disclosures in five days.

Trimio's MCP gateway is the governance layer for AI tool calls — permission filtering, deny-by-default, content policy, cost attribution, and full audit logging for every tool invocation. See how it works.