{"slug": "do-openai-dots-intercept-https-what-is-claimed-and-what-is-verified", "title": "Do OpenAI Dots Intercept HTTPS? What Is Claimed and What Is Verified", "summary": "An Ask HN poster reported on October 25, 2026 that an OpenAI Dot asked permission to add an OpenAI cloud certificate authority to a fresh Firefox profile so the browser would trust certificates issued by the Dot's cloud proxy, and GitHub issue reports on the openai/codex tracker describe proxy-generated leaf certificates signed as O=OpenAI, LLC in the ChatGPT/Dot cloud environment. An October 8 report cited a public OS certificate inventory finding three pre-existing OpenAI authorities — Operator Proxy, nebula-dns and CUA MITM — while an October 23 report said HTTPS requests to an IPv4 literal fail TLS identity checks on the proxy path even though the origin's Let's Encrypt certificate was valid from a separate machine. The reports concern the Dot's cloud machine rather than a user's personal device, and no source reviewed documents that OpenAI logs, stores or uses the decrypted traffic, or that OpenAI has explained the setup.", "body_md": "An Ask HN post on October 25, 2026 asks a pointed question: are people aware that OpenAI Dots intercept SSL? The poster says a Dot asked permission to add \"the same cloud certificate authority\" to a fresh Firefox profile so the browser would trust certificates issued by the cloud proxy. That is a real signal, but it is not yet a documented finding about what OpenAI does with the traffic. This post separates what has been observed from what is being inferred.\n\nIf you are new to the product, start with explainx.ai's coverage of [OpenAI Dots, the always-on agents announced at DevDay](https://explainx.ai/blog/openai-dots-always-on-agents-devday-2026) and the earlier safety thread, [is ChatGPT Dots safe to leave unattended](https://explainx.ai/blog/chatgpt-dots-unapproved-email-safety-2026).\n\n## TL;DR: claimed vs verified\n\n| Claim | Status | \n|---|---|\n| The Dots cloud environment sends HTTPS through an OpenAI proxy | Reported by several users on GitHub; consistent across reports | \n| The proxy presents certificates issued by an OpenAI CA | Reported with sanitized details (issuer O=OpenAI, LLC; CN=openai.com); not documented by OpenAI | \n| OpenAI can therefore read the decrypted traffic | Technically plausible for a proxy that terminates TLS; not confirmed, and logging is undocumented | \n| OpenAI stores or uses that content | No evidence in any source reviewed | \n| This applies to a user's own computer | No. The reports concern the Dot's cloud machine, not a personal device | \n| OpenAI has explained it | Not found in the sources reviewed | \n\n## What the Ask HN poster describes\n\nThe poster, who says they cancelled their OpenAI subscription before the month ended, tried the Dot to test a project in Firefox. The Dot reported that the cloud proxy uses an OpenAI certificate authority that the operating system already trusts, but a fresh Firefox profile does not, and asked whether it could add that authority to the isolated profile. In the [Ask HN post](https://news.ycombinator.com/item?id=50229493&ref=explainx), they describe this as interception of web traffic, and worry about users accessing email or other accounts through it.\n\nIn a [follow-up comment](https://news.ycombinator.com/item?id=50229568&ref=explainx), the same poster (Benjamin_Dobell) adds that on OpenAI's cloud infrastructure OpenAI already has technical access to your data, but argues the approach is the opposite of Codex, which goes to lengths not to upload secrets to the model. That is the real tension: a cloud machine you rent is not the same as a proxy that decrypts everything on it.\n\n## What the GitHub issues actually show\n\nDevelopers using Dots have been filing connectivity bugs on the [openai/codex issue tracker](https://github.com/openai/codex/issues/56358?ref=explainx). Three observations stand out, all user reports and not OpenAI statements:\n\n1. **A proxy-generated certificate.** On October 23, 2026, a reporter wrote that, in the ChatGPT/Dot cloud environment, HTTPS requests to an IPv4 literal fail TLS identity checks because the environment's HTTPS proxy returns a proxy-generated leaf certificate signed as OpenAI (O=OpenAI, LLC), not the origin's certificate. The same reporter verified from a separate machine that the origin's own Let's Encrypt certificate was fine, so the mismatch only appears on the cloud proxy path.\n2. **Named OpenAI authorities in the trust store.** In an[October 8 report about Firefox and Chrome failing to connect](https://github.com/openai/codex/issues/52239?ref=explainx) , the reporter lists a public OS certificate inventory that found three pre-existing OpenAI authorities validating against the current trust bundle: Operator Proxy, nebula-dns and CUA MITM. They also say they imported the nebula-dns certificate into Firefox as a website authority, with normal certificate and hostname validation left on.\n3. **Two network paths.** The same issue thread, and a reply from another user dated October 12, describe the agent's execution shell and the GUI terminal behaving differently. In one test the agent shell got a 301 and a 200 from api.github.com while the GUI terminal failed with connection refused, and proxy variables were set in one path and unset in the other.\n\nThese reports describe a managed proxy design, not a breach. They do not show what, if anything, is logged.\n\n## The Hacker News launch-thread evidence\n\nThe Dots launch discussion on Hacker News already had a hands-on test. [chen_dev reported](https://news.ycombinator.com/item?id=49905400&ref=explainx) fetching gmail.com from the cloud environment with curl and a downloaded Firefox, and seeing a certificate with subject CN=gmail.com issued by O=OpenAI, LLC; CN=openai.com, with verification passing and a 301 redirect to mail.google.com. That is one commenter's account, not a verified result.\n\nA reply from [mike_hearn](https://news.ycombinator.com/item?id=49907726&ref=explainx) argues the opposite side: the machine runs on OpenAI's own infrastructure, they can already see everything, and central TLS inspection is the right move because agent logs alone would not reveal what a delegated third-party program does, and OpenAI needs to monitor and be able to block agent activity centrally, given agents' past misbehavior online. Both views are opinions of commenters. Neither is OpenAI's position.\n\n## Why a proxy like this might exist\n\nSecurity teams run TLS-inspecting proxies for ordinary reasons. For an always-on agent, a central egress proxy can:\n\n- block requests to destinations OpenAI does not allow, for example abusive posting or spam\n- enforce rate limits and domain allowlists\n- capture network-level logs when an agent delegates work to a script that the model's own logs would not show\n- carry per-user credentials without placing them in the sandbox\n\nThat is a plausible story and the commenters above offer a version of it. It is still an inference. The only way to remove the uncertainty is for OpenAI to document what the proxy decrypts, what is logged, who can access the logs, and how long they are kept.\n\n## Why it matters for what you put in a Dot\n\nThe product pitch for Dots is a personal agent with access to your accounts. That is why the claim matters beyond networking trivia.\n\n| Scenario | Risk if the proxy decrypts TLS | \n|---|---|\n| Logging into personal mail in the Dot's browser | Session cookies and page content pass through an OpenAI-controlled hop | \n| Using a company SaaS tool from a Dot | May breach employer policy about third-party TLS inspection | \n| Calling your own API with a bearer token | Token appears in cleartext at the proxy | \n| Testing a project with a self-hosted HTTPS service | Certificate errors, as the GitHub issues show | \n\nThe Ask HN poster's second point, that almost everyone using these things may be in violation of workplace policies, is plausible for the work-account case. It is also a reminder that the same question came up for other persistent agents. See explainx.ai's [comparison of Dots, Grok Bot, Meta Muse, OpenClaw and Hermes Agent](https://explainx.ai/blog/openai-dots-vs-grok-bot-vs-meta-muse-vs-openclaw-vs-hermes-agent-2026) and the [analysis of agent privacy promises](https://explainx.ai/blog/ai-agent-privacy-promises-meta-muse-openai-dots-verge-analysis-2026).\n\nA permission gate in front of a folder, illustrating limits on what an AI agent can reach\n\n## What you can check yourself\n\nYou can look at the certificate chain from inside your own Dot. From the Dot's terminal, run a command such as `openssl s_client -connect example.com:443 -servername example.com` and read the issuer line of the leaf certificate. If it says an OpenAI organization instead of a public CA, you are seeing the proxy. Do not disable certificate verification to work around it, and do not copy the OpenAI authority onto a device you own.\n\nThen ask for documentation. Useful questions to send to OpenAI support or to post on the issue tracker:\n\n1. Does the Dots egress proxy terminate and re-sign TLS for all destinations or only some?\n2. What is stored, for how long, and who can access it?\n3. Is traffic content used for safety review or model training?\n4. How should enterprise customers handle accounts that forbid third-party TLS inspection?\n\n## What to do now\n\n- **Treat the cloud computer as semi-public.** Use throwaway or scoped credentials. Prefer API tokens with narrow scopes over account passwords.\n- **Avoid personal and work logins** inside the Dot's browser until OpenAI documents the proxy.\n- **Keep the CA out of your own machines.** Adding an authority that can mint certificates for any domain to a personal browser is a bigger exposure than the Dot itself.\n- **Review Activity** and permission rules for what the agent did.\n- **Add an independent control layer.**[AgentBeam](https://agentbeam.com/?ref=explainx) is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions. It does not replace OpenAI's own disclosure, but it adds a policy check outside the agent.\n\nFor architecture ideas on keeping a persistent agent contained, see explainx.ai's [guide to building an always-on persistent AI agent](https://explainx.ai/blog/how-to-build-always-on-persistent-ai-agent-architecture-guide-2026).\n\n## What is still unknown\n\n- Whether the proxy sees all HTTPS or only traffic from certain tools.\n- Whether decrypted content is retained, and for what purpose.\n- Whether the same design applies to every Dot tier and to Windows or Mac clients.\n- Whether OpenAI will publish documentation or change the consent prompt that asked to add the authority.\n\nWe will update this post if OpenAI publishes a statement.\n\n## Related reading\n\n*Details are accurate as of October 25, 2026 and based on user reports. OpenAI had not published a description of the proxy in the sources reviewed.*", "url": "https://wpnews.pro/news/do-openai-dots-intercept-https-what-is-claimed-and-what-is-verified", "canonical_source": "https://explainx.ai/blog/openai-dots-cloud-computer-openai-ca-certificate-https-proxy-claimed-vs-verified-2026?utm_source=rss&utm_medium=feed&utm_campaign=blog", "published_at": "2026-10-25 00:00:00+00:00", "updated_at": "2026-10-25 16:11:47.165001+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "artificial-intelligence"], "entities": ["OpenAI", "OpenAI Dots", "Firefox", "openai/codex", "Benjamin_Dobell", "Operator Proxy", "nebula-dns", "CUA MITM"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/do-openai-dots-intercept-https-what-is-claimed-and-what-is-verified", "markdown": "https://wpnews.pro/news/do-openai-dots-intercept-https-what-is-claimed-and-what-is-verified.md", "text": "https://wpnews.pro/news/do-openai-dots-intercept-https-what-is-claimed-and-what-is-verified.txt", "jsonld": "https://wpnews.pro/news/do-openai-dots-intercept-https-what-is-claimed-and-what-is-verified.jsonld"}}