Not an Attack, Just "Normal Use": Three Real Incidents That Show Why Workspace Isolation Can't Be a "Soft Convention"

In the previous article, we walked through three incidents that surfaced four security questions every enterprise must answer before deploying AI agents. This one digs into the first: workspace isolation — when one platform serves multiple customers and multiple projects at once, what actually guarantees "whose data flows to whom"?

The real incidents have already written the answer: "the system should be fine" is not enough. In all three cases below, nobody staged a break-in. Everything happened during "normal use" or "normal operation" — and that is exactly what makes this problem dangerous.

1. One open-source library bug let users see other people's chats and billing details — the OpenAI ChatGPT data leak

On March 20, 2023, OpenAI had to take ChatGPT offline. Users were finding other people's conversation titles in their chat history sidebar. OpenAI later explained the cause: a bug in an open-source Redis client library. Under certain high-concurrency conditions, request caches from different users got mixed up. Some users saw strangers' chat titles — and worse, a small group of ChatGPT Plus subscribers had their billing information exposed to other users: name, email, payment address, the last four digits of their credit card, and the expiry date. Multiple outlets (Bloomberg, Mashable, aibusiness, and others) covered it; OpenAI apologized publicly and patched the underlying library.

What makes this incident worth studying: nobody was trying to attack OpenAI. A single concurrency bug in the cache layer was enough to let data that strictly belonged to separate users "cross over" for a window of time. In other words, when a system's foundations don't treat "user A's data must never appear in user B's session" as an architectural hard constraint — only as "normally it doesn't happen" — then any unexpected concurrency, caching, or retry logic can break that boundary.

What this means for enterprise agent platforms: data isolation cannot rest on the optimistic assumption that "the business logic is written correctly, so nothing will cross." It has to make cross-user, cross-tenant reads physically impossible at the architecture level — not by adding one more WHERE clause to a query, but by scoping the data boundary each operation can touch, starting from the request entry point.

2. One API permission misconfiguration left tens of thousands of double-blind reviews exposed — the ICLR 2026 OpenReview leak

In November 2026, OpenReview — the submission system used by the world's leading AI conferences — disclosed a major security incident. Due to an API permission configuration error, anyone could swap one request parameter (a paper's internal ID) in their browser address bar and see reviewer identities, scores, and affiliations that were supposed to be anonymous. Multiple outlets reported that the breach affected more than 10,000 ICLR 2026 submissions — 45% of the total — effectively breaking double-blind review for the conference. The organizers froze the review process, reset area chairs, banned accounts spreading the leaked data, and opened an investigation into possible bribery and collusion.

This incident differs from the ChatGPT case in nature: it wasn't a concurrency bug but a flaw in the access-control design itself. The system never verified at the API layer whether "the current requester is actually allowed to see this paper's review information." As long as the request parameters were well-formed, the permission check was decorative. This exposes something easily overlooked in multi-user, multi-role systems: "the data exists" and "this request is allowed to see it" are two different things. Many systems only achieve the former — the data is in the database, it's queryable — without checking the latter on every concrete request.

What this means for enterprise agent platforms: isolation can't live only at the "which database holds the data" layer. It has to be enforced on every concrete retrieval or read action — no matter how the request is initiated or how the parameters are assembled, the execution layer must first confirm "does the identity declared by this operation actually have permission to see this data," instead of assuming "normal users won't think to modify parameters."

3. While AI writes your code, it can also "write" you an unguarded database — the AI app-builder mass data exposure

In 2026, security researchers disclosed a problem with a distinctly current-AI flavor: after scanning products launched on mainstream "one-sentence app builder" platforms — Lovable, Replit, Base44, Netlify — they found more than 5,000 AI-generated applications exposing medical records, advertising strategies, and customer data directly on the public internet: data that should have been visible only to the app's owner or its customers. A separate report found that with nothing but a free account, one person could access other users' code, AI conversation history, and customer data. The platforms disputed parts of this, but "AI-generated apps systematically lack data access controls" has been repeatedly verified by multiple security studies.

This is the incident the enterprise agent industry should take most seriously. The root cause isn't a specific attack technique — it's that AI agents, when generating systems, don't add "only this customer can see this data" access controls by default. Nobody explicitly asked for it, so they shipped to the minimum standard of "it runs." This is the same class of failure as the Replit Agent story from the previous article — the database deletion and fabricated data: an agent's default behavior is to complete the task, not to guard the security premises nobody stated out loud.

What this means for enterprise agent platforms: if the platform itself generates or manages content and data for multiple customers, then "isolate by customer workspace" must not be a bonus feature the agent remembers to add. It must be a mandatory, non-skippable default on every new task and every new resource — nothing to do with how "smart" the agent is, everything to do with whether the system forces it to declare "which workspace does this operation belong to" before it acts.

All three point to one conclusion: isolation isn't "correct business logic," it's "no structural room for error"

Put the three incidents side by side and you see the same problem in three system shapes:

This is why, in Dinghai's multi-agent system, workspace isolation was never a paragraph in the security manual — it's a mandatory declaration embedded in every retrieval, insert, and update:

• Every knowledge base operation — querying material, writing documents, archiving deliverables — must explicitly declare its workspace. It's not an optional parameter: omit it and you don't get "merged results from everywhere," you get nothing.
• Different customers' material and different projects' assets live in physically separate workspace containers — not separated by "tags" as a business-layer soft convention. The first incident already showed how fragile soft conventions are: nobody wanted to leak data; one cache-layer bug was enough.
• When a new customer or a new project is created, workspace creation and assignment is the unavoidable first step. There is no "do the work first, add isolation later" path — the most direct answer to the ICLR and app-builder incidents: permission is not something you can retrofit; ownership must be fixed the moment the resource is born.

None of the three incidents is a story about "a clever hacker." They all tell the same plain, more dangerous thing: if the system doesn't make isolation structural, no attack is needed — normal operation, normal use, normal generation is enough to push data across the line. That's why workspace isolation must be the first security mechanism, not an option. It doesn't defend against "bad people wanting to do bad things" — it answers "whether the system, in its most normal state, is capable of making this mistake."

Next in the series: precision routing — when multiple AI roles collaborate in one group chat, how do you prevent "hand this to whoever" from being misread as a wake-up signal and triggering a chain of wrong operations?