Governance, Risk, and Responsible Use · Lesson 3 of 5

6.3 — Project Sharing and Access Governance

Know how enterprise admins share Project access at department scale, and weigh the governance tradeoff between broad, convenient access and tightly scoped, policy-aligned access.

Sharing a Claude Project with a handful of people, one at a time, doesn't scale to an organization with hundreds or thousands of employees. Enterprise-tier organizations support a more efficient path: an admin can add an entire department to a Project in bulk, rather than sharing it with each employee individually. This is a genuine, built-in Team/Enterprise collaboration feature, reflecting that enterprise deployments need to distribute access at the scale of an org chart — departments, teams — not one person-by-person invite at a time.

Bulk-Adding a Department

When a scenario describes an admin granting a whole department access to a Project in one action — say, adding all 40 people in Customer Support to a Project built for drafting help-center articles — that's this capability, not a series of individual sharing actions strung together, and not a workaround like a shared login or a manually maintained distribution list outside the product.

The Convenience-vs-Control Tradeoff — and Organisational AI Policy

Bulk sharing is efficient, but efficiency is not the only thing that matters here, and this is where the feature intersects directly with the blueprint's "follow organisational AI policies and governance standards" bullet. The fact that bulk-adding a department is possible in one click doesn't mean it's the appropriate action for every Project. A help-center drafting Project probably is fine to share broadly across Support — low sensitivity, wide legitimate need. A Project containing draft customer contract terms, unreleased pricing strategy, or personnel data is a different case: broad department-level access to that content can conflict with an organization's own AI governance policy, even though the bulk-share button doesn't know the difference.

A well-governed organization typically defines its own tiers — for example, "marketing content Projects can be shared broadly within Marketing," but "pricing strategy Projects are restricted to Sales leadership and Legal, reviewed individually." The admin's job in that setting isn't just knowing that bulk sharing exists; it's knowing when the organization's own policy calls for scoped, deliberate access instead, and choosing the narrower path even though the broader one is one click away. Convenience and control are a real tradeoff, not a solved problem — the product gives you both options, and following your organization's policy is what decides which one is correct for a given Project.

Why This Is a Governance Question, Not Just an Admin Preference

It's tempting to treat the choice between bulk and scoped sharing as a matter of admin taste — some admins like to move fast, others like to be careful. That framing misses what's actually at stake. Every person added to a Project can see everything in it, and every person added is one more person whose account compromise, careless forwarding, or simple curiosity could expose that content beyond its intended audience. For a help-center Project, that risk is low and broad sharing is a reasonable, deliberate call. For a Project holding unreleased pricing or draft contract terms, the same broad-sharing decision multiplies the number of people who could leak, misuse, or simply stumble across commercially sensitive material by a factor of hundreds. An organization's AI governance policy exists precisely to make this calculation once, in writing, rather than leaving each admin to reinvent it under time pressure for every new Project.

Key Concept

Bulk-adding a whole department to a Project in one action, rather than sharing individually, is a real Team/Enterprise collaboration feature built for organization-scale access distribution. Whether to use it for a given Project is a governance decision, not just a convenience decision — it should follow the organization's own AI access policy, which may restrict broad sharing for sensitive Project content even though the bulk-share capability exists.

Common Exam Distractor

Don't assume that because a broad-sharing feature exists and is easy to use, using it is automatically the correct or governance-compliant choice. The exam tests whether you'll reach for the convenient, broad option by default, or check what the described organisational policy actually calls for the Project's sensitivity level. A feature being available is not the same as a feature being the right call in a given scenario.

Exam traps

Assuming project sharing at enterprise scale always requires adding each person one at a time

Bulk user addition and organization-wide distribution to an entire department in one action is a built-in Team/Enterprise collaboration feature, not a manual, per-person process.
Treating bulk department sharing as automatically the right choice because it's efficient and available

Whether broad sharing is appropriate depends on the Project's sensitivity and the organization's own AI access policy — a convenient feature isn't automatically the policy-compliant choice for every Project.
Assuming an Enterprise admin's action is compliant just because the admin has the technical permission to perform it

Having the technical ability to bulk-share a Project doesn't mean doing so follows the organization's governance standards — admins are expected to check the described policy for that Project's content, not just what the tool allows.

Practice question

An Enterprise admin is about to bulk-add the entire 200-person Sales department to a Project containing draft customer contract terms and unreleased pricing strategy. The organization's AI governance policy states that pricing strategy documents are restricted to Sales leadership and Legal only. What should the admin do?

A Proceed with the bulk add, since the bulk department-sharing feature is available and technically supports adding the whole department in one action
The feature being technically available doesn't override the organization's own governance policy, which explicitly restricts this content to a narrower group.
B Share the Project only with the specific roles or groups the policy specifies (Sales leadership and Legal), rather than bulk-adding the whole department Correct
This follows the organization's stated AI governance policy for this specific, sensitive Project content — the correct scope is defined by policy, not by which sharing action is most convenient.
C Bulk-add the whole department now, and ask employees to voluntarily avoid opening the Project if they don't need it
Relying on voluntary self-restriction after granting broad access doesn't actually restrict access — it grants exactly the broad access the policy says shouldn't exist for this content.
D Bulk-add the department, but only after also enabling the Billing role for everyone added
The Billing role concerns payment and usage/cost visibility and has no bearing on whether this Project's access should be restricted per the stated policy — this doesn't address the actual issue.

Build exercise: Weigh Convenience vs. Control in Project Sharing

Beginner · 20 minutes

You'll practice:

Locate the Project sharing settings and identify the bulk/department-level option
Draft a simple organisational policy distinguishing Project sensitivity tiers
Apply that policy to decide whether bulk sharing is appropriate for a specific Project

In the Console (or its documentation, if your organization isn't on an Enterprise tier), find the sharing settings for a Project and identify the options available — at minimum, an individual-invite option and a broader, group- or department-level option.

This grounds the abstract concept in the actual settings UI or documented options, rather than relying on the concept alone.

You should see: A sharing settings view (or documentation page) listing at least one individual-invite option and one broader, group- or org-wide sharing option.
Hints
1. ```
Look specifically for language distinguishing individual invites from group- or org-wide sharing.
```
2. ```
If you don't have Enterprise-tier access, check the Console's documentation for how this feature is described.
```
3. ```
Note any prerequisites (like plan tier) required for the bulk option.
```
Write a short, one-paragraph 'Project access policy' for a hypothetical organization, defining at least two Project sensitivity tiers (e.g. 'general/low-sensitivity content' vs. 'restricted/sensitive content') and which sharing approach — bulk department sharing vs. individual, role-based sharing — applies to each.

This exercises writing the kind of organisational AI governance policy the exam expects you to recognise and follow, not just recall as an abstract fact.

You should see: A short written policy naming at least two tiers and a matching sharing rule for each, similar in structure to the pricing-strategy example in the lesson.
Hints
1. ```
Base your tiers on realistic content types — marketing copy vs. contract terms is a good contrast, similar to the lesson's example.
```
2. ```
Make sure each tier has an explicit sharing rule attached, not just a sensitivity label.
```
3. ```
Keep it to a few sentences — the goal is a usable policy, not an exhaustive document.
```
Apply the policy you just wrote to two specific hypothetical Projects — one that clearly fits the broad-sharing tier and one that clearly fits the restricted tier — and write one sentence for each explaining whether bulk department sharing is appropriate.

This is the actual governance judgment the exam tests: not whether you know bulk sharing exists, but whether you can correctly decide when it's the appropriate action given a policy.

You should see: Two short justifications, one approving bulk sharing and one rejecting it in favor of narrower, role-based sharing, each referencing your own policy.
Hints
1. ```
Make the two Projects genuinely different in sensitivity so the contrast is clear.
```
2. ```
Reference your policy tiers by name in each justification.
```
3. ```
Consider what would go wrong if you applied the opposite sharing approach to each Project.
```

Sources

Reused/adapted from Associate lesson 5-2-project-sharing-bulk-access
Anthropic docs — Team and Enterprise Plans