Summary and evidence
ALL lets an authorized ChatGPT conversation use tools on your computer, including files, Terminal, desktop UI, browser and potentially privileged operations. This is meaningful authority, not a risk-free chat feature.
This page distinguishes what is deployed and production verified, what is in the source pending rollout, and what is not implemented. The control plane and public relay were verified in production on September 29, 2026. What this page describes from source remains source description, not a continuous live audit.
The relay can read MCP contents. No end-to-end encryption is live. An outbound connection does not make the relay blind or eliminate the consequences of compromised accounts or infrastructure.
Architecture and trust boundaries
The installation is split across a local runtime on the computer, the ALL control plane, a relay that routes ALL requests and responses, and the authorized ChatGPT integration. The device initiates the connection toward ALL infrastructure; the design does not require exposing an inbound public port on the customer computer.
The public website and ALL Guide are a separate surface. The website chat can explain the product and open checkout, but it has no tools for controlling the visitor computer. Device control exists only after ALL is installed, the device is registered and the relevant integration is authorized.
Deployment state: verified, available after updating, not implemented
The September 29 hardening ships in three tiers. Each protection belongs to exactly one of them.
- Deployed and production verified — control plane and relay: Ed25519 device credentials with a control-plane-only signing key and public verification keys on the relay; five-minute device sessions with a proof-of-possession handshake and in-band renewal; per-device Durable Objects coordinating replay records, identity generations and revocation; public discovery endpoints; and the relay running as a dedicated non-root user with zero Linux capabilities, no HMAC or master secret in its environment, header-allowlist forwarding, and access logging disabled on the relay and its reverse proxy. Verified with public endpoint probes, live process identity and sandbox inspection, log-suppression probes, and a real installed device completing authorization and MCP through the new stack.
- Runtime 0.6.7, active after updating — device side: a persistent local identity key in native secure storage, automatic short-session renewal, and hardened OAuth/PKCE with hashed secret state. Installed clients keep working today through legacy tokens validated online by the control plane. These protections activate when a client installs the updated runtime; migration is automatic, with no periodic reinstall or re-pairing. Lost keys, revocation or outages can still interrupt access.
- Not implemented: end-to-end encryption blinding the relay. TLS remains per-hop; the relay still reads in-flight payloads, and a compromised relay can read, save or modify them and misuse observed bearers within local authority.
License-page removal still requires private control-plane acknowledgement before site membership cleanup. If confirmation fails, the site must not report a released seat. Removing a device is not deletion of local files, task history or third-party copies, and is not a promise of instantaneous revocation everywhere.
OAuth and ChatGPT pairing
The integration uses OAuth and PKCE for ChatGPT pairing. The updated runtime strengthens that flow; on installed clients it activates after updating to runtime 0.6.7. A five-minute device session is not the same credential as a ChatGPT OAuth bearer.
A compromised relay can observe and reuse a valid OAuth bearer within its authority. Device proof of possession does not universally prevent that. The local runtime still decides whether a tool call is permitted.
Relay and data visibility
The relay terminates TLS and handles MCP request and response bodies in plaintext, including payloads transported as Base64. Base64 is not encryption. TLS protects individual network hops; it does not hide contents from the relay. No end-to-end encryption (E2EE) is live.
Traffic can contain file paths and excerpts, commands, terminal results, UI state, screenshots or other tool data. A compromised relay can read, save or modify in-flight payloads and reuse observed OAuth bearer tokens subject to local authorization. That can include command execution when local tool authority allows it; we cannot claim that a compromised relay cannot execute commands.
No deliberate relay body archive was found in application source. On the deployed relay, access logging is disabled on the relay and its reverse proxy, and synthetic probes confirmed that query strings are no longer logged. Host crash collection, swap and Cloudflare or provider retention were not exhaustively audited, and rotated archives from before September 29, 2026 may still contain expired pairing URLs pending an operator purge decision. This is not a blanket no-logs or no-storage claim.
Local tasks, workflows and results intentionally persist to support continuing work. Outputs sent back to a conversation go to ChatGPT, and optional AI-backed diagnosis, repair or vision may send relevant data to Workers AI. Local execution is not all-local processing. See Privacy.
Activity numbers, transfers and local records
This section describes the 0.7 source and was not part of the September 29, 2026 production verification. It describes ALL 0.7 and later; earlier versions report no activity numbers and have no transfers, journal, recipes or project index.
Installed computers report two whole numbers (operations completed today, in UTC, and jobs running) in their health record, next to version, platform and status. Nothing the operations touched, ran or printed is part of that record.
An encrypted file-transfer copy can be downloaded for at most 24 hours; after that it is deleted (deletion by the storage expiry rule can lag by up to one more day), and it cannot be opened without a key that is never sent to the storage endpoints. The sending computer encrypts with AES-256-GCM, with a new key and nonce for every transfer, and uploads in parts; each part carries its own SHA-256, which the control plane checks as the part arrives, and the receiving computer verifies the authentication tag and the file checksum before the file takes its final name. The key travels inside the ChatGPT conversation, so a compromised relay could see it: this protects the stored copy, not against the relay.
Several computers: a request is routed to another computer of the account only where ChatGPT holds its own live authorization on that computer, with the permissions the operation needs, and the account service also checks the license and the device registration; otherwise it is refused. “Disconnect ChatGPT from this computer” on the activity page revokes that authorization. Computers beyond three (extra seats) are added on request, and each keeps its own registration and authorization.
The local journal, saved recipes, project index and job summaries stay on the computer in ALL’s private state folder; ALL does not upload them. ALL itself never records file contents or command output in the journal, recipes or project index (a journal note holds whatever short text ChatGPT chooses to write in it); job records keep a digest and a log of command output and are not scrubbed of secrets. Notes and saved recipes written by earlier conversations are treated as data, not as your instructions. These files are not protected from software running as your user, so keep secrets in the environment or in a tool’s own login rather than on command lines. The same folder also holds, for 24 hours, a private receipt of the reply of most operations (it can contain file content and command output; the stored copy passes through redact_public_result, which would replace text matching a list of known credential formats with [credential redacted], but that list is empty in this version, so the reply is stored as returned and can also hold secrets that were in them; no receipt is kept for the replies of files.extract, jobs.status, jobs.wait, terminal.job.status, journal.recent, code.references and git.review), and, for up to 7 days, the transcript text, OCR text and video frames that the file reader writes for long jobs. Neither is uploaded by ALL. See Privacy.
Operating-system permissions
ALL does not attempt to hide or bypass native platform protections. Some capabilities require explicit approval from the user or administrator.
- macOS: Accessibility, Screen Recording, Full Disk Access and automation permissions where applicable.
- Windows: user permissions or administrative elevation for tasks that require it.
- Linux: user access, available desktop mechanisms and elevated privileges where required.
- Actual capabilities also depend on installed applications, authenticated sessions and device policy.
Privileged and high-impact operations
Some tools can install software, modify configuration, terminate processes or execute privileged commands. Checks, snapshots, approvals and limits depend on the capability and local policy. Do not assume every action requires a new confirmation or that every side effect can be rolled back.
Only administer systems you are authorized to control. For production, irreplaceable data, billing, credentials or public publishing, use appropriate human review, narrowly scoped access and independent backups.
Credentials and secrets
Customer packages do not contain Cloudflare master credentials, Workers AI master keys or ALL backend secrets. Device credentials are distinct from infrastructure master credentials.
ALL may operate a third-party session the user has already authenticated, such as a browser, GitHub, Cloudflare, App Store Connect or local software. That does not mean ALL owns those credentials or can bypass 2FA, agreements, subscriptions, permissions or approvals required by the third party.
Update integrity and repair
Plans entitled to updates use a private release channel authorized by the license. The agent checks release metadata and the artifact SHA-256 before installing an official update. Packages are served from private storage and authorization is checked before download.
The no-updates plan is limited to the purchased version recorded in its entitlement. Repairing an installation must not become a path to obtain a release that the plan does not include.
Website, payments and ALL Guide
The site source sets browser controls such as CSP, HSTS on HTTPS responses and framing restrictions. Stripe hosts payment collection; the site checks the payment server-side. These are source observations, not a fresh production audit.
Both website chats use Cloudflare Workers AI and have no computer-control tools. The privacy/security mode receives a fixed source knowledge context and an explicit three-tier deployment state chosen by the server, not by visitor text. Model answers can still be wrong and are not a human audit.
Chat prompts and results are not deliberately written to the site's license/lead KV or application logs. The site uses fixed chat error codes and disables automatic invocation logging and tracing; that does not establish provider-wide zero retention. Do not submit credentials, license links, screenshots or document contents. Read how chat data is processed.
Third-party dependencies
ALL integrates with or automates software and services it does not control. Changes to APIs, permissions, user interfaces, policies, operating systems or authentication flows can degrade or break a capability even if ALL itself has not changed. No third-party feature is guaranteed to remain available indefinitely.
Customer responsibilities
- Protect your ChatGPT account and devices where ALL is installed.
- Do not share activation keys, tokens or authenticated sessions with unauthorized people.
- Keep appropriate backups before destructive tasks or migrations.
- Review high-impact commands or actions when the context calls for it.
- Revoke access and remove the installation when a device is no longer under your control.
- Keep relevant operating systems and applications reasonably current.
Responsible vulnerability disclosure
Email admin@fynory.app with subject ALL Security. Start with a non-sensitive description of the impact, affected version/OS if known, and reproduction steps using synthetic data. Do not send tokens, passwords, private keys, license links, screenshots or document contents.
If compromise is suspected, stop sensitive work, disconnect the ALL integration or stop ALL locally, and contact support from a trusted device. This website chat cannot revoke access or verify containment.
- Do not access other users' data or systems.
- Do not cause outages, data loss or deliberate service degradation.
- Do not use phishing, social engineering or physical attacks.
- Allow reasonable time for investigation before public disclosure.
- No monetary bounty or response deadline is promised here.
Security limitations
No system capable of controlling a computer can promise zero risk. Signing, permissions, OAuth, secret isolation, license verification and an outbound architecture reduce risk, but they do not eliminate software defects, account compromise, human error, third-party vulnerabilities or harmful instructions.
Security also depends on how you configure your device, which permissions you grant and which actions you authorize.
Need to reach us?
Start with a non-sensitive description. Never send credentials, license links, screenshots or document contents.
admin@fynory.app