Roles, Permissions and Governance
The governance problem with AI tools
Most SaaS tools have clearly scoped permissions: a CRM user can only see their own accounts; a finance tool user can only view their budget code. Claude is different. It is a general-purpose intelligence tool — a Member can use it to draft an email, analyse a spreadsheet, write code, or summarise a document. This breadth is what makes it valuable, but it also means governance cannot rely on feature-level access controls alone.
Instead, governance in Claude Enterprise works through a combination of:
- Role-based access — who can administer the organisation versus who can just use it
- Projects — scoped configurations that shape what Claude does in a particular context
- Policy — written acceptable-use rules that define what employees may and may not do
- Monitoring — usage analytics and audit logs that allow detection of policy violations
This lesson covers role-based access. Projects are covered in M64; policy and monitoring are in M65 and M66.
What admins can do that members cannot
The Member role gives access to:
- The Claude chat interface (all models available to the organisation)
- Creating, sharing and managing personal Projects
- Inviting others to Projects they own
- Managing their own profile, preferences and personal API keys (if the admin has allowed this)
- Viewing and searching their own conversation history
The Admin role adds:
- Full Admin Console access (all six sections)
- Viewing all organisational Projects (including those created by any member)
- Creating organisation-wide Projects visible to all members
- Changing organisation-wide settings (SSO, 2FA, retention, training opt-out)
- Inviting, deactivating and changing the roles of any member
- Viewing organisation-level usage analytics
- Accessing billing and seat management
- Submitting data deletion requests on behalf of the organisation
Deciding who should be an Admin
The Admin role should follow the principle of least privilege: give it only to people who need it to do their job.
Appropriate admins:
- IT administrator or IT manager responsible for SaaS governance
- Security or compliance officer who needs to verify settings and pull audit logs
- Designated "AI admin" role if your organisation has one
Not appropriate admins:
- Senior managers who want visibility into what their teams are doing (use usage analytics reports instead)
- Power users who want more capability than a Member provides (Projects give Members significant customisation capability without admin access)
- Anyone outside IT/Security without a specific need
Recommended minimum: 2 admins (resilience). Recommended maximum: 5 admins in most organisations.
Project-level governance
While the Admin Console has only two roles, Projects introduce a layer of scoped governance. When a member creates a Project, they become its owner. As owner they can:
- Edit the Project's system prompt and settings
- Add and remove Project members
- Archive or delete the Project
- See all conversations that take place within the Project (note: this is Project-specific, not org-wide)
Admins can view all Projects from the Admin Console and can edit or archive any Project. This is important for governance: if a member creates a Project with a problematic system prompt, an admin can correct or remove it.
Best practice: for high-stakes Projects (e.g., one used by your legal team to analyse contracts), make an admin the Project owner rather than the creating member, so the Project does not become orphaned if that member leaves.
Enforcing governance through Projects
Use Projects as governance tools, not just convenience features. Three approaches:
Locked system prompts for regulated workflows: if you have a workflow where employees must not enter certain data types (e.g., patient names in a healthcare setting), create a Project with a system prompt that explicitly instructs Claude to flag such inputs and refuse to process them. Users who work in that context get a guardrail built into the tool.
Departmental sandboxing: create separate Projects for departments with different risk profiles. Legal's Project can have a conservative system prompt; Marketing's can be more creative. This avoids a one-size-fits-all configuration that either over-restricts or under-restricts.
Version control for system prompts: because admins can edit Projects, treat the system prompt as a versioned document. When you make a significant change, note it in your internal IT change log with the date and reason. This creates an audit trail.
The governance review cadence
Governance is not a one-time event. Schedule these reviews:
Monthly:
- Check for Projects created by members that you are not aware of. Review their system prompts. Archive any that appear abandoned or problematic.
- Review pending invitations older than 14 days. Resend or remove them.
Quarterly:
- Run the user audit (M62-L1 scenario).
- Review admin accounts: are all current admins still in their roles? Have any left the organisation?
- Review the acceptable-use policy: has anything changed (new regulations, new use cases) that requires an update?
- Pull usage analytics and report to leadership.
Annually:
- Renew or renegotiate the Enterprise contract and review seat count.
- Review the DPA for changes in data handling practices.
- Assess whether SSO and SCIM configuration reflects any changes in your IdP (e.g., a migration from Okta to Azure AD).
Scenario: the Project governance gap
A retail company deploys Claude Enterprise without a formal Project governance process. Eighteen months in, the HR admin runs a review and finds 47 Projects in the organisation. Several have no members, four have system prompts that expose personal employee data (one was set up by a manager to "help with performance reviews" and included example employee records in the system prompt), and two are owned by users who have left the organisation and were deactivated.
The HR admin archives the empty Projects, removes the employee data from the problematic system prompts (replacing with generic instructions), and reassigns the orphaned Projects to active admins. She then creates a policy requiring admin approval for any Project intended for use with employee personal data.
This remediation took half a day. A governance review cadence would have caught these issues before they became a risk.
Key takeaway
Roles give you a control plane; governance is what you build on top of it. Two roles (Admin and Member), a clear policy on who gets which role, a Project review cadence, and a quarterly user audit give you a defensible governance posture for almost any organisation size.
📖 Official Documentation See this in practice in Anthropic’s live support docs: