Short answer: Yes. If an approval screen is reachable from the place an AI agent runs, a browser tab it drives or a dialog on the machine it controls, then a compromised or prompt-injected agent can click “Approve” by itself. A confirmation click proves that something clicked, not that a human weighed the decision. The durable fix is to move the authorization decision out of the agent’s reach, so the grant is authored by the person in a channel the agent cannot operate.
Can an AI agent really click its own “Approve” button?
Yes, and vendors now say so plainly. The category has a name: computer-use agents (for example, Anthropic’s Claude Computer Use and OpenAI’s Operator, now folded into ChatGPT’s agent mode) act by reading a real screen and clicking on it the way a person would. In its November 2025 research on browser agents, Anthropic notes that these agents work by “navigating to URLs, filling forms, clicking buttons, downloading files,” and concludes that even after major robustness gains, “no browser agent is immune to prompt injection.” Their reported attack success rate dropped to around 1 percent, which they describe as still “meaningful risk,” not a solved problem.
An approval button is just another button on the screen. If the agent can see and click the page, it can see and click the “Approve” on a consent dialog rendered in that same page. This stops being theoretical once you add prompt injection. Palo Alto Networks Unit 42 documented in March 2026 that indirect prompt injection, where hidden instructions are planted in web content the agent reads, is “no longer merely theoretical but is being actively weaponized,” with observed attacker goals including “unauthorized transactions” and “sensitive information leakage.” An injected instruction that says “approve the pending request” is executed the same way as any other instruction the agent picks up.
Why isn’t a confirmation dialog enough?
Because a click is weak evidence of a considered human decision, even when a real human is present. Anthropic reported that in Claude Code, users approved “roughly 93% of permission prompts,” and observed that “the more approvals a user sees, the less attention they pay to each.” That is approval fatigue in the best case, where a human is actually in the loop. In the worst case, where the agent controls the input path, there is no human in the loop at all, and the click carries no signal whatsoever.
The lesson is that the security of a consent step does not come from the presence of an “Approve” button. It comes from where the button lives. If the decision surface sits inside the agent’s execution context, the agent can complete it, and the confirmation becomes ceremony rather than control.
What does a real human-in-the-loop actually require?
The approval has to be a ceremony the agent cannot complete from where it runs. In practice that means three properties:
- The grant is authored by the person, not the agent. The user chooses the scopes and the duration inside the application’s own authenticated session, not through a redirect or dialog the agent set in motion.
- The decision surface is outside the agent’s reach. If approving requires an action on a channel the agent does not control, an injected instruction has nothing to click.
- Escalation always returns to the human. When an agent needs more access than it was granted, that request cannot be self-served. It has to route back through the same out-of-band decision the person made the first time.
This is why “add a human approval step” is necessary but not sufficient. The approval step has to be one the agent physically cannot perform on its own, or it collapses back into the problem it was meant to solve.
How does user-mediated authorization solve this?
User-mediated authorization is built on exactly this separation. The person opens a “Connect Your AI Agent” flow inside the app’s own session and selects what the agent may do and for how long. The app generates a single-use, time-limited connection credential and delivers it to the person through a channel the person controls, never to an agent endpoint, webhook, or callback URL. The person then hands that credential to their agent out of band, and the agent exchanges it for a scoped, revocable access token.
The point that matters here: there is no redirect, callback, or programmatic path an agent can drive to create or expand a grant. The authorization decision happens outside the agent’s execution context, so a malicious instruction injected into the agent has no button to click and no endpoint to call. If the agent later hits an operation outside its scope, it gets an insufficient_scope response, and the only way forward is a fresh, user-mediated grant. There is no self-service escalation path.
One honest edge case remains: a computer-use agent running on the person’s own machine could try to drive that connection screen too. This is why the escalation ceremony itself can be hardened. The requirement is the important part: the confirmation must be something the agent cannot complete from where it runs, such as an approval on a separate device the agent does not control, or a user-verified assertion from an authenticator registered before the task began. AgentAdmit implements this with WebAuthn user verification, the standard behind passkeys: an app can require that any grant which elevates an existing user’s scopes be confirmed with a presence ceremony, and can apply the same requirement to consent-setting changes generally. Other mechanisms that satisfy the same property work just as well; what matters is that no approval surface reachable from the agent’s execution context counts as proof of a human decision.
This is the same failure mode behind incidents like the GitHub MCP “toxic agent flow” reported in 2025, where a benign request plus a poisoned public issue led an agent to leak private repository data through its own over-broad token, and the zero-click Microsoft 365 Copilot prompt-injection flaw (CVE-2025-32711). In each case the agent had standing authority it could exercise without a human re-entering the loop. Moving the grant and every escalation out of the agent’s reach removes that standing authority by design.
User-mediated authorization complements standards like OAuth and protocols like MCP. MCP tells an agent what it can do; the authorization layer decides whether it is allowed, and keeps that decision where the agent cannot reach it.
Frequently asked questions
Can prompt injection make an AI agent approve its own access?
If the approval surface is reachable from the agent’s execution context, yes. Prompt injection is an instruction the agent reads and acts on, and clicking an on-screen “Approve” is an action a browser or computer-use agent can take. Unit 42 documented indirect prompt injection being weaponized in the wild in early 2026, including for unauthorized transactions. The defense is to place the approval on a channel the agent cannot operate.
Can a computer-use agent approve its own consent prompt?
Yes. Computer-use agents such as Claude Computer Use and OpenAI’s Operator act by reading a screen and clicking on it, so an approval dialog rendered where the agent runs is just another button it can press. A consent step shown on the same device the agent controls therefore proves nothing. The fix is to require approval on a channel the agent cannot operate, so the decision is made outside its reach.
Is a human approval click enough to stop AI agent misuse?
Not on its own. Anthropic found users approved about 93 percent of Claude Code permission prompts and grow less attentive as prompts pile up. A click confirms that something clicked, not that a human evaluated the specific action. A confirmation step is only as strong as the agent’s inability to complete it.
How do you stop an AI agent from escalating its own permissions?
Remove the programmatic path to more access, then harden the human path. With user-mediated authorization, a request beyond the granted scope returns an insufficient_scope error, and the only way forward is a new grant the person authors in the app’s own session. Because a computer-use agent on the person’s machine could try to drive that session too, the elevation ceremony can additionally require proof of human presence that the agent cannot produce from where it runs, for example WebAuthn with user verification from a pre-registered authenticator, or an approval on a separate device the agent does not control.
Does this replace OAuth or MCP?
No. It complements them. OAuth and MCP handle authentication and capability discovery. User-mediated authorization adds the piece they do not: a per-user, per-agent, scoped grant that the user controls and that lives outside the agent’s execution context.
AgentAdmit is the authorization layer for AI agents, built so the authorization decision never sits where an agent can click it. Learn more at agentadmit.com.
Related reading: What is user-mediated authorization for AI agents?, What is the Context Access Divide?, and MCP security: how to let an AI agent access user data safely, What is caller-identity consent for AI agents?.