Claude Code Enterprise — SSO, Audit Trails, and Policy Controls

Why enterprise controls matter for AI tooling

AI-assisted development tools introduce a category of action that traditional access control systems were not designed for: an agent that reads files, executes commands, and makes changes based on natural language instructions. Most enterprise security frameworks have clear policies for who can read which files and who can run which commands. Fewer have clear policies for an AI that can do both, across a broad surface, at the direction of any engineer with a terminal.

The enterprise tier of Claude Code addresses this gap with controls that sit between the engineer's instruction and the action the CLI takes. An administrator defines the permitted envelope — which directories can be read, which shell commands can be run, which model tiers can be selected — and the CLI enforces it regardless of what the engineer asks. The audit log records everything that happens within that envelope, so there is a complete trail of AI-assisted actions available for security reviews, incident investigations, and compliance audits.

SSO integration

Claude Code enterprise integrates with any OIDC-compatible identity provider. Engineers authenticate through the organisation's existing SSO stack; the CLI exchanges the OIDC token for a session credential rather than asking for a separate API key. This keeps credential issuance and revocation within the access control system the IT and security teams already manage.

The practical implication is that when an engineer leaves the organisation and their account is deprovisioned, their Claude Code access is revoked at the same time — no separate off-boarding step is required, and no orphaned API keys remain active after the account closes. For teams that have been through a security audit focused on credential sprawl, this property tends to be one of the most immediately valued aspects of the enterprise tier.

SAML 2.0 is supported alongside OIDC for organisations that have not yet migrated their identity provider to the newer protocol. Group membership from the identity provider can be mapped to Claude Code permission tiers, so engineers in the senior engineer group can be granted higher permission thresholds than engineers in the contractor group, without any per-user configuration.

Audit trails

The audit log captures a structured record of every significant action in a Claude Code session: session starts and ends, file reads and writes, shell commands executed, skill invocations, MCP tool calls, and model tier selections. Each entry includes a timestamp, the user identity from the SSO session, the repository path, and the specific action taken.

Logs are forwarded to your existing SIEM infrastructure via webhook or log-shipping integration. Splunk and Datadog are the most common targets, though any platform that accepts structured JSON over HTTP works. The log schema is documented and stable across minor releases, so existing dashboards and alert rules do not break when the CLI version updates.

For regulated industries, the audit log also captures the prompt that preceded each action. This is the record a compliance officer needs to verify that an AI-assisted change was within scope of the engineer's authorisation — not just that a file was written, but what instruction led to that write. Prompt logging can be scoped to specific repository paths or action types if capturing all prompts raises data handling concerns.

Permission policy and prompt caching controls

The permission policy configuration supports several layers of restriction. Shell command allow-lists specify which command patterns are permitted; commands outside the list are blocked before execution, not just flagged after. File path restrictions limit which directories the CLI can read from or write to. Skill source restrictions block loading skills from outside the approved shared registry. Model tier caps prevent engineers from selecting tiers above the approved ceiling for a given context.

Human approval gates are an additional control for regulated industries where a second person must review AI-assisted changes before they land on disk. With the gate enabled, every proposed edit is held until a designated reviewer approves it — the engineer who initiated the session cannot self-approve. This satisfies the four-eyes requirement common in financial services and healthcare engineering workflows.

Prompt caching policy controls whether session context is cached across sessions for cost reduction purposes. Teams where data residency requirements prohibit cross-session context storage can disable caching entirely or set a short time-to-live that aligns with their retention schedule. The NIST AI Risk Management Framework provides a useful governance structure for documenting these controls and mapping them to organisational risk tolerance — the GOVERN and MEASURE functions in particular are a natural fit for the permission and audit capabilities described here.

Enterprise control reference

The table below maps each enterprise control to the party responsible for configuring it and the log target where the relevant events appear.

Control	Who enforces	Log target
SSO authentication	IT / identity team via OIDC or SAML configuration	Identity provider access log + Claude Code session log
Shell command allow-list	Security team via org policy config	Claude Code audit log — blocked-command events
File path restrictions	Security team via org policy config	Claude Code audit log — file access events
Human approval gate	Engineering manager via repo-level setting	Claude Code audit log — approval and rejection events
Prompt caching policy	Platform team via org settings	Not separately logged; reflected in session cost metrics
Model tier cap	Engineering manager or security team	Claude Code audit log — tier selection events

Fitting enterprise controls into existing governance

Most organisations already have an AI governance process underway, whether that is a formal programme aligned to the NIST AI RMF or an informal review checklist that engineering and legal work through before deploying a new AI tool. Claude Code enterprise controls are designed to produce the evidence those processes ask for: a defined permission boundary, a complete action log, identity-linked accountability, and a human review step for high-stakes changes.

The controls do not replace human judgment about whether AI-assisted development is appropriate for a given context — they bound and record the activity so that judgment can be exercised on accurate information. Teams that have gone through a security review of Claude Code enterprise typically find that the main discussion is not about the technical controls, which are straightforward, but about the policy question of what the approved envelope should be for different categories of engineer and different repository types.