The most consequential thing OpenAI shipped on 29 September was not an agent. It was a room: ChatGPT Space, where teammates, ChatGPT, Codex and an always-on Dot all read from and write to the same context. A context that several principals can write to and several agents will act on is not a folder with a chat attached — it is a credential, held jointly, with the authority of whoever holds the most and the judgement of whoever holds the least. Every permission control on offer is pointed at the wrong boundary.
At a glance
DevDay 2026 carried more than twenty announcements. Four of them compose into one architecture, and it is the composition rather than any single piece that changes the threat model.
| What shipped | What it is | Why it matters here |
|---|---|---|
| Dots | Always-on agents on OpenAI's flagship model, each given its own cloud computer and browser, reachable via chat, Slack and Teams, and connectable to thousands of applications. | An agent that runs when no one is looking, with persistent state and a logged-in browser. The human-in-the-loop assumption is gone by design, not by accident. |
| ChatGPT Space | A shared workspace where employees, ChatGPT, Codex and Dots operate against the same shared context. | Several principals, one context. This is the part with no precedent in the permission models anyone has deployed. |
| Pages | A document type designed for humans and agents to co-author — text, charts, images, visualisations. | A mutable artefact that is simultaneously output and input. What one agent writes, the next one reads as context. |
| Computer use in the Agents API | Screen-level control available to developers building on the platform. | The action space stops being a tool list. Anything a logged-in browser can reach is now in scope. |
Each of these has shipped somewhere before in isolation. The combination — persistent autonomous execution, a shared multi-writer context, and screen-level reach — has not, and the security properties of a composition are not the intersection of its parts.
The architecture, drawn as a permission problem
Read the diagram right to left and the product looks reasonable: each connector is scope-limited, each action is attributable to an agent, each agent belongs to a workspace. Read it left to right and the problem is obvious. Five writers put bytes into one store. One reader is an autonomous process with a browser, a filesystem and thousands of app grants. There is no label on the read path saying which writer produced which bytes, and no mechanism that treats a paragraph from a hostile source differently from a paragraph typed by the team lead.
The industry has a name for the general case of this and it has been on this wiki for months: the reach of an agent is not the tool list you attached but the set of state it can change that something else can later read. A shared context store inverts it. The reach of a writer is not the permissions that writer holds but the set of agents that will later read what they wrote.
Why "shared context" is the same sentence as "shared credential"
Authority unions, judgement intersects
Put four members and two agents in a Space. The agents read everything in the Space and act with their own grants, which in practice are provisioned to cover what the team collectively needs. So the effective authority available to any instruction that lands in the context is the union of what the agents can do — but the barrier to landing an instruction there is the least careful member's paste. Authority composes upward; caution composes downward. That is the defining property of a shared credential, and it is why the security industry spent twenty years getting rid of them.
The write path is unauthenticated with respect to the reader
Workspace membership authenticates writers to the platform. It does not authenticate them to the reader, because the reader is a language model consuming a flat context in which a summary written by Codex, a PDF someone uploaded and a comment from an external collaborator are the same kind of object. Membership answers "may this person write here". The question the agent needs answered is "how much should I trust this block", and there is nothing in the surface that carries the answer.
Persistence removes the human who would have noticed
An interactive assistant that does something odd does it in front of someone. An always-on agent working toward a standing goal on its own schedule does not. Combine that with a shared context and the exposure window stops being a session and becomes the retention period of the document: text written into a Page in March is still in the context in September, still read as instruction-shaped input, still able to steer a run nobody is watching.
The blast radius is now organisational, not per-user
The failure that matters is no longer "an agent did something wrong for its user". It is "an agent did something wrong for its user because of something a different user's input said". That crosses a principal boundary, which means the incident belongs to two people and the audit trail belongs to neither — the exact shape that makes attribution arguments expensive.
Five boundaries, and the two that matter are the two you cannot buy
Per-connector scopes and per-agent credentials are genuinely good controls, and they are aimed at a call the agent makes on its own initiative. They have almost nothing to say about a hostile paste, because a paste is not a call — it is text that changes which calls the agent chooses to make, all of them within scope. Membership is better than nothing and stops only outsiders, which is the wrong threat: the dangerous writer in this architecture is usually a well-meaning insider forwarding a supplier's email.
The two rows that would actually work are per-block provenance — a label that travels with each piece of context and gates what the agent may do with it — and an egress policy on the agent's own runtime. Neither is offered. Provenance requires the platform to track authorship through summarisation, which is where labels are lost today. Egress control requires the ability to constrain a sandbox you do not operate, which is precisely what you give up when the agent gets "its own cloud computer".
Three readings of the same room
All three columns are accurate descriptions. The product one is how the feature is sold and how users will reason about it; the enforcement one is what the platform checks; the behavioural one is what an attacker plans against. Security work consists of moving your own mental model to the third column while the org chart is still operating on the first, and the specific move here is to stop asking "what can this agent do" and start asking "who can cause this agent to do it".
Note what the third column does not say. It does not say the architecture is unsafe or that Spaces should not be used; a shared context is genuinely how collaborative work gets done, and the productivity case is not in dispute. It says the unit of trust is the Space, so the Space is the thing that needs a scope — and right now the only scope it has is its membership list.
What to do if you are deploying into one
None of the controls below require the platform to ship anything. All of them are decisions about how you organise the work.
- Scope the Space, not the agent. Decide what authority is acceptable for the union of everything the Space can reach, then provision the agents down to that. One Space per trust domain — per customer, per team, per sensitivity tier — costs you convenience and buys you the only containment available.
- Keep externally-sourced material out of shared contexts. Supplier emails, vendor PDFs, scraped pages and support tickets are attacker-authored text. If they must be processed, process them in a Space with no write-capable connectors, and move conclusions across by hand.
- Treat an always-on agent's write access as a production credential. Review it the way you would review a service account: what can it change, who reviews the change, and what is the revocation path. A standing goal plus a write connector is a deploy pipeline with no approver.
- Make one human the named owner of each Space. Not the creator — the owner, who is accountable for its membership and its connector set, and who notices when both grow.
- Log writes, not just actions. Platform audit logs record what the agent did. You also need what it read and who put it there, because that is the only trail that answers a cross-principal incident. If the platform will not give you that, record it at the point where your own systems contribute content.
- Assume the summary is the payload. Anything that compresses the Space — a digest, a status Page, a daily brief — is where a hostile instruction gets laundered into a trusted-looking block with no author. Do not let a summariser's output be read as more authoritative than its worst input.
FAQ
Is this a criticism of OpenAI's design specifically?
No. Every vendor shipping collaborative agent workspaces in 2026 has the same gap, because per-block provenance through summarisation is an unsolved problem rather than a feature anyone chose to skip. DevDay is the clearest specimen because the pieces — persistence, shared context and screen-level reach — arrived together and at scale.
Do OAuth scopes not solve this?
They solve a different problem well. A scope constrains what a call may do; it cannot distinguish a call the agent chose for its user from a call the agent chose because a paragraph in the shared context told it to. Both are in scope by construction, which is why the scope is satisfied and the outcome is still wrong.
Does a single-user agent avoid the problem?
It reduces it to the ordinary injection case, where the only untrusted writers are the sources the agent fetches. That is still a real problem, but the authority available to an instruction is one person's rather than a team's, and the incident has one owner. The multi-writer case is strictly worse on both counts.
What is the smallest change with the largest effect?
One Space per trust domain, and no write-capable connectors in any Space that ingests external material. It costs convenience, requires no platform feature, and removes the composition that makes the rest of it dangerous.
How would I detect this going wrong?
Not by content inspection. Watch for an agent whose tool-call sequence stops resembling the sequences its task type usually produces, and for reads of context blocks that no member of the Space authored. Both are behavioural signals and both need the read path logged, which is the thing you have to arrange in advance.
Further reading
On this wiki:
- Ambient authority — why authority the agent did not have to ask for is the recurring shape of these failures.
- Context taint tracking — the label that would fix the read path, and why it is bookkeeping rather than classification.
- Blast radius — sizing what a single compromised run can reach.
- Shared memory and the blackboard pattern — the same architecture, analysed as a coordination mechanism.
- Unintended coordination between agents — what happens when agents read each other's output as instruction.
- Agents in shared channels — the UX half of the same problem.
- Shared and multi-user agents — designing for more than one principal.
- Detecting agent compromise — the behavioural signals that survive a classifier miss.
Sources:
- DevDay 2026 recap — OpenAI
- OpenAI launches Dots and ChatGPT Space — VentureBeat
- DevDay 2026 live updates — CNBC