Chapter 4. Sharing, permissions and data boundaries

Learning objectives

• Build a permission matrix across people, materials and actions, and explain what each product's sharing roles actually allow.
• Recognize different sharing units—conversation links, projects, notebooks, task links and exported files—and design sharing scope.
• Control sharing and connections organization-wide with workspace admin controls, and audit existing state after changes.
• Distinguish retention, deletion, training use and memory as separate settings, and explain differences between plans.
• Protect data boundaries by minimizing the amount of sensitive material sent and separating spaces.

Introduction

A consulting team created a project to share with a client. The team lead believed it was safe because the client contact had only the lowest permission, “view.” Alongside report drafts intended for the client, the project contained an internal staffing rate sheet. A month later, the client contact proposed renegotiating contract terms based on that sheet. View permission allowed access to project files too. Another project in the same team saw the opposite problem: reassured that a business workspace did not use data for training, a colleague casually pasted client interview records into a personal account and requested a summary. Both incidents arose from misunderstanding boundaries, rather than a tool defect.

Permission names look like everyday words, but products define the actions they permit. This chapter starts by reading those definitions precisely. It then examines what each sharing unit carries, what administrators can enforce organization-wide, and how long data is retained and whether it is used for training. Finally, it covers designing to send less sensitive material in the first place and cleaning up access when people change roles. Chapter 3 addressed what AI can reach; this chapter addresses what people can see.

Key concepts

Reading permissions across three axes

“Team members can use this project” is too vague a permission description. Permissions combine three axes.

Every permission-matrix row should be a sentence containing all three, such as “The freelance designer may view and download files in the draft-design folder, but may not edit instructions or invite others.” Also record why the permission is necessary for work. Permissions without justification are candidates for revocation.

Sharing permissions by role

Judging by a sharing role's name alone easily leads to mistakes. Official help pages define them as follows as of the verification date.

Across these products, even the lowest role can see the material. OpenAI states that all project members can view and download added files and see the member list, including names and email addresses. Editors can invite people but cannot remove existing members. Lowering a role alone does not prevent exposure, and granting edit access can expand sharing scope.

Distinguishing sharing units

What travels with a share depends on what is shared.

Before clicking Share, always verify what is included with that sharing unit. A common mistake is sharing an entire project when only one conversation needs to be shown.

Group sharing and permission calculation

Sharing through groups or links is easier to manage than individual invitations, but permission calculation becomes more complex. ChatGPT's help pages explain that individual permissions can be changed after inviting a group, but the more permissive of the group and individual permissions applies. If the group has Edit access, lowering an individual to Chat still leaves that person able to edit. The reverse works: invite the group with Chat and raise selected individuals to Edit.

Members joining through a workspace link receive Chat permission by default; links cannot give the entire workspace Edit permission. In personal accounts, choosing “Anyone with a link” allows any signed-in user with the link to join. The principle is simple: use the lowest role for broad sharing, and grant higher permissions separately only to individuals who need them.

Sharing pitfalls

1. Hiding on screen is not blocking access. Gemini Notebook's chat-only view link hides sources and outputs on screen, but official help documentation warns that it does not fully revoke viewers' underlying access; hidden material may remain reachable through other routes.
2. Turning sharing off may leave existing shares. Anthropic documentation states that disabling project sharing blocks new user and group shares but preserves existing individual shares. Organization-public projects become private, however, so people whose access depended solely on public visibility lose access.
3. Deleting a link does not delete existing copies. Deleting a ChatGPT shared task link prevents further access through that link, but copies recipients already made remain.
4. Connected content may have sharing restrictions. Claude Team and Enterprise guidance directs connector use to private rather than shared projects. When sharing a conversation with specific people, raw connector or MCP tool data is omitted; only Claude's final answer is shared. That answer can still contain connected information, so read it before sharing and do not bypass restrictions by copying and pasting raw data.
5. Instructions are not sharing controls. “Do not disclose this externally” guides model answers but cannot change access permissions.

Designing sharing scope

Design sharing scope by separating spaces, rather than adjusting permission names.

1. Divide recipients into groups, such as the internal team, outside partners and all employees.
2. List materials each group must and must not see.
3. For groups with forbidden material, create a separate space without that material.
4. Default to the lowest role in each space, granting edit access only to those responsible for maintenance.
5. Set a sharing end date and schedule member and link cleanup for that date.
6. Test with that group's role before sharing (see Going deeper).

Workspace admin controls

Organization-level controls are stronger than individual caution. Caution varies and people make mistakes; admin controls enforce the same rules across an organization. The primary controls as of the verification date are summarized below.

Admin controls have limits. Administrators can enable, disable and scope features, but cannot determine whether each item uploaded by a member is appropriate. Admin controls and members' judgment about materials must work together.

Retention, deletion, training use and memory

Data handling has four separate switches. Changing one does not change the others.

OpenAI explains that turning off “Improve the model for everyone” prevents subsequent conversations from being used for training, but does not delete or hide saved conversations. Temporary chats do not appear in history, create memories or train models, but may be retained for up to 30 days for safety. Anthropic states that deleting a personal-plan conversation removes it from history immediately and from backend storage within 30 days. Complete deletion is not instantaneous.

Data handling by plan

Business and personal plans have different defaults.

The same feedback button can have different consequences by plan. Feedback may be an exception even on business plans, so organizations must decide whether to permit it and inform members. Also check that for Claude Enterprise, project retention takes precedence for conversations inside projects; projects are retained indefinitely unless separately configured.

Separating sensitive materials: send less

Uploading all sensitive material and masking results afterward is too late. The principle is to send less from the start.

1. Processing environment: handle sensitive material only in a business workspace the company has contracted.
2. Extract only what is needed: if analyzing inquiries requires their content, remove names and contact details.
3. Pseudonymization: Korea's Personal Information Protection Act (PIPA) defines this as processing personal information by deleting some of it or replacing some or all of it so that a particular individual cannot be identified without additional information (Article 2, subparagraph 1-2). For example, replace a customer's name with “Customer A” and keep the mapping separately outside the AI space.
4. Use aggregates: use counts by month or type instead of individual records.
5. Separate spaces: create a separate space containing only people who need access.
6. Regular audits: review members, visibility and connected apps quarterly; revoke access when work ends.

Remember that context may reveal masked information. Reasons for resignations in a small department may identify people even without names. Pseudonymization alone is insufficient for such material; first consider keeping it out of AI entirely.

Derived information and personal versus organizational spaces

Information can leak without sharing the original file. AI-generated summaries, comparison tables and quotations are derived information containing the source's content. Pasting an internal-space summary into an external space can have the same effect as sharing the original. Combining sources can also reveal information not apparent in any single source.

Personal and organizational spaces have different administrators and policies even when used by the same person. Uploading company material to a personal account bypasses company retention, training and audit settings. If this happens, delete it immediately and notify security staff according to company policy.

Access cleanup for onboarding, transfers and offboarding

When people change roles, AI assets tied to them can create operational gaps. Check four asset types.

Scheduled tasks need particular attention. ChatGPT tasks run under their creator's account, connections and permissions; copies shared through links run separately under recipients' accounts. When an owner leaves, tasks may quietly stop or continue under the departed person's permissions. Build shared assistants and recurring tasks around team responsibility rather than an individual, and appoint joint administrators. With identity-provider account management, offboarding can be linked to connection revocation. For example, deactivating an identity-provider account also revokes Claude managed-auth connector access.

Going deeper

Settings usually affect future behavior

An admin change may seem likely to revoke existing shares or connections automatically, but many settings only change future behavior.

Always follow setting changes with an audit of existing state. Some settings instead act immediately and irreversibly. Shortening Claude Enterprise retention schedules data outside the new period for permanent deletion as soon as the change is saved; it cannot be restored. Check whether each setting is future-only or immediate and retroactive, and assess the affected scope before retroactive changes.

Testing whether permissions actually apply

Admin settings can differ from users' actual access because group and individual permissions overlap, source permissions differ from expectations, or old links remain. Test important sharing arrangements.

1. Choose test accounts or cooperating colleagues for each role.
2. Confirm access to permitted materials under that role.
3. Try opening restricted materials, editing instructions, inviting others and downloading files.
4. Ask the AI about restricted material. If the space does not contain it, the AI should not be able to answer.
5. Record results and setting evidence in a table, with the next audit date.

Work automation from a personal-information perspective

In August 2025, Korea's Personal Information Protection Commission published its guide to processing personal information in generative AI development and use. Covering commercial services such as ChatGPT, it divides the generative AI lifecycle into four stages—purpose setting, strategy development, training and development, and deployment and management—and presents safeguards for each. It emphasizes governance led by the Chief Privacy Officer (CPO). The Commission says the guide will be updated, so consult the latest edition.

For no-code automation owners, this perspective becomes three questions: Does the automation process personal information? If so, is it limited to what the purpose requires? Does the company's privacy officer know the processing environment and retention and training settings? This book does not give legal advice. Review automation involving personal information with the company's privacy officer during design.

At work

Resonance Audio: a space shared with an outside production company

Sound equipment rental company Resonance Audio is preparing a two-month regional tour with Moon Halo Productions. Project manager Kang Yerin plans a shared project in the company's business workspace for two production-company contacts. Materials include venue equipment layouts, load-in schedules, and internal equipment costs and rental quotation calculations.

Kang's first plan put everything in one project with the lowest role for the outside contacts. The help pages showed that even this role could view and download files. The second plan kept costs in the project but added “Do not discuss costs or margins” to instructions. Kang rejected this too: instructions would not block access, and the files remained open.

Kang split the spaces. “Tour collaboration,” shared with the production company, contained only layouts and schedules. “Tour internal,” limited to company employees, held costs and quotation calculations. Outside contacts received Chat permission, and only Resonance Audio's technical director received Edit permission.

The real problem emerged later. In week three, the technical director asked AI in the internal project to summarize equipment configurations by venue, then planned to paste it into the collaboration project. The summary's bottom row included expected profit margins by venue—derived information AI had produced from internal sources. Kang fortunately spotted it before pasting.

Kang added a rule: create externally shared outputs only inside the externally shared project. A person must check outputs line by line before moving them from internal projects to external recipients. Before sharing, a colleague also entered the collaboration project with a Chat-role account and asked, “What are the equipment costs?” and “What are the profit margins?” Since the material was absent, AI could not answer. Kang scheduled removal of the outside contacts on the tour's final day.

Connected Living: handing over automation during a transfer

Assistant Manager Baek Jian in the operations team at household-goods company Connected Living will transfer to product planning next month. Baek has built the team's AI automation alone for a year. Operations lead Jung Woojin requested a handover during the two weeks before transfer.

Baek and Jung first inventoried assets: three shared projects owned by Baek; a returns assistant used by 30 customer support agents; email and drive connectors authenticated with Baek's individual account; and two scheduled tasks running every morning under that account. One task summarized the previous day's return-request emails and posted to the team channel.

Jung initially suggested keeping Baek's account and simply taking over its password. Baek objected: another person using the account would blur accountability in the activity records, and Baek would keep using it in the new department. They decided to transfer assets rather than the account.

1. They moved the returns assistant's original instructions and test question set to the team drive and checked whether the product supported ownership transfer. Unsupported assets were recreated under the operations successor's account and compared with the same test set.
2. They first invited the successor as a shared-project editor, then resolved ownership. One unused project was deleted after necessary materials were moved to the team drive.
3. They recreated scheduled tasks under the successor's account, and the successor reconnected email and drive using their own account. After three consecutive days of correct results, they deleted the tasks under Baek's account.
4. They checked that Baek was removed from operations spaces and that Baek's personal connectors no longer reached operations materials.

On the final handover day, Jung changed team rules: shared assistants and recurring tasks must support management by at least two people, and the asset inventory must be updated quarterly.

Common mistakes

1. “Chat or View permission prevents seeing materials.” Even the lowest role usually permits viewing. Remove restricted materials from the space.
2. “Hidden on screen means safe.” Hiding and revoking access are different.
3. “Disabling sharing removes existing shares.” New sharing may stop while individual shares remain. Conversely, access based on public visibility may close immediately. Audit after changes.
4. “Lowering an individual's permission after inviting a group lowers their effective access.” The higher group or individual permission may apply.
5. “Turning training use off deletes conversations.” Training use and retention or deletion are separate settings.
6. “Business plans never use anything for training.” Explicitly shared data, such as feedback, may be an exception.
7. “No original file was shared, so nothing leaked.” Derived information such as summaries and comparisons can leak too.
8. “Taking over the owner's account completes handover.” Transfer assets—spaces, assistants, connections and tasks—and verify results.

Summary at a glance

Check the official docs

• OpenAI — Projects in ChatGPT: Read sharing roles, group permission calculation, file access, conversation links versus project sharing, admin controls and retention.
• Anthropic — What are projects?: Check Can view and Can edit permissions and the effects of disabling sharing.
• Google — Create a notebook in Gemini Notebook: Read viewers and editors, chat-only view limitations, exports and permissions, and copy settings.
• OpenAI — Data controls in ChatGPT: Check what model-improvement settings change and leave unchanged, and temporary chats. Also consult Enterprise privacy for business plans (Appendix D).
• Anthropic — Is my data used for model training?: Read business-product training non-use and feedback exceptions. See Appendix D for Enterprise custom retention guidance.
• Google — Generative AI in Google Workspace Privacy Hub: Check Gemini data handling and retention in Workspace.
• National Law Information Center — PIPA, Article 2: Check the definition of pseudonymization.
• Personal Information Protection Commission — Press release on the generative AI personal-information processing guide: Check the guide's structure and whether it is the latest edition.

Self-check

4-1. Explain why “Team members can use this space” is vague using the three axes of people, materials and actions. Rewrite it as one sentence containing all three.

4-2. Tabulate whether ChatGPT shared-project Owners, Editors and Chat members can invite others, remove existing members and download uploaded files.

4-3. Choose one of five sharing units—conversation link, project, notebook, scheduled task link or exported file—and state what travels with it and what does not.

4-4. Write one line on what retention, deletion, training use and memory each control. Explain why “I turned training use off, so past conversations disappeared” is wrong.

4-5. Explain PIPA's definition of pseudonymization in your own words. Suggest two measures to “send less” before analyzing support records with AI.

4-6. Use the term “derived information” to explain how information can leak without sharing the original file. Propose one operating rule to prevent this.

4-7. Explain why existing state must be audited after admin changes. Give one future-only setting example and one setting with immediate irreversible effects.

Hands-on tasks