AI Coding Tools Enterprise Controls: SSO, Audit Logs and Admin Policy Side by Side

Before an organisation rolls out an AI coding tool, it needs to know how that tool connects to its identity provider, what it records for auditors and which settings an administrator can lock. This page sets out the documented enterprise controls of five widely used AI coding tools in identical fields: single sign-on, user provisioning, audit records, admin policy, device enforcement, tool and context restriction, data retention controls and usage reporting. It is written for security architects, identity teams, procurement and engineering leaders who have to approve or configure these tools. Every fact comes from the vendor's own documentation or pricing page as checked on 15 November 2026. Tools are listed alphabetically; order is never a ranking, and the page makes no recommendation. Last checked: 2026-11-15.

This is an independent reference page from NHI Mgmt Group based on public provider documentation; it is not sponsored or endorsed by any provider.

Key takeaways

• Controls sit on organisation plans. For all five tools, SSO, provisioning and audit records are documented for business or enterprise tiers, not individual plans, so the plan decision comes before the configuration work.
• Three layers of control. Each vendor documents an identity layer (SSO, SCIM, roles), a policy layer (models, features, MCP servers) and a device or local configuration layer, and an organisation needs all three.
• Audit records differ in scope. Vendors describe what their audit logs or compliance exports contain in different terms; check whether a record covers admin actions, agent actions, conversation content or local activity before mapping it to a requirement.
• Analytics are not audit logs. Several vendors state this directly, so usage dashboards should not be offered to auditors as evidence of who did what.
• Automation credentials need governance. Service accounts, access tokens and analytics keys used by these tools are non-human identities with their own owner, scope and rotation needs.

How the comparison was built

The five tools are Claude Code (Anthropic), Cursor, Devin Desktop (Cognition, formerly Windsurf), GitHub Copilot (GitHub) and OpenAI Codex (OpenAI). Each has a live product page on nhimg.org and public administrator documentation. For each tool the same fields were filled from the vendor's admin documentation, plan pages and governance pages, fetched on 15 November 2026. Where a vendor's pages checked do not state a capability, the cell says "Not stated by" the vendor, which means only that the pages read did not describe it.

The fields follow what an identity or audit team usually asks in a tool approval: can we enforce SSO, can we deprovision automatically, what is logged and for how long, can we restrict models and integrations centrally, can we enforce settings on the device, and what happens to our code and prompts. Prices and plan names are included only to show where the controls sit. For full plan and price detail see the AI Coding Tools Pricing Tracker, and for a wider view of the market see the AI Coding Tools Hub.

Enterprise controls side by side

As of 15 November 2026, from each vendor's documentation and plan pages.

Claude Code

Claude Code's organisation controls come from two places: the Claude plan, which carries identity and audit features, and Claude Code's managed settings, which carry technical policy.

• Identity and audit: Anthropic's pricing page lists SSO on Team and Enterprise, and SCIM, audit logs, the Compliance API, role-based access, domain capture and custom data retention controls on Enterprise.
• Delivery of policy: managed settings can be delivered three ways. Server-managed settings are set in the claude.ai admin console, fetched at startup and polled hourly. MDM delivery uses the com.anthropic.claudecode macOS preferences domain or a Settings value under HKLM\SOFTWARE\Policies\ClaudeCode, checked every 30 minutes. File delivery places managed-settings.json in a system directory such as /etc/claude-code/.
• Precedence: managed settings sit above user, project and local settings, so developers cannot override them, apart from a few documented cases where a stricter lower value still counts.
• Example keys: permissions.disableBypassPermissionsMode, allowManagedPermissionRulesOnly, allowManagedHooksOnly, availableModels, and allowManagedMcpServersOnly with an allowedMcpServers list.
• Group targeting: the docs state the admin console cannot target a group yet; different groups get different files or MDM profiles, or a self-hosted gateway that delivers settings per identity provider group.

Availability: per the pricing page, Team Standard is $20 per seat per month billed annually ($25 monthly); Enterprise is $20 per seat per month billed annually with a 20-seat minimum and usage billed at API rates. Product detail is in What Is Claude Code? and hardening in the Claude Code Security Guide.

Cursor

Cursor documents its organisation controls on its Enterprise documentation page and in the plan comparison on its pricing page.

• Identity: SSO with SAML or OIDC on Teams and Enterprise; SCIM provisioning and deprovisioning on Enterprise.
• Audit: audit logs on Enterprise track authentication, user management and administrative actions.
• Policy: Privacy Mode can be enforced org-wide; Model Access Restrictions and repository, model and MCP access controls are Enterprise features, alongside auto-run, browser and network controls.
• Device and network: MDM policies enforce allowed team IDs and extensions on user devices; IP allowlisting and proxy configuration are documented under network configuration. Hooks for security and compliance workflows can be distributed through MDM and server-side.
• Automation and reporting: service accounts are non-human accounts for automated workflows on Enterprise; the Analytics API provides usage metrics.

Availability: per the pricing page, Teams starts at $30 per user per month and Enterprise is custom priced. Product detail is in What Is Cursor? and hardening in the Cursor Security Guide.

Devin Desktop

Cognition documents Devin Desktop's organisation controls on a single controls page, split between account administration, team settings and device policy.

• Identity: SSO and SCIM are account-level controls in account administration (the Windsurf dashboard, or the Devin app under Settings, Administration). RBAC roles and permissions are managed there, and changing team settings requires the Devin Desktop admin permission.
• Policy: Allowlisted models limits which models members can use across Cascade, Devin Local, Command and Devin CLI. The MCP allowlist lists permitted MCP servers, and any server not on it is blocked.
• Data retention: two settings decide whether members can use Anthropic and OpenAI models that need data retention for trust and safety checks; the page states those providers keep data up to 30 days and do not train on it.
• Device policy: Windows Group Policy, macOS configuration profiles or /etc/vscode/policy.json on Linux, enforced by the operating system before the app starts. Examples include AllowedExtensions, UpdateMode and TelemetryLevel (all, error, crash or off).
• Reporting: the Individual analytics setting allows per-member analytics in team dashboards; the analytics API uses service keys created in account administration.

Availability: per the controls page, Allowlisted models, the MCP allowlist, the retention toggles and Individual analytics are Teams and Enterprise settings. Product detail is in Devin Desktop (formerly Windsurf) and hardening in the Windsurf Security Guide.

GitHub Copilot

GitHub Copilot's identity controls come from GitHub Enterprise Cloud, and its Copilot-specific controls are listed as administrator features for Business and Enterprise.

• Identity: SAML SSO can be enabled for all organisations in an enterprise, where it becomes mandatory, or per organisation. SCIM provisioning at enterprise level needs an Enterprise Managed Users account; otherwise SCIM needs organisation-level SAML. Tested identity providers are AD FS, Entra ID, Okta, OneLogin, PingOne and Shibboleth.
• Administrator features: Policy management, Access management, Usage data, Audit logs and File exclusions. The documentation also has admin pages for managing network access, the enterprise MCP allowlist and MCP registry, enterprise managed settings and model availability.
• Audit: the enterprise audit log records plan, settings and policy changes, licence changes and agent activity on the GitHub website. Searches use action:copilot and actor:Copilot. Events are kept for 180 days, with streaming to a SIEM recommended for longer history. The docs state the audit log "does not include client session data".
• Access to audit: enterprise owners, or holders of the "Read enterprise audit logs" custom role.

Availability: per the plans page, Copilot Business is $19 and Copilot Enterprise $39 per granted seat per month, and the page notes Copilot is not currently available for GitHub Enterprise Server. Product detail is in What Is GitHub Copilot? and hardening in the GitHub Copilot Security Guide.

OpenAI Codex

OpenAI documents Codex controls across its authentication, groups and provisioning, and governance pages, with identity inherited from the ChatGPT workspace.

• Identity: sign in with ChatGPT follows workspace provisioning, roles and RBAC; Codex cloud requires ChatGPT sign-in and MFA, and SSO administrators are told to enforce MFA. API key sign-in works for local surfaces and is billed at API rates.
• Provisioning and roles: SCIM provisions workspace membership and groups; each group has one authoritative membership source (manual, identity provider or dynamic), and custom roles can be assigned to groups or members. Leavers should be removed in the identity provider.
• Audit: the Compliance API exports records under conversation_message and codex_log; local execution emits separate OpenTelemetry events; admin-defined hooks can run on the cloud coordinator. The governance page warns that conversation visibility alone does not give a complete record of local actions.
• Local enforcement: managed configuration keys forced_login_method, forced_chatgpt_workspace_id and cli_auth_credentials_store, with chatgpt_base_url lockable; mismatched credentials log the user out.
• Automation: Enterprise admins can allow Codex access tokens for trusted scripts, schedulers and private CI runners.

Availability: the authentication page states feature availability varies by plan and links a comparison table. Product detail is in What Is OpenAI Codex? and hardening in the OpenAI Codex Security Guide.

How to choose: factual criteria

The right choice depends on the organisation's existing estate, not on a ranking. These criteria come from the documented controls above.

Small organisations often rely on the SSO and central policy in the base organisation plan and accept device-level enforcement later. Large or regulated organisations usually need SCIM, an exportable audit trail and device enforcement from day one, which typically means the vendor's enterprise tier.

Rolling out controls

1. Pick the plan for the controls you need: map each requirement in the table above to the tier that carries it before purchase.
2. Connect identity first: configure SSO, then SCIM, and test a joiner, a mover and a leaver before inviting users.
3. Set central policy: restrict models and MCP servers, enforce the privacy or retention setting, and record each decision.
4. Enforce on devices: deploy managed settings or device policy to a pilot group, confirm the client reports the policy is in force, then widen.
5. Wire up audit: stream audit or compliance records and local telemetry to the SIEM, and confirm retention meets your policy.
6. Govern automation identities: inventory service accounts, access tokens and analytics keys with an owner, scope and rotation date.
7. Roll back safely: keep the previous policy file or profile versioned so a bad setting can be reverted quickly.

Detection and measurement

• Coverage: share of active users signing in through SSO and provisioned by SCIM.
• Leaver lag: time from identity provider deprovisioning to loss of tool access.
• Policy in force: share of devices reporting managed settings or device policy applied.
• Audit completeness: days of audit history held in the SIEM against the required retention.
• Allowlist exceptions: number of requests for models or MCP servers outside the allowlist, and time to decision.
• Automation credentials: share of service accounts and tokens with a named owner and a rotation date.

Credentials created for these tools are covered in AI Coding Tools and Secrets Sprawl and How to audit AI coding assistant tokens and config files. Retention terms per tool are compared in the AI Coding Tools Data Retention and Training Tracker.

Practitioner checklist

• Record the date whenever you quote a vendor control or plan, and recheck the admin documentation before renewal.
• Confirm which plan carries SSO, SCIM and audit records for each tool before purchase.
• Test joiner, mover and leaver flows through SCIM before the pilot starts.
• Deploy device or managed settings so developers cannot switch to personal accounts or override policy.
• Set model and MCP allowlists centrally and review exceptions monthly.
• Stream audit and compliance records to the SIEM and check retention against policy.
• Do not present usage analytics as audit evidence.
• Inventory automation credentials for these tools with an owner, scope and rotation date.

Standards and references

• Anthropic: Claude Code, Deploy managed settings
• Anthropic: Claude pricing
• Cursor: Enterprise documentation
• Cognition: Devin Desktop admin controls
• GitHub: GitHub Copilot features
• GitHub: Reviewing audit logs for GitHub Copilot
• OpenAI: Codex governance
• OpenAI: Codex authentication

Related NHI Mgmt Group resources: AI Coding Tools Hub · AI Agent Platforms Compared · Vibe Coding Tools Compared · AI Coding Assistant Buyer's Guide