Willison's reverse-engineering shows the model chooses tools and issues searches at inference time rather than pulling from a pre-indexed chunk set. He treats this as the key insight of the piece: understanding the connector system as an agent loop is what makes its behavior — and its risks — legible.
Submitted Willison's post to HN where it hit 100 points, signaling the community values the architectural teardown over marketing coverage. The framing of ChatGPT Work as an agent system rather than RAG is what makes the submission noteworthy.
Willison flags that when the model decides at runtime what to fetch across Gmail, Drive, Slack and more, every message and document in scope becomes part of the prompt surface. He notes OpenAI has hardened some paths after prior injection reports but says the guardrails still feel thin — a hostile email sitting in an archive is effectively a latent instruction to the agent.
The editorial extends Willison's threat-model framing, arguing the shift from bounded RAG retrieval to runtime tool selection is precisely what changes the security posture. It reframes the piece as a field manual for teams about to point ChatGPT at their real inboxes.
The editorial explicitly frames the value of the post as filling a documentation gap OpenAI itself has left — probing tool schemas, system prompt scaffolding, and connector invocation order. It positions independent technical writeups as the actual source of truth for enterprise adopters evaluating the feature.
Simon Willison published a long walkthrough of ChatGPT's new Work mode — the connector-heavy tier OpenAI has been rolling out to business accounts — and, as usual, his write-up is more useful than OpenAI's own docs. The feature lets ChatGPT reach into Gmail, Google Drive, GitHub, Outlook, SharePoint, Slack, Notion, HubSpot, Linear and a handful of other systems, then answer questions that span them.
Willison's post is essentially a reverse-engineering exercise. He probes what the model actually *does* when you ask it something like "summarize what my team shipped last week" — which connectors it hits, in what order, how it decides what to fetch, and what the tool schemas look like. The short version: ChatGPT Work isn't a retrieval pipeline in the classic RAG sense — it's an agent loop, with the model choosing tools and issuing searches on the fly.
He also pulls out the system prompt scaffolding around the connectors, notes where OpenAI has clearly hardened things after prior injection reports, and flags the places where the guardrails still feel thin. The piece lands the way Willison's posts usually do: not as a review, but as a field manual for people who are about to put this thing in front of their real inbox.
Most "ChatGPT can now read your Gmail" coverage stops at the demo. Willison's contribution is to make the architecture legible. And the architecture matters, because it changes the threat model.
A classic RAG system retrieves a bounded set of chunks and stuffs them into a prompt; an agentic connector system lets the model decide, at inference time, what to fetch and from where. That's more powerful — it's how you get answers that span three tools without pre-indexing everything — but it means every document, message, ticket and calendar invite in scope is effectively part of the prompt surface. A single hostile email sitting in your Gmail archive is now a potential instruction to the agent, not just data.
This is not theoretical. Willison has been documenting variations of the confused deputy and prompt-injection-via-connector problem for two years, and each new integration surface has shipped with a fresh class of it. His teardown shows OpenAI has clearly learned from previous rounds — there's visible scaffolding telling the model to distrust content it retrieves — but scaffolding in the system prompt is not a security boundary. It's a suggestion.
The second thing worth naming: this is OpenAI's real answer to Microsoft Copilot for Microsoft 365 and to Glean. The pitch is no longer "chat with a model," it's "replace the enterprise search box, plus do work on top of it." That's a much bigger surface area, sold to buyers who mostly can't evaluate the security posture themselves. The people who *can* — Willison, and the small cohort of researchers doing this work in public — are effectively QA'ing a product that's already being rolled out to seat counts in the tens of thousands.
The third thing: this is where the LLM industry's insistence on "trust the model to do the right thing" collides hardest with two decades of least-privilege thinking in enterprise IT. A connector token that can read all of a user's Drive is a token that, in an agentic setup, can be *induced* to read all of a user's Drive on behalf of an attacker. The mitigations right now are per-request confirmations, output filtering, and hope.
If you're an engineer whose company is about to turn Work mode on, a few practical notes.
First, scope the connector tokens like you'd scope any other integration — not like a chat feature. If your Drive connector is granted with the same OAuth scope your users have, then the model has the same read reach as your users, and prompt injection is a privilege-escalation vector, not a UX bug. Push for per-folder or per-label scoping where the connector supports it. GitHub's app-installation model is closer to the right shape than the "authorize the whole account" pattern most others still use.
Second, log everything the agent does. Willison's post makes it clear the tool-call traces exist; make sure your admin surface actually exposes them. If the audit trail for "ChatGPT read this doc on behalf of Alice at 3pm" doesn't live somewhere your DLP team can query, you don't have an audit trail. You have marketing copy.
Third, treat inbound channels — email, Slack DMs, shared docs from outside the org — as untrusted input to the LLM, not just to humans. The old rule was "don't click links from strangers." The new rule is "don't let your agent read messages from strangers unless the retrieval path strips instructions." Nobody has a clean answer for how to do that yet, which is itself the point.
For teams building competing products: Willison's teardown is also a spec. The connector list, the tool-schema shape, the way the agent decides between search and direct fetch — all of that is now roughly public. If you're building the open-source or self-hosted version of this, you have a working reference.
The interesting question over the next six months isn't whether ChatGPT Work gains adoption — it will, because the demo is genuinely good and the buyer is a CIO, not a security engineer. It's whether the first public incident is a data exfiltration via a poisoned document, an accidental cross-tenant leak, or a plain old misconfigured connector. All three are on the table, and the mitigations that exist today are largely convention, not enforcement. Willison's post is worth reading in full before you turn any of this on inside your org.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.