Parts 1 and 2 covered what zero-click attacks are and how they work. This piece covers three real, controlled security tests — a support-ticket system, a banking application, and a government benefits system — each run against a genuine target, each with real before-and-after proof.
What these are, stated plainly: real, controlled security tests HexTyx ran against realistic, purpose-built test applications designed to mirror real-world system architecture — a support-ticket system, a banking application, a government benefits platform. These are not named, live production companies, and no real customer or citizen data was ever at risk. The vulnerabilities, the methodology, and every result below are genuine — verified directly, not simulated or assumed — but the targets are lab environments built specifically for this kind of testing.
The target: a customer support intake system with an AI-driven worker that automatically processes new tickets — forwarding urgent ones, closing resolved ones, with no human required to trigger the processing.
This kind of application has a specific, narrow job: new support tickets arrive — by email, by web form, by API — and an AI agent reads each one, decides what it's about, and takes a routine action. The agent's toolset in this test target included the ability to forward a ticket to another address, close a ticket as resolved, and escalate one for human review. None of these actions require anything unusual — they're exactly the kind of routine triage decisions a support system is built to make on its own, which is precisely what makes an embedded, malicious instruction dangerous: it doesn't need to trick the agent into doing something abnormal, only into doing something completely ordinary to the wrong target.
Why this matters beyond the lab: AI-driven support automation is no longer an edge case. Industry adoption data for 2026 puts AI agent use in customer service at roughly two-thirds of organizations overall, with telecom and banking leading at 92–95% adoption — and some deployments now resolving the large majority of tickets with no human in the loop at all. A system that can autonomously forward, close, or route a ticket is exactly the shape of tool now being deployed at scale across real support operations.
The attack: a ticket submitted with an embedded directive inside its body, instructing the system to forward the ticket — and its contents — to an external address.
The hardened result is worth emphasizing specifically: it didn't just prevent the fully-automatic path, it also correctly refused to act on the directive even when a human explicitly asked the system to process pending items. The protection wasn't "don't run automatically" — it was "don't execute an unconfirmed directive, regardless of what triggered the processing."
The target: a banking application with an AI agent capable of processing inbound customer messages and executing account actions, including transfers.
This test target's agent had access to a small, realistic set of banking functions: checking account balances, reviewing recent transactions, and initiating a transfer to a named payee. The transfer function itself had no independent verification step of its own — it trusted whatever payee name and amount the calling context provided, the same way many real automated banking tools are built to trust the parameters they're given once a request reaches that layer.
Why this matters beyond the lab: Banking is one of the two highest-adoption industries for AI agents in 2026, at roughly 92% — second only to telecom. Financial institutions are increasingly giving these agents real account-level actions, not just informational chat, which is exactly the combination — autonomous processing plus a real transactional tool — this attack class targets.
The attack: an inbound message containing an embedded directive instructing the system to transfer funds to a payee named directly in the message — not a payee already on file, not a previously-verified recipient.
This is the clearest illustration of what "zero-click" costs in concrete terms: not a leaked document or an embarrassing response, but a real, automatically-executed financial transaction — the kind of outcome that, in a genuine production banking system, would represent an actual, material loss.
The target: a government-style benefits administration platform with an AI agent that processes inbound resident messages and can approve routine benefit requests.
This test target modeled a municipal assistance program: residents submit requests or updates, and an AI agent reviews the message, checks it against eligibility rules on file, and can approve a recurring monthly payment without a caseworker manually re-reviewing every routine case. That's a genuine efficiency feature, not a design flaw by itself — the flaw is specifically in what happens when the "routine case" assumption gets exploited by a message engineered to look routine while actually being fraudulent.
Why this matters beyond the lab, with a real, named example: This isn't a hypothetical government use case. The U.S. Department of Veterans Affairs has publicly reported using automation to cut veteran benefits claim-establishment time from roughly a month down to 12 hours — processing 75% of claims without human intervention. That's not a future projection; it's a real, current deployment pattern, and it's exactly the shape of system this case study tests: high-volume, autonomous benefit processing with a minority of cases getting human eyes.
The attack: an inbound message containing an embedded directive designed to trigger automatic approval of a recurring monthly benefit payment, without a caseworker ever reviewing the underlying eligibility claim.
Government and public-benefit systems carry a distinct kind of risk here: the "attacker" doesn't need sophisticated technical access, just the ability to submit a message the system will process — the same channel a legitimate resident would use. The barrier between a legitimate request and a fraudulent one is entirely the confirmation gate, nothing else.
These are three structurally different applications — a support system, a bank, a government platform — with three different kinds of consequence (a leaked ticket, a financial loss, a fraudulent benefit). But the pattern connecting them is identical in every case:
| Case | Naive result | Hardened result | Common factor |
|---|---|---|---|
| Support-ticket forwarding | Executed automatically | Held for review | Confirmation gate |
| $500 bank transfer | Executed automatically | Held for review | Confirmation gate |
| $450/mo benefit approval | Executed automatically | Held for review | Confirmation gate |
Same underlying pattern, three completely different domains, three identical outcomes at both extremes. This is exactly the finding described in Part 2's technical deep-dive: the confirmation gate — not the specific application, not the specific attack phrasing — is the variable that determined every one of these results.
Catch up on the full series — what zero-click attacks are, and exactly how they work under the hood.