playbook
ChatGPT projects and shared workspace risks
A practical security guide for small teams using ChatGPT Projects, shared projects, files, instructions, memory, links, and workspace collaboration.
Bottom line
ChatGPT Projects are useful because they collect chats, files, and instructions around a single workflow. That same convenience can turn a project into a long-running mini knowledge base with customer files, support context, sales notes, contracts, screenshots, and team decisions. Small teams should approve shared projects as workspaces, not as casual folders.
Use this default rule:
Do not share a ChatGPT Project until the owner, members, files, instructions, data classes, memory boundary, and deletion rule are documented.OpenAI’s Projects documentation says shared project members can view chats and files in the project, and uploaded files can be used by ChatGPT in responses visible to other project members. OpenAI’s ChatGPT Business privacy documentation also says Business users have private chat histories by default, but sharing a project changes the collaboration boundary for content placed inside that project.
Before using a shared project for customer or internal work, run the AI Tool Risk Checker and record the project rule in the Small Team AI Security Checklist. If customer tickets or support replies are involved, pair this with the support ChatGPT policy and ticket redaction workflow.
Shared project risk matrix
| Project use case | Main risk | Default decision |
|---|---|---|
| Public content drafting | Low data sensitivity, but brand and accuracy risk. | Allow with editor review. |
| Internal operations playbook | Internal decisions, owners, and process details may become broadly visible. | Allow with named owner and limited members. |
| Support-ticket summaries | Customer data, account context, screenshots, and incident notes may persist in project chats/files. | Pilot only with redaction and retention rule. |
| Sales or customer success project | Contracts, pricing, renewal risk, customer names, and private account notes. | Restrict to account team and approved sources. |
| Engineering investigation | Logs, source snippets, stack traces, internal URLs, and credentials may appear. | Restrict; no secrets or production logs by default. |
| Security incident workspace | Vulnerability details, indicators, affected customers, credentials, and legal context. | Do not use normal project workflow; route to incident process. |
| Shared project with workspace link | More people may join than intended if the link remains open. | Prefer invite-only; review member list and link setting. |
The safest first version is one project, one workflow, named members, no broad customer history, and a review date.
Project approval checklist
Use this before creating or sharing a project.
- Name the project owner and backup owner.
- Define the business purpose in one sentence.
- List allowed data classes: public, internal, customer, sensitive customer, regulated, security, or source code.
- List prohibited data: secrets, credentials, payment details, regulated data, raw customer exports, incident evidence, or legal files.
- Decide whether files can be uploaded.
- Decide whether existing chats can be moved into the project.
- Decide whether the project can be shared by direct invite, group, or workspace link.
- Use chat access by default; reserve edit access for project owners.
- Review project instructions for accidental disclosure or unsafe standing rules.
- Define deletion, archive, and offboarding behavior.
- Record the review date.
Do not use a shared project as the first place to clean up messy customer data. Redact and classify first.
Access and sharing controls
| Control | Practical rule | Why it matters |
|---|---|---|
| Project owner | One owner, one backup. | Someone must remove files, members, and stale links. |
| Member list | Invite named people or groups only when needed. | Shared project members can see project chats and files. |
| Workspace link | Avoid unless the workflow is intentionally broad. | A workspace link may let more workspace users join than intended. |
| Chat access | Default for collaborators. | Chat users can view and interact without changing files or instructions. |
| Edit access | Owners and maintainers only. | Edit users can update instructions, upload/remove files, and invite others. |
| Group access | Review group membership before sharing. | Group changes may affect who can reach the project. |
| Shared chat from project | Treat as narrower than full project sharing. | A shared chat link exposes that chat, not the full project, unless the recipient joins the project. |
| Offboarding | Remove user from project and source systems. | Workspace removal does not replace project-level review. |
Project sharing is not the same as normal chat privacy. Once content enters a shared project, project members can use it as project context.
File and instruction rules
Files and project instructions are the highest-risk parts of a shared project because they can shape future responses for everyone in the project.
| Item | Default rule |
|---|---|
| Customer files | Do not upload raw files. Use redacted excerpts or approved summaries. |
| Contracts and pricing | Upload only with account-owner approval and access-limited membership. |
| Support screenshots | Summarize manually unless screenshot upload is approved. |
| Logs and trace files | Remove tokens, IPs, customer identifiers, internal hostnames, and secrets first. |
| Project instructions | Keep instructions operational; do not include credentials, private customer commitments, or hidden policy exceptions. |
| Old files | Review monthly and remove files no longer needed. |
| Moved chats | Review before moving; old chats may carry unrelated customer or internal context. |
Recommended project instruction:
Use only the files, chats, and instructions inside this approved project.
Do not infer customer identity, account status, billing terms, legal commitments, security assurances, or deadlines.
If required information is missing, ask the project owner.
Do not include customer identifiers or internal notes in customer-facing drafts.Project approval record
Copy this into a ticket or lightweight register.
ChatGPT Project approval
Project name:
Project owner:
Backup owner:
Workspace:
Business purpose:
Members or groups:
Access levels:
Sharing mode:
Files allowed:
Existing chats allowed:
Data classes allowed:
Data classes prohibited:
Customer data involved:
Connectors involved:
Project instructions reviewed:
Retention or deletion rule:
Offboarding rule:
Review date:
Approval decision:
Evidence links:Rollout plan
| Phase | Action | Exit criteria |
|---|---|---|
| Pilot | Create one project for one low-risk workflow. | Owner, members, files, and instructions are documented. |
| Review | Inspect project instructions, files, moved chats, and member list. | No raw customer data, secrets, or stale members. |
| Share | Invite named users with chat access first. | Members understand what data can be added. |
| Expand | Add edit access or groups only after review. | Owner confirms group membership and file rules. |
| Renew | Review monthly while projects are new. | Remove stale files, chats, links, and members. |
For a small team, shared projects should be boring: narrow purpose, clear members, minimal files, explicit cleanup.
Red flags
Stop and review the project if any of these appear:
| Red flag | Why it matters |
|---|---|
| Project has “all customers”, “all support”, or “everything” in the purpose. | Scope is too broad to govern. |
| Workspace link is enabled but nobody owns member review. | Access can drift. |
| Files include screenshots, exports, contracts, logs, or spreadsheets without classification. | Sensitive data may be reused in future responses. |
| Project instructions include customer-specific promises or internal exceptions. | Future answers may repeat commitments out of context. |
| Existing chats were moved without review. | Old chats can carry unrelated data. |
| No deletion or review date exists. | Projects become stale knowledge stores. |
| Security incidents or credentials are discussed. | Route to incident response, not normal project collaboration. |
Evidence checked
- OpenAI Projects in ChatGPT
- Managing data, sharing, and privacy in ChatGPT Business
- OpenAI business data privacy, security, and compliance
- ChatGPT connector approval template
- ChatGPT Business retention questions
- How to redact customer tickets before using AI
FAQ
Are ChatGPT Projects private by default?
A personal project starts as the user’s working space, but sharing changes the boundary. In a shared project, members can see project chats, files, instructions, and the member list according to their access.
Are shared projects safer than shared chat links?
Not automatically. A shared chat link exposes a specific chat. A shared project can expose the broader project context, including chats, files, instructions, and future work inside the project.
Can project members download uploaded files?
OpenAI’s Projects documentation says members of a project can view and download files added to the project. Treat file uploads as shared project assets, not private notes.
Should support teams use one project per customer?
Usually not at first. One project per customer can create many retention and access-review problems. Start with a redacted workflow project, then create customer-specific projects only when the owner, members, files, retention rule, and customer commitments are clear.
Does ChatGPT Business train on shared project data?
OpenAI says Business workspace data is excluded from training by default. That does not remove the need to manage who can view project files, what gets uploaded, how long it stays, and whether customer commitments allow the workflow.
Recommended next step
Create a project approval record for one existing or planned ChatGPT Project. Then run the AI Tool Risk Checker and add the approved rule to the Small Team AI Security Checklist.