Document Security and Departmental Isolation
The core question
When you upload HR salary data to a Project for the HR team, can someone in Engineering see it? When your Legal team uploads a confidential M&A analysis, can the Marketing team access it? When Finance uploads a board presentation draft, can a junior employee stumble across it?
The answer to all three is no — provided your Projects are correctly structured. This lesson explains the isolation model and how to implement it.
How Projects provide isolation
The fundamental isolation boundary in Claude Enterprise is the Project. A Project's knowledge files, conversations, and settings are accessible only to:
- Members explicitly added to that Project
- Organisation Admins (who can see all Projects for governance purposes)
If a user is not a member of a Project, they cannot:
- See that the Project exists (in most configurations)
- Access any conversations within it
- Access any knowledge files uploaded to it
- Read the system prompt (custom instructions)
This means that if your HR Project has 8 members and your Engineering Project has 18 members, the 18 engineers cannot see or search the HR Project's content, and vice versa.
The isolation model visualised
Organisation
├── HR Project (members: HR team, 8 people)
│ ├── System prompt: HR policies and tone guidance
│ ├── Knowledge: salary-bands.pdf, benefits-guide.pdf, disciplinary-policy.pdf
│ └── Conversations: visible only to HR team members
│
├── Engineering Project (members: Engineering team, 18 people)
│ ├── System prompt: coding standards and architecture guidance
│ ├── Knowledge: api-docs.pdf, architecture-decisions.md, coding-standards.pdf
│ └── Conversations: visible only to Engineering team members
│
└── Leadership Project (members: exec team, 6 people)
├── System prompt: strategic analysis, board-level communication
├── Knowledge: board-pack-template.docx, q4-targets.pdf, m-and-a-analysis.pdf
└── Conversations: visible only to exec team membersNo cross-access. Each department operates in its own space.
What Admins can see
Organisation Admins have visibility across all Projects. This is intentional: admins are responsible for governance, and they need to be able to audit what Projects exist, what system prompts are configured, and whether any Projects contain inappropriate content or member lists.
What admins can see:
- All Projects and their names
- Project member lists
- System prompts (custom instructions)
- Knowledge files (names and content)
What admins cannot do:
- Read individual user conversations (conversation content is private to the user and Project members)
Implication for your governance structure: only trust people with Admin access who genuinely need it. A manager who is curious about what the Finance team is using Claude for should not be made an Admin to satisfy that curiosity — they should be added as a Project member if there is a business reason.
Practical setup for departmental isolation
Step 1: one Project per sensitive department or use case
Do not create one giant organisation-wide Project for everyone. Create Projects aligned to your natural data boundaries:
| Department / Use case | Suggested Project | Knowledge files |
|---|---|---|
| HR | HR Operations | Salary bands, policies, job descriptions |
| Legal | Legal Review | Contract templates, jurisdiction guides |
| Finance | Finance Analysis | Chart of accounts, board pack templates |
| Engineering | Engineering AI | Architecture docs, coding standards |
| Marketing | Brand & Content | Brand guidelines, messaging frameworks |
| Leadership | Executive Intel | Board materials, strategic plans |
Step 2: assign members at the Project level, not the organisation level
When you invite someone to a Project, they only gain access to that Project — they do not gain broader access to the organisation. Use this:
- HR staff → HR Project only
- Engineers → Engineering Project only
- Senior leaders → relevant Projects for their function + Leadership Project
- Admins → all Projects (automatically, by role)
Step 3: review membership regularly
Leavers who are deactivated at the organisation level immediately lose access to all Projects. But internal moves (someone transfers from HR to Engineering) require a manual membership update: remove them from the HR Project, add them to the Engineering Project.
Use the Members section of each Project to audit membership at least quarterly.
Step 4: do not upload data above its clearance level
A Project's isolation is only as strong as what you put in it. If you upload a document to the Marketing Project that contains confidential pricing strategy that Marketing should not have, the isolation model cannot protect you — you put the document there intentionally.
Match knowledge file contents to the intended audience of the Project.
What "safe" means — and what it does not mean
Safe from cross-department access: ✓ Yes. As described above, Project isolation prevents this.
Safe from Anthropic staff access: ✓ Yes, for Enterprise plans. Anthropic's Enterprise contract includes a Data Processing Addendum (DPA) that governs how data is handled. Enterprise conversations and knowledge files are not accessible to Anthropic employees in normal operation.
Safe from model training: ✓ Yes. Enterprise contracts opt out of using organisation data for model training by default. This is confirmed in the Privacy & Data section of the Admin Console. Verify it is active on your organisation (M63-L1 covers this in detail).
Safe from deletion or loss: ✗ Not guaranteed. Projects and knowledge files can be deleted by admins or Project creators. If you have important documents in a Project, maintain a separate source-of-truth copy outside Claude (SharePoint, Google Drive, etc.). Claude is not a document management system — it is a workspace that references documents.
Safe from users copying content out: ✗ Not technically enforced. A user can copy Claude's output — including output that draws on knowledge files — into an email or external document. If this is a concern, address it via your acceptable-use policy and training rather than relying on technical controls.
Sensitive data: what to avoid uploading
Some categories of data should not be uploaded to Claude Projects regardless of isolation controls, because they represent unacceptable risk if controls ever fail or are misconfigured:
| Data category | Recommendation |
|---|---|
| Personal employee data (performance records, medical, salary of named individuals) | Do not upload. Use anonymised or aggregated versions. |
| Customer PII (names, addresses, financial details) | Do not upload. Claude is not a PII processor — use synthetic or redacted data. |
| Passwords, API keys, credentials | Never upload. |
| Unpublished financial results | Consult your legal team before uploading. Insider trading rules may apply. |
| Patient data (HIPAA) | Do not upload unless your Enterprise contract explicitly covers healthcare data. |
| Data covered by specific regulatory regimes (GDPR special categories) | Consult your DPO first. |
For legitimate HR use cases involving individual employee data, use anonymised or role-based examples rather than real records.
Scenario: a misconfiguration and how to fix it
A fast-growing technology company creates a single "All Staff" Project when they first deploy Claude Enterprise. They upload the company handbook, brand guidelines, and the latest all-hands presentation — all appropriate for all staff.
Three months later, the Finance Director wants to use Claude for board pack drafting. Not thinking about isolation, she uploads the draft Q3 board pack (including confidential revenue figures and a proposed acquisition) into the existing All Staff Project.
An admin running a routine governance review notices this the following week. The document has been in the All Staff Project — accessible to all 80 employees — for seven days.
Fix:
- Delete the confidential document from the All Staff Project immediately.
- Create a new Leadership Project with membership restricted to the exec team.
- Upload the document to the Leadership Project.
- Investigate whether any non-exec employees accessed or cited the document.
- Update the acceptable-use policy to require admin approval before uploading confidential materials.
- Brief the Finance Director on Project structure and data sensitivity.
Prevention: do the Project structure design before deployment. Agree with each department head what goes in their Project and who the members are. A 30-minute governance workshop at the start of the rollout prevents this class of error.
Key takeaway
Projects are your primary isolation tool. One Project per department or sensitive use case. Explicit membership. Regular membership audits. Never upload data above the clearance level of the Project's members. Isolation is technical but the boundaries are set by humans — get the structure right before you go live.
📖 Official Documentation See this in practice in Anthropic's live support docs: