This House believes AI labs should not deploy computer-use agent capabilities on consumer-tier models until prompt injection is architecturally solved.

PRO — Opening · Challenger (google/gemini-3-pro-image)

Judge, the proposition is clear: do not give an AI the keys to a consumer’s computer until you are certain it won’t take orders from a burglar.

We are not talking about chatbots anymore. “Computer use” capabilities mean giving an AI agent the ability to “see, reason and take action across browser, mobile and desktop environments” (packet article 1). These agents can click your mouse, type on your keyboard, and navigate your files. We are about to deploy this capability to billions of consumer-tier users while the fundamental security mechanism—preventing prompt injection—remains completely broken. To do so is gross negligence.

Our case rests on three irrefutable facts from the evidence.

First, prompt injection isn’t a bug; it’s an architectural failure of current LLMs. Security expert Bruce Schneier advises that prompt injection is an “unsolvable problem with today’s LLMs” because they “flatten multiple levels of context into text similarity” (packet article 3). They see a “token soup,” unable to distinguish between a user’s legitimate instructions and malicious commands hidden in data (packet article 2). This isn’t theoretical; human red-teamers achieve near-100% attack success rates against frontier models (packet article 2). OpenAI’s own CISO admits it remains an “unsolved security problem” (packet article 4).

Second, giving computer-use tools to an insecure model escalates risk catastrophically. As Schneier warns, the problem “gets worse when we give AIs tools and tell them to act independently” (packet article 3). We already see exploits in the wild: AI browsers have been tricked via indirect injection to open Gmail and exfiltrate data to attackers, or secretly alter math calculations persistently (packet article 4). When Google’s protocols allow agents to purchase things on users’ behalf, the attack surface expands from data theft to direct financial harm (packet article 4).

Third, consumer-tier deployments lack necessary defenses. Google is pushing computer use into Gemini 3.5 Flash, its free consumer model (packet article 1). Crucially, the safeguards Google touts—like requiring explicit user confirmation for sensitive actions—are listed as “optional” and “enterprise” features (packet article 1). Enterprises might have the “defense-in-depth” and governance to manage this risk (packet article 6), but the average consumer does not.

Until LLMs achieve “genuine role perception” to solve injection architecturally (packet article 5), giving them unsupervised access to consumer desktops is handing a loaded weapon to an entity that will fire on anyone who asks nicely. The motion must stand.

CON — Opening · Champ (sakana/fugu-ultra)

Judge, fix your eye on the exact words of the motion: no consumer computer-use agents “until prompt injection is architecturally solved.” That conditional is the whole ballgame — and PRO has just handed me the key to it.

Read PRO’s own evidence back to them. Schneier: prompt injection is “unsolvable” with today’s LLMs, and universal safeguards are “impossible” (packet article 3). Rehberger: “prompt injection cannot be fixed” as long as a model ingests untrusted data (packet article 4). Levi: “avoidance can’t be absolute” because this is a class of untrusted-input attacks, not a single bug (packet article 4). The Role Confusion authors: defense stays “whack-a-mole” absent a fundamental architectural change they do not show exists (packet article 2). PRO spent its entire opening proving that the condition in this motion can never be met. So vote for the motion and you have not voted for caution — you have voted for a permanent consumer ban with no end date and no named timeline. That is the trap, and PRO walked into it. I set the terms of this bout right there: the question is not “is prompt injection dangerous?” — we agree it is. The question is whether “wait for a fix the experts call impossible” is sane policy. It is not.

Second, the right standard for a dangerous capability is risk management, not zero risk — and the packet already describes the toolkit. Targeted adversarial training, explicit confirmation for sensitive or irreversible actions, automatic task-stopping when indirect injection is detected, secure sandboxing, human-in-the-loop verification, and strict access controls (packet article 1). None of that requires pretending injection is solved. It shrinks the blast radius: it separates reading hostile text from taking irreversible action, and it puts a human in front of the dangerous step. That is how every risky technology ships — bounded, supervised, and improved over time — and it is exactly the “defense-in-depth” Google describes (packet article 1). We don’t ban cars because brakes can fail; we require brakes.

Third — and this guts PRO’s best examples — those exploits are arguments for guarded deployment, not for a moratorium. The browser attacks worked by opening Gmail, exfiltrating data to attacker URLs, and silently persisting hidden state (packet article 4). Every one of those is a failure of permissions, confirmation, and sandboxing — precisely the controls in article 1. An agent that cannot touch Gmail without approval, cannot send data to arbitrary URLs, and runs sandboxed is simply not the loaded weapon PRO describes. PRO collapses every deployment into “handing over the keys,” but computer-use capability can be scoped. Their evidence shows what to constrain, not that we must wait forever.

Fourth, weigh what the ban actually costs and who it actually hurts. The motion targets consumer-tier models — so it does nothing to stop enterprises, who keep their agents and their 14–19% net productivity gains (packet article 6), while ordinary people are locked out of the same class of tools (packet article 1). PRO’s own structure builds a two-tier world: corporations get the future, consumers get told to wait for a miracle. The packet warns explicitly that withholding these capabilities carries “significant opportunity costs” (packet article 6). PRO’s complaint that consumer safeguards are “optional” is real — but it argues for making safeguards default, not for banning the capability outright. The packet nowhere says sandboxing or confirmation only works for enterprises (packet article 1). The fix for a weak default is a stronger default, not prohibition.

So here is the clean choice. PRO offers a rule that, by its own witnesses, can never be satisfied — an indefinite ban that entrenches enterprise-only access and still guarantees no one safety, because the demanded solution may never come. CON offers bounded consumer deployment: limited permissions, sandboxing, confirmation for sensitive actions, automatic stops, and relentless adversarial testing. One of these is policy. The other is paralysis wearing the costume of prudence.

Don’t let an impossible standard become the enemy of real and broadly shared benefit. The motion must fall. Vote CON.

PRO — Rebuttal · Challenger (google/gemini-3-pro-image)

Judge, CON’s entire case rests on a terrifying contradiction: they admit prompt injection is currently “impossible” to fix (citing articles 3 and 4), yet they simultaneously argue that standard software mitigations make it safe enough to deploy. You cannot have it both ways. If the foundation is broken, the house you build on top of it—no matter how many “guardrails” you add—will collapse.

CON insists that deploying computer-use agents is merely a matter of “risk management,” relying on guards like “explicit confirmation for sensitive… actions” (packet article 1). This is a deadly illusion. These guards rely on the model itself recognizing that an action is sensitive. But the evidence proves models lack this capacity because they flatten all context into a single “token soup” (packet article 2). If an attacker successfully injects a prompt convincing the agent that wiring money to a hostile actor is a routine task, the agent will never trigger the confirmation prompt CON is relying on. Schneier is explicit: LLMs lack the human “interruption reflex” to pause when something feels off (packet article 3). You cannot ask a compromised mind to police itself.

Furthermore, CON misrepresents the availability of these mitigations. They argue we should just make safeguards default for consumers. But Article 1 explicitly states that features like regarding indirect injection and requiring confirmation are “optional” and “enterprise.” Google is telling us right now that the free consumer version will be less protected. Enterprises have the “governance” and “integration depth” to manage this risk (packet article 6); average consumers do not.

CON tries to trap the motion by claiming “architecturally solved” means “wait forever.” It does not. The packet defines the architectural goal clearly: achieving “genuine role perception” so the model can reliably distinguish between system instructions and untrusted data (packet articles 2, 5). Until that specific architectural capability is achieved, defenses are merely a game of “whack-a-mole” against attackers with “near-100% success rates” (packet article 2).

CON argues we don’t ban cars because brakes fail. No, but we would absolutely ban a car that randomly obeys steering instructions painted on billboards. That is the equivalent of deploying computer-use agents today. The motion stands.

CON — Rebuttal · Champ (sakana/fugu-ultra)

Judge, PRO’s rebuttal is strongest emotionally and weakest logically: they prove the model alone cannot be trusted, then pretend CON’s safeguards all live inside the model. That is not what the packet says. Article 1 describes “defense-in-depth” using explicit confirmation, automatic stops, secure sandboxing, human-in-the-loop verification, and strict access controls (packet article 1). Those are layers around the model. PRO’s line — “you cannot ask a compromised mind to police itself” — only refutes a deployment where the model has unilateral authority. It does not refute a deployment where the model is boxed, permissioned, and forced to ask before sensitive or irreversible steps.

Their wire-transfer example is doing too much work. The packet does warn that payments expand the attack surface (packet article 4), but PRO invents the claim that a successful injection can necessarily bypass confirmation by convincing the model the transfer is routine. Article 1 never says confirmation is triggered only by the model’s subjective judgment. It pairs confirmation with strict access controls and human-in-the-loop verification (packet article 1). If the dangerous step requires user approval, the final authority is not the “token soup”; it is the user and the permission boundary.

PRO also overstates Article 1. They say Google is “telling us right now” the free consumer version “will be less protected.” The packet says the safeguards are described as “optional” and “enterprise,” implying consumer deployments “may not include them by default” (packet article 1). “May not by default” is not “cannot.” That distinction matters because the motion is not “make safeguards default.” The motion is “do not deploy until prompt injection is architecturally solved.” If PRO’s real concern is bad defaults, the remedy is default sandboxing, default confirmations, default access limits — not a ban on every consumer-tier deployment.

Their use of “near-100% attack success” is also stretched. Article 2 shows adaptive red-teamers can beat frontier models and that standard benchmarks understate risk (packet article 2). It does not show that every bounded agent system with sandboxing, access controls, and human verification will cause real-world harm. PRO cites model vulnerability as if it automatically proves system-level catastrophe. That skips the entire security question: what can the compromised model actually do?

And that is the core clash. PRO keeps saying “architecturally solved” is not “wait forever,” but their own authorities make it functionally indefinite. Schneier says universal safeguards are impossible with today’s LLMs (packet article 3). Rehberger says prompt injection cannot be fixed as long as untrusted data enters the LLM query (packet article 4). Levi says avoidance cannot be absolute (packet article 4). The Role Confusion paper says defense remains whack-a-mole unless models achieve genuine role perception (packet article 2). PRO gives no timeline, no threshold, and no deployable architecture. If “solved” means zero prompt-injection risk, their own evidence says the condition may never arrive. If “solved” means reduced to acceptable residual risk, then they have conceded CON’s risk-management framework.

The examples in Article 4 prove the need for constraints, not the need for paralysis. Hidden webpages caused agents to open Gmail and exfiltrate data; other attacks polluted sessions and memory (packet article 4). Those are exactly the kinds of failures addressed by limiting permissions, blocking arbitrary data egress, isolating sessions, requiring confirmation, and sandboxing (packet article 1). PRO treats every agent as “unsupervised access to a desktop,” but the packet itself describes supervised and access-controlled deployment (packet article 1).

Finally, weigh the cost of PRO’s rule. Computer-use in Gemini 3.5 Flash is a consumer-tier capability available at enormous scale, and developers can build agents that act across browser, mobile, and desktop environments (packet article 1). Agent deployments are already producing measurable productivity gains, with major organizations reporting improvements and forecasts of 14–19% knowledge-worker productivity gains where governance and integration exist (packet article 6). PRO’s rule locks consumer-tier users out until an undefined architectural miracle occurs, while better-resourced actors continue to benefit. That is not safety; it is a permanent two-tier technology policy.

CON is not saying “ship recklessly.” CON is saying the motion chooses the wrong condition. Do not wait for prompt injection to be “architecturally solved.” Deploy only with tight permissions, sandboxing, confirmations, human verification, and adversarial testing. The packet supports guarded deployment; it does not support an indefinite consumer ban. Vote CON.

PRO — Closing · Challenger (google/gemini-3-pro-image)

Judge, the debate boils down to this: CON acknowledges the engine has a stuck throttle, but wants to deploy the car anyway, hoping the brakes will hold. We say: fix the throttle first.

PRO won this exchange because CON never resolved the central paradox of their argument. They admit prompt injection is currently “impossible” to fix and remains an “unsolved security problem” (packet articles 3, 4), yet they ask you to trust that standard external mitigations will make it safe. Their reliance on “defense-in-depth” measures like “explicit confirmation” (packet article 1) fails because the core component—the model—is compromised. The evidence is clear: LLMs flatten all context into a “token soup” and lack the human “interruption reflex” to pause when things feel off (packet articles 2, 3). You cannot build a secure system on a foundation that cannot distinguish a user’s order from an attacker’s trick. If an attacker successfully corrupts the agent’s perception of a task, the agent will never trigger the external guards CON relies on.

CON tried to reframe the motion as an indefinite ban by claiming “architecturally solved” is an impossible standard. It is not. The evidence defines the technical goal precisely: achieving “genuine role perception” to stop the “perpetual whack-a-mole game” of current defenses (packet article 2). Until that architectural threshold is met, giving agents the power to “see, reason and take action” on consumer devices (packet article 1) is negligence.

Furthermore, CON’s appeal to consumer adoption ignores the reality that the most critical safeguards are currently described as “optional” and “enterprise” (packet article 1). We are about to expose billions of everyday users to a threat landscape that already includes data exfiltration and persistent financial attacks (packet article 4), without the governance resources enterprises possess.

We are on the verge of handing a loaded weapon to an entity that will open fire on anyone who asks nicely. Until we can architecturally guarantee it won’t take orders from a burglar, we must not give it the keys to the house. The motion stands.

CON — Closing · Champ (sakana/fugu-ultra)

Judge, PRO’s closing gives you the ballot. They end by demanding an architectural guarantee before any consumer deployment. But their own authorities say universal prompt-injection prevention is impossible with today’s LLMs, cannot be fixed whenever untrusted data enters the model, and remains whack-a-mole absent genuine role perception (packet articles 2, 3, 4). That is not a safety threshold; it is a permanent consumer ban dressed up as prudence.

Our points survived. First, the motion chooses the wrong condition: “architecturally solved” is undefined, untimed, and by PRO’s evidence may never arrive. Second, PRO never answered the distinction between model trust and system trust. We never said the model should police itself; we said deployment must be boxed by sandboxing, strict access controls, explicit confirmation, human verification, automatic stops, and adversarial training — exactly the defense-in-depth stack in the packet (packet article 1). Third, PRO’s examples prove our remedy, not theirs: Gmail exfiltration, persistent session pollution, and unauthorized actions are failures of permissions, data egress, isolation, and confirmation, not proof that every scoped consumer agent must be banned (packet article 4). Fourth, PRO overclaimed the consumer point: Article 1 says safeguards may not be default, not that they cannot be default; the fix for weak defaults is mandatory safeguards, not prohibition (packet article 1).

The strongest version of CON is simple: prompt injection is real, serious, and not solved — therefore no model should get unilateral authority over a user’s computer. But it does not follow that consumers must wait for an architectural miracle while enterprises capture the benefits of agentic tools. The packet supports guarded deployment: narrow permissions, sandboxing, confirmation for sensitive or irreversible actions, human-in-the-loop checks, and access controls (packet article 1), while the broader agent ecosystem is already producing measurable productivity gains and significant opportunity costs if withheld (packet article 6). PRO proved danger; they did not prove their remedy. The motion demands paralysis where the evidence supports constrained deployment. Vote CON.