You connected your AI agent to Slack, GitHub, and Jira. The platform popped up a polite dialog: "Allow Slack access?" You clicked yes. You felt responsible. You felt in control.

You weren't. The agent just DM'd your CEO a draft bug report meant for #engineering. The permission gate never asked about recipients, channels, or what "Slack access" actually means when a machine is holding the keys.

Three platforms, one pattern, zero depth

Two weeks ago, the discourse was about agent platforms lacking meaningful authorization entirely — agents with root access and nobody building sudo. That conversation is already outdated. All three major platforms have now shipped their answer: tool-approval workflows, those "Are you sure?" prompts that pop up before an AI agent (a program that acts on your behalf, not just chats) does something consequential. The authorization gap hasn't been filled. It's been wallpapered over.

Google's ADK added action confirmations at Cloud Next (April 22–24). Anthropic's Managed Agents, launched April 8, included per-tool permission policies from day one. OpenAI's Agents SDK shipped needs_approval callbacks in its April 15 update. Three companies, converging on the same idea — like three architects independently designing the same leaky roof.

The pattern is identical across all three: you approve or deny access at the tool level. "Allow Slack" or "Deny Slack." Binary. On or off. A bouncer checking IDs at the building entrance while every apartment door inside stays wide open.

Where the actual danger lives

The blast radius of a bad tool call — the damage it can actually do — lives in the parameters: which Slack channel the message goes to, which Git branch someone force-pushes, which SQL query runs against your production database, which Jira project the agent floods with auto-generated tickets.

To be fair, Google ADK and OpenAI do pass tool-call parameters to developer-written callbacks. You can write code like return amount > 1000 to block expensive operations. But here's the critical distinction: the platform gives you a hook, not a safety net. You write the rules yourself, in raw Python, for every tool, for every parameter, for every edge case. No declarative policy engine. No built-in allowlists. No "only post to #engineering and #random" toggle in a dashboard.

Anthropic's implementation is even simpler — their permission policies operate purely on tool names. The user.tool_confirmation event accepts exactly two responses: "allow" or "deny". No field for argument constraints. No conditional logic. The agent either can use Slack or it can't.

As security researcher Simon Willison wrote in September 2024: "Once an LLM agent has ingested untrusted input, it must be constrained so that it is impossible for that input to trigger any consequential actions." Tool-level gates don't achieve that. They constrain which actions exist, not what those actions do.

We've seen this movie before

The pattern is a copy-paste from mobile permissions circa 2008. Android 1.0 granted blanket "camera access" — no distinction between a selfie app and a document scanner silently photographing your desk. It took Google seven years and Android 6.0 Marshmallow (2015) to ship runtime permission scoping — contextual controls over how an app uses the camera, not just whether it can.

Agent platforms are at the Android 1.0 stage today. The permission dialog exists. It feels like security. It isn't.

Microsoft said the quiet part out loud

On April 22, Microsoft's developer blog published a blunt admission: "Instruction-following alone shouldn't be treated as a security boundary." Their own red-team testing — conducted as part of the Agent Governance Toolkit they open-sourced earlier this month — revealed a 26.67% policy violation rate when using prompt-only guardrails. One in four dangerous calls slips through if you rely on the LLM to police itself.

AGT is the closest thing to a real solution: a middleware layer that sits between your agent and its tools, enforcing declarative policy rules written in YAML, OPA, or Cedar. It actually inspects parameters. It actually gates based on argument values. But it's middleware you bolt on yourself — not native to any agent platform. Good duct tape, but duct tape.

The price of doing it right

Parameter-level gating is genuinely hard. It requires semantic understanding — knowing that #general is a public channel while #exec-compensation is not. It adds latency to every tool call in systems already fighting context window limits (how much text the AI can "see" at once). And worst of all, it creates approval fatigue: the more granular the gates, the faster users train themselves to click "approve all" without reading — the exact behavior that makes permissions theater.

What you should actually do

Until platforms ship parameter-aware gates as a native feature, you have two honest options. One: build middleware that checks tool-call arguments against allowlists — safe channels, safe branches, safe query patterns. Two: accept that clicking "Allow Slack" means "allow the agent to do anything the Slack API supports," and plan accordingly.

The permission dialog on your agent platform is a placebo. It controls which doors the agent can open, but not what the agent does inside the room. Three platforms shipped the same lock in April 2026, and none of them included the deadbolt.