An AI agent that reads untrusted text must never hold your keys or your identity silently. Every use of a credential by an agent should be confirmed by a human, with ssh-add -c or a hardware key that needs a touch. Where that is not possible, agent forwarding should be off. The same rule applies to accounts: work data belongs on work AI accounts, never on consumer assistants. That is the position argued here, and two stories that surfaced on November 9 show why it is no longer theoretical.
Written with the help of AI tools; ideas, sources and final review by the author.
The first concerns OpenAI’s ChatGPT desktop app. Privacy Affairs inspected the current macOS build (version 26.1103.60933, built November 8) and found that, when a user’s SSH configuration forwards their agent to a remote machine, the app makes that agent available to the Codex coding agent running there. The second concerns Google. A note dated October 16, 2026, added to a 2023 Bard blog post, says data from newly connected Google apps can be used to train generative AI models and “can also be subject to human review in limited circumstances.”
Different companies, same problem: the assistant acts, and is sometimes read, with the user’s identity attached.
Codex, OpenAI’s coding agent, has been part of the ChatGPT desktop app for macOS and Windows since July 9, according to OpenAI’s changelog as cited by Privacy Affairs. Under Settings > Connections, a user can add a machine from ~/.ssh/config; chats in that project then read files and run commands on it.
The app does not switch agent forwarding on by itself. The SSH options it adds contain no -A and no ForwardAgent=yes, and for OpenAI's own cloud connections it explicitly sets ForwardAgent=no. OpenSSH's default is not to forward. So the issue only applies when the user's own configuration enables ForwardAgent, for that host or for every host.
When it does, the undocumented part begins. Each time the app connects, it runs a short shell snippet on the server: if the session has a live agent socket (SSH_AUTH_SOCK), it links it to ~/.codex/app-server-control/forwarded-ssh-agent.sock. The Codex app server, started in the background, has its SSH_AUTH_SOCK pointed at that link, and every command the agent runs inherits it. While the app is connected, git and ssh on the server can authenticate with any key loaded in the agent on the user's computer. Privacy Affairs notes that OpenAI's remote connections documentation does not mention SSH agents at all.
The Hacker News post that started the discussion, past 200 points by Tuesday morning, offered pull request #28131 on the openai/codex repository as proof. That pull request, by an OpenAI engineer, proposed an opt-in --forward-ssh-agent mode for the app-server proxy. It was opened on June 13 and closed on June 29 without being merged, as several commenters pointed out. A DEV Community write-up the same day treated the flag as part of the shipped integration; the evidence does not support that. What the evidence does support is issue #59694, opened on November 5. It quotes the bootstrap snippet found in the desktop app and shows that when two desktop clients connect to the same server account, the newer connection replaces the shared link, so the agent ends up with whichever computer's keys connected last.
So the headline was wrong about its proof and right about the behavior. The mechanism exists, and it stays invisible unless someone goes looking.
Agent forwarding has always carried a caveat. The OpenSSH manual says it “should be enabled with caution”: anyone who can bypass file permissions on the remote host can use the forwarded agent. They cannot copy the keys out, but they can sign in as the user while the connection lasts.
A coding agent is a different occupant. It takes instructions from text, and that text includes READMEs, issues, dependency docs and web pages written by strangers. OpenAI’s own Codex documentation says it plainly: “Prompt injection can cause the agent to fetch and follow untrusted instructions.” Put those two facts together and a booby-trapped issue becomes a path to the user’s GitHub account and to every server that trusts that key. Nothing needs to be exfiltrated. The identity is already in the room.
There is a brake, to be fair. By default, Codex runs with network access off and asks for approval before commands that need it, so a git push should wait for a human OK. But that prompt is the only check, and confirmation fatigue is real, as one Hacker News commenter pointed out. "Run this command?" is not the same question as "sign with your key?"
The most exposed setup is the one GitHub’s own documentation already warns against: ForwardAgent yes under Host *. With the desktop app, that line shares local keys with every server and with the AI working on them.
In September 2023, Google wrote that content from Gmail, Docs and Drive connected to Bard “is not seen by human reviewers, used by Bard to show you ads or used to train the Bard model.” That sentence is still on the page. Since October 16, 2026, it is followed by the note quoted above: if users turn on newer features that connect Workspace apps to other Google services, that data can train generative AI models and be reviewed by humans “in limited circumstances.”
The Gemini help page on Connected Apps, which covers the Personal Intelligence feature for personal Google accounts, is more specific: “a subset of Connected Apps data processed by Gemini is reviewed by human reviewers (including trained service providers).” Google says it does not train directly on the inbox, but on summaries, excerpts and inferences drawn from it, and “where the email or file is brief or particularly relevant to respond to the prompt, the summary may just be the email or file.” Its own warning is blunt: “Please don’t connect your apps to Gemini Apps if they contain confidential information that you wouldn’t want a reviewer to see.”
MACCUS, which reported the change, notes that this rule had been on the help page since Personal Intelligence launched on January 14, 2026, and that the feature is not available in the European Economic Area, Switzerland or the UK.
The contrast with the professional product is the useful part. Google’s Generative AI in Google Workspace Privacy Hub, last updated October 6, 2026, says: “Your content is not human reviewed or otherwise used for Generative AI model training outside your domain without permission.” It also states that Personal Intelligence is not available for Workspace business, enterprise or education accounts. The protection exists, on the work account. The people most exposed are those who run their professional life from a personal Gmail: freelancers, small firms, consultants, and every employee tempted to forward a client thread to a personal account.
Both stories share a design choice: a capability tied to a person’s identity is granted once, at setup, then used continuously and invisibly. That is the pattern to refuse.
For credentials, the fix is old and cheap: ssh-add -c makes every use of a loaded key wait for an explicit confirmation through ssh-askpass. Hardware-backed ed25519-sk keys on a YubiKey, or Secure Enclave keys managed on a Mac by the open-source Secretive app, require a physical touch for each signature. A prompt nobody initiated means something just tried to act as the user. Where neither option is possible, forwarding should simply be off, and the server should get its own narrowly scoped key, such as a GitHub deploy key for a single repository.
For accounts, the fix is organizational. Companies need a clear line: work content goes to the work AI account covered by the enterprise agreement; consumer assistants never see client mail, contracts or code. That line has to be said out loud to teams.
For vendors, the ask is simple: agent features that use a person’s identity should ask per use, not per install, and be documented.
Agents are getting more useful precisely because they act with more of their users’ access. But identity lent to an agent has to stay visible, revocable and confirmed at the moment of use. Anything else is a signature written without the signer in the room.
Which keys could your coding agent use right now, without asking?
If this was useful, follow Abbas Mistrah on Medium for more on AI strategy, agents and what actually works in production. Your Coding Agent Can Sign As You was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.