How to Govern Claude Enterprise with SSO and the Compliance API

In this blog post How to Govern Claude Enterprise with SSO and the Compliance API we will explain how to control access to Claude, monitor its use and create reliable evidence for security and compliance reviews.

The risk is not usually that employees are deliberately misusing AI. It is that access grows faster than governance. Staff change roles, contractors leave, administrators gain excessive permissions and sensitive information enters conversations without anyone having a clear record.

Claude Enterprise provides two important layers for managing this problem. Single sign-on, or SSO, controls who can enter the platform using your existing company identity system. The Compliance API provides a controlled way for authorised systems to retrieve activity records, user details and, where required, Claude content for auditing and investigation.

Think of SSO as the front door and the Compliance API as the security record

SSO allows employees to sign in to Claude using the same corporate account they use for Microsoft 365 and other business applications. For many Australian organisations, that account is managed through Microsoft Entra ID, formerly known as Azure Active Directory.

This means Claude access can follow your existing login protections. These may include multi-factor authentication, where users confirm their identity with a second step, and conditional access, which can block risky logins or require a company-managed device.

The Compliance API serves a different purpose. An API is a standard method for one system to request information from another. Claude’s Compliance API allows approved security, legal or compliance systems to retrieve activity data without relying on someone manually exporting reports.

Used together, these controls answer two basic governance questions:

• Who should be allowed to use Claude?
• Can we prove what happened if something goes wrong?

Start by making your identity system the source of truth

Manually inviting users into Claude may work during a small trial. It becomes risky once dozens or hundreds of people have access.

Before enforcing SSO, verify your company email domains and decide which Claude organisations will use the same identity configuration. Then connect Claude Enterprise to your identity provider, such as Microsoft Entra ID, Okta or Google Workspace.

For most established organisations, SSO should be combined with SCIM. SCIM is a standard that automatically creates, updates and removes accounts based on information in your corporate staff directory.

If someone leaves the company and their Entra ID account is disabled, SCIM can remove their Claude access through the same offboarding process. This reduces the risk of former employees or contractors retaining access to conversations, projects and connected business information.

Just-in-time provisioning is another option. It creates an account when an approved person first signs in. It is convenient, but SCIM generally provides stronger lifecycle control because accounts can also be removed automatically without waiting for another login.

Do not give every employee the same level of access

Successful governance is not just about allowing or blocking Claude. It is about giving each group the capabilities required for its work and no more.

Claude Enterprise roles and groups can control access to features such as standard chat, Claude Code, web search and connectors. Connectors are links between Claude and services such as document repositories or collaboration platforms.

A practical access model could look like this:

• General employees can use approved chat features but cannot add new connectors.
• Developers can use Claude Code within defined engineering policies.
• Finance and legal teams have access to carefully approved data sources.
• AI administrators can manage users and settings but do not automatically receive billing or privacy permissions.
• Security staff can review activity without being able to change day-to-day business settings.

This is known as least-privilege access, meaning people receive only the permissions necessary for their role. It also supports the Essential Eight, the Australian government’s cybersecurity framework, particularly its guidance on multi-factor authentication and restricting administrative privileges.

SSO and role controls do not achieve Essential Eight compliance by themselves. They do, however, provide useful evidence that access to an important business platform is centrally managed and reviewed.

Use the Compliance API for evidence rather than surveillance

The Compliance API can provide access to Claude activity, users, groups, roles, effective organisation settings and, for Claude Enterprise environments, chats, files and projects. It can also support approved deletion workflows.

This does not mean every conversation should be copied into a security monitoring system. Collecting everything without a defined purpose can increase storage costs, employee concerns and privacy risk.

A better design sends routine activity records into your central security monitoring platform, often called a SIEM. Conversation or file content should only be retrieved when there is a documented legal, security, privacy or regulatory reason.

A basic activity request looks like this:

curl --fail-with-body -sS \
 "https://api.anthropic.com/v1/compliance/activities?limit=100" \
 --header "x-api-key: $ANTHROPIC_COMPLIANCE_ACCESS_KEY"

The access key in this example acts like a highly privileged password. Depending on its permissions, it may be able to read sensitive conversations and files or permanently delete content.

Store it in a secrets manager, which is a protected vault for system credentials. Never place it directly in scripts, source code, documentation or security tool configuration files.

Decide what events require action

Logs have little business value if nobody knows what to do with them. Before connecting the Compliance API to another platform, define the activities that should trigger a review.

Useful examples include:

• An unexpected administrator or owner role being assigned.
• Changes to organisation-wide security or access settings.
• A user accessing Claude after their employment status changed.
• Unusual file activity involving a sensitive business area.
• Repeated attempts to access restricted features or connectors.
• Deletion activity that falls outside an approved process.

Each alert should have an owner, a severity level and a response procedure. Otherwise, the business simply creates another dashboard that nobody checks.

This monitoring can also support obligations under the Australian Privacy Act. Australian Privacy Principle 11 requires covered organisations to take reasonable technical and organisational steps to protect personal information.

If an incident may involve serious harm, the Notifiable Data Breaches scheme may also require assessment and notification. Reliable identity and activity records can make that investigation faster and more defensible.

A practical scenario for a growing Australian business

Consider a 180-person professional services firm using Claude across consulting, finance, marketing and software development. Its original pilot relied on manual invitations, and several contractors still appeared in the user list months after their projects ended.

The firm moved access into Microsoft Entra ID groups and used SCIM to automate account creation and removal. General users, developers and administrators were assigned different capabilities, while connector access was limited to approved teams.

Claude activity records were then sent to the firm’s existing security monitoring platform. Full conversation content was excluded from routine collection and could only be retrieved through an approved investigation process.

The outcome was not just better security. Offboarding became part of the normal Microsoft 365 process, quarterly access reviews took hours rather than days and the leadership team could demonstrate how Claude was being controlled.

A sensible implementation plan

1. Inventory current access. Identify users, administrators, contractors, connectors and Claude organisations.
2. Verify your domains and configure SSO. Test access carefully before making it mandatory.
3. Enable automated provisioning. Use SCIM where possible so onboarding and offboarding follow your staff directory.
4. Design roles around business need. Separate general use, development, administration, finance and security responsibilities.
5. Protect Compliance API credentials. Grant only the required permissions and store every key in a secure vault.
6. Define logging and retention. Decide what information is collected, where it is stored and when it is deleted.
7. Test the response process. Confirm your team can investigate a suspicious login, permission change or sensitive file event.

These controls should sit alongside the broader adoption framework covered in our guide to safely adopting Claude Enterprise. If Claude connects to internal systems, also review how to connect Claude to business data safely and how to design secure tool access for Claude agents.

Governance should make AI easier to use safely

Good Claude governance is not about watching every employee or blocking useful AI features. It is about making access predictable, removing it quickly and keeping enough evidence to respond confidently when questions arise.

CloudProInc brings more than 20 years of enterprise IT experience to this work. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations connect Claude governance with Microsoft Entra ID, Microsoft 365, Defender, Wiz and their broader security controls.

If you are not sure whether your current Claude setup provides enough control or audit evidence, we are happy to take a practical look at it with you — no strings attached.