Please open a private security advisory on GitHub (Security → Report a vulnerability) rather than a public issue. If that isn't possible, email info@polyhelper.ai.

The free copy-paste path is entirely hand-driven and has no attack surface worth this page — you're just using the AI sites yourself. Everything below is about the optional hands-free path, where an agent drives a browser that holds your logins.

Our safety does not rely on "detecting bad text." It relies on what the agent is allowed to do.

Every answer the agent collects is untrusted input: a model's output can carry indirect prompt injection aimed at the orchestrator (OWASP LLM Top 10 — LLM01). Trying to strip "instructions" with a string filter is not a real defense: it can damage legitimate content, and perfect prevention is understood to be impossible inside standard transformer models. So we don't depend on it.

Instead, collected text is treated as quoted data, never as commands. If an upstream model hallucinates a tool-call block, or regurgitates an injected instruction, the orchestrator merges it as a citation and executes nothing from it. This is a safeguard that bounds the damage — not a guarantee that no model will ever be tricked into writing something wrong into the document.

A useful frame (Meta's Agents Rule of Two): an agent is dangerous when it holds all three of —

1. it processes untrusted input,
2. it can reach sensitive data / systems, and
3. it can change external state (buy, send, delete, post, call APIs).

PolyHelper's hands-free agent has the first two, and keeps the third as narrow as a capability can be:

• Ask-and-read only. It does take one outward action — the one you asked for: sending your question to the sites you named. Beyond that it does nothing outward: it never buys, posts, deletes, changes settings, or calls an API.
• Nothing it reads can become an action. No collected answer is ever allowed to trigger a new step, a new destination, or a new instruction. That's the cut that matters: the untrusted input and the outward action are never connected.
• So a poisoned upstream answer has nowhere to go — the realistic worst case is a wrong line in your document, which the provenance labels help you catch.

This follows capability-isolation research (CaMeL, information-flow control / FIDES), and it's why zero-click agent exploits like EchoLeak (CVE-2025-32711) succeed elsewhere: they chain all three capabilities into each other. We keep the third one pinned to a single user-initiated action and never let collected text reach it.

The limit: this is a prompt-level constraint plus a deliberately small tool surface — not a technical sandbox. It shrinks the blast radius; it does not prove the radius is zero.

Operational rules that follow from this:

• Run in a visible browser window — never headless/hidden.
• Use your existing logged-in session; never store or type credentials or cookies.
• Run it in a separate browser window/profile, away from the rest of your work.
• No CAPTCHA-solving, no anti-detect/fingerprint spoofing, no proxy rotation, no account pooling.

Since Chrome 136, the browser ignores --remote-debugging-port on your default profile (a fix against CDP-based cookie theft). Automation must use a separate --user-data-dir, so the agent runs in an isolated profile and you log in to your AIs inside that window first. This adds friction but is the safer arrangement — treat any tool that claims to silently attach to your everyday browser session with suspicion.

Hosted/multi-tenant browser farms, storing or forwarding cookies, CAPTCHA solving, stealth/fingerprint spoofing, proxy rotation, account pooling, or promising "no ban risk." See DISCLAIMER.md for what this tool is and is not.