Back to the CIO and CSO starting point Security and GRC hub
AI identity and developer access: SSO, MFA, keys and git
AI identity and developer access is the set of controls that decide who can sign in to AI tools, which machines and pipelines can call model APIs, and what code assistants can do in a repository. Lightbridge splits it into four layers: workforce sign-in, strong authentication, non-human credentials, and developer guardrails.
This page is for a CIO, CSO, or head of engineering who needs to know what each control does and where it stops. Vendor statements are attributed and linked. Each cited source page was re-fetched on 2026-11-03. The pages carry no publication date in the fetched text, so no per-source date is shown. Lightbridge does not recommend a vendor here. It sits within Lightbridge's security and GRC advisory hub, next to the guides on AI agent security and AI observability and audit logging.
SSO, SCIM, and domain verification: what Lightbridge checks first.
Source pages re-fetched 2026-11-03; none states a publication date.
Start with the workforce. Anthropic states that for Claude Team and Enterprise, domain verification proves domain ownership, all verified domains must be managed through a single identity provider, and verification alone does not change existing users' access. It states the default provisioning mode is Invite only, with Just-in-Time provisioning as an option that gives new users the User role by default (Anthropic, SSO setup).
SCIM goes further, with a plan limit. Anthropic's SCIM page states SCIM is available on Enterprise plans and Console organizations only, not Team plans (Just-in-Time provisioning does work on Team). Anthropic states SCIM directory sync provisions and deprovisions users based on identity provider assignments without requiring a first login, and that SCIM with group mappings propagates role and seat tier changes by group membership. Group mappings set role type and seat tier only. Microsoft Entra pushes SCIM changes every 40 minutes, and the Primary Owner is exempt from SCIM reconciliation. Owner and Admin roles are not exempt: they are removed if they are not in a mapped group (Anthropic, JIT and SCIM). Plan for that delay when you offboard someone.
OpenAI describes directory sync (SCIM) as a way for eligible customers to synchronize users or groups from an identity provider, and states a standalone ChatGPT Business plan does not include SCIM. For ChatGPT for Teachers K-12 district tenants, it states domain claiming is not required to enable SCIM. We found no general statement for other plans on that page. It also states a successful sign-in or matching email does not automatically grant access to every product, so invitations, synchronized assignments, and roles decide access (OpenAI, identity and access).
Two stated limits deserve a runbook. Anthropic states that if Require SSO is on and the identity provider certificate or client secret has expired, no one in the organization can sign in to fix it, and support must be contacted. It also states it does not support identity-provider-initiated login for Claude Console organizations that share SSO settings with a Team or Enterprise organization. Put certificate expiry dates in a calendar and keep a documented break-glass path.
SSO, SCIM, and MFA documentation for Microsoft Copilot and Google Gemini: Not stated in the documentation we reviewed. Whether Claude enforces MFA natively or delegates it to the identity provider: Not stated in the documentation we reviewed. Check each before you rely on it.
Phishing-resistant authentication: where Lightbridge puts FIDO/WebAuthn.
Source pages re-fetched 2026-11-03; none states a publication date.
Phishing-resistant MFA is a control at the identity provider. When an AI tool hands sign-in to your SSO, the strength of that sign-in is whatever your provider enforces. CISA's fact sheet lists FIDO/WebAuthn and PKI-based authentication as phishing-resistant MFA and urges administrators and high-value targets to implement it or plan the migration (CISA fact sheet on implementing phishing-resistant MFA, linked in the sources section of this page). CISA also states SMS or voice MFA should be a last resort, because it is vulnerable to phishing, SS7, and SIM swap attacks. The same sheet allows it as a temporary solution during the transition.
NIST gives the assurance levels. SP 800-63B-4 states applications assessed at AAL2 must offer a phishing-resistant authentication option, and that AAL3 requires a phishing-resistant authenticator with a non-exportable authentication key (NIST SP 800-63B-4). Its treatment of syncable authenticators such as passkeys: Not stated in the documentation we reviewed.
Lightbridge's view, offered as judgment: order the rollout by blast radius. Identity provider administrators and AI workspace owners first. Then engineers with repository write access. Then everyone else. Keep a fallback method for lost keys, and write down who can approve a reset.
Non-human identity and API key custody, as Lightbridge frames it.
Source pages re-fetched 2026-11-03; none states a publication date.
Pipelines, agents, and scheduled jobs call model APIs without a person present. The default is an API key in an environment variable, and the key outlives the person who created it. The better pattern is a short-lived token tied to the workload.
Anthropic states Workload Identity Federation lets workloads authenticate to the Claude API with short-lived OIDC tokens instead of long-lived sk-ant API keys. It states the minted token lifetime is the lesser of the rule's token_lifetime_seconds (60 to 86400, default 3600) and twice the remaining lifetime of the presented identity provider JWT, and never less than 60 seconds (Anthropic, Workload Identity Federation). The same page states Workload Identity Federation is not a complete security solution and is only as strong as the upstream identity provider. GitHub states OIDC lets workflows exchange short-lived tokens with a cloud provider so long-lived cloud credentials need not be stored as GitHub secrets, and that the token is valid for a single job (GitHub, OpenID Connect).
What we did not find: OpenAI project-scoped key and workload federation documentation, and workload identity for the major cloud model services. Both: Not stated in the documentation we reviewed.
Where a key is unavoidable, Lightbridge advises four habits. Name an owner for every key. Scope it to one workload. Set a rotation date. Keep it out of chat tools, tickets, and notebooks. If you route traffic through a gateway so keys never reach applications, see Lightbridge Automation's explainer on LLM gateways.
The developer surface: code assistants, repositories, and git, per Lightbridge.
Source pages re-fetched 2026-11-03; none states a publication date.
Code assistant policy
Anthropic documents that Claude Code managed settings (managed-settings.json, MDM, or server-managed through claude.ai) are the highest precedence level and are not overridden by user files or the --settings flag, with a few exceptions: for some security-sensitive keys a stricter lower-level value is honored, and a managed model setting is a default rather than a lock (availableModels and deniedModels are the locks) (Anthropic, settings). It also documents that a local administrator can edit the managed source, and that managed settings bind Claude Code only, not other tools (Anthropic, managed settings).
GitHub states Copilot policies control which features, agents, and models users can access, are set at the enterprise level first, and can be enabled, disabled, or left for organizations to decide. Policies can apply to any surface where users authenticate to Copilot, and users given access directly by the enterprise are not covered by "Let organizations decide" (GitHub, Copilot policies).
Repository and git controls
GitHub states push protection blocks pushes containing secrets before they reach the repository. It is disabled by default for repositories and requires GitHub Secret Protection. By default anyone with write access can bypass it by giving a reason, which creates an alert and an audit log event; GitHub notes delegated bypass can restrict that. User-level push protection is on by default for public repositories on GitHub.com (GitHub, push protection). GitHub also states repository administrators can enforce required commit signing on a branch, which blocks all commits that are not signed and verified (GitHub, commit signature verification).
For review, GitHub states the enterprise audit log lists events from the last 180 days and retains Git events for seven days. By default only the past three months are displayed unless a date range is given (GitHub, enterprise audit log). Copilot-specific audit events, secret scanning coverage of AI-generated code, and branch protection rules beyond signed commits: Not stated in the documentation we reviewed. Log design is covered in Lightbridge's guide to AI observability and audit logging.
The controls table Lightbridge uses: documented features and stated limits.
Each row says what the source states, except where a cell is marked as a Lightbridge note. Source pages re-fetched 2026-11-03; none states a publication date. Where the sources are silent, the cell says so.
| Control | Documented feature | Stated limit or gap |
|---|---|---|
| Claude SSO and domain verification | Domain verification, single identity provider for all verified domains, Invite only or Just-in-Time provisioning (source). | Verification alone does not change existing users' access. An expired certificate or secret with Require SSO on locks everyone out until support is contacted. |
| Claude SCIM | Provision and deprovision without a first login, group mappings for role and seat tier (source). | Mappings set role and seat tier only. Entra pushes changes every 40 minutes. The Primary Owner is exempt from reconciliation. |
| ChatGPT SSO and SCIM | Directory sync for eligible customers; access set by invitations, synchronized assignments, and roles (source). | A standalone ChatGPT Business plan does not include SCIM. Sign-in does not grant access to every product. SSO enforcement and MFA text: Not stated in the documentation we reviewed. |
| Phishing-resistant MFA | CISA lists FIDO/WebAuthn and PKI-based methods. NIST SP 800-63B-4 requires a phishing-resistant option at AAL2 and a non-exportable key at AAL3 (CISA, NIST). | CISA: SMS or voice only as a last resort or a temporary transition step. AI vendor MFA enforcement: Not stated in the documentation we reviewed. |
| Claude API Workload Identity Federation | Short-lived OIDC tokens in place of long-lived keys; lifetime 60 to 86400 seconds on the rule, default 3600 (source). | Applies to the Claude API. Anthropic states it is not a complete security solution and is only as strong as the upstream identity provider. Equivalent OpenAI and cloud-provider federation: Not stated in the documentation we reviewed. |
| GitHub Actions OIDC | Short-lived tokens exchanged with a cloud provider, valid for a single job (source). | GitHub frames the benefit as applying when the cloud provider supports OIDC and trust is configured. |
| Claude Code managed settings | Highest precedence, not overridden by user files or --settings, except a stricter lower-level value for a few security-sensitive keys (source). | A local administrator can edit the managed source. A managed model is a default, not a lock. Binds Claude Code only, not other tools (source). |
| GitHub Copilot policies | Control features, agents, and models; set at enterprise level; apply to any surface where users authenticate (source). | Users given access directly by the enterprise are not covered by "Let organizations decide". |
| GitHub push protection | Blocks pushes containing secrets before they reach the repository (source). | Disabled by default for repositories; requires GitHub Secret Protection. By default, write access can bypass with a reason, which raises an alert and an audit log event. |
| Required signed commits | Repository administrators can block unsigned or unverified commits on a branch (source). | Scoped per branch. Other branch protection rules: Not stated in the documentation we reviewed. |
| GitHub enterprise audit log | Events from the last 180 days (source). | Git events retained for seven days. Only the past three months display by default. Admin audit logs for Claude, ChatGPT, and Gemini: Not stated in the documentation we reviewed. |
A working checklist from Lightbridge for identity and developer access.
These items are Lightbridge's planning judgment, built on the documented behavior above. They are not a vendor or standards requirement.
- Verify your domains and route every AI workspace through one identity provider.
- Turn on SCIM where the plan offers it, and measure how long a leaver keeps access given the sync interval.
- Calendar every SSO certificate and client secret expiry. Document a break-glass path.
- Require phishing-resistant MFA for identity provider admins and AI workspace owners first.
- Retire SMS and voice codes for privileged roles.
- Inventory every AI API key, its owner, its scope, and its rotation date.
- Move pipelines to short-lived tokens where the vendor supports it.
- Push code assistant policy from a managed source, and accept that it covers one tool.
- Enable secret push protection on every repository where your GitHub licensing includes it, and review the bypass events.
- Require signed commits on protected branches.
- Export audit events on your own schedule, since Git events are kept for seven days.
How Lightbridge advises on AI identity and developer access.
Lightbridge is an independent advisory and program-management firm. We help a CIO or CSO map who and what touches AI services today, set the order of the rollout, and run the program through delivery. Where hands-on configuration is needed, vetted partners deliver under Lightbridge's program management.
Identity sits beside other layers. Read shadow AI discovery for the accounts you have not seen, AI hosting options for where models run, and AI contracts and legal for the terms behind each tier. This guide is part of Lightbridge's security and GRC advisory hub.
Lightbridge Automation, a sibling practice in the Lightbridge group, offers AI governance consulting and publishes explainers on zero data retention and the Claude compliance guide. If a recommendation here points to work a sibling practice would deliver, Lightbridge discloses that upfront and you remain free to take the work elsewhere. The AI governance consulting above is a Lightbridge Automation service.
AI identity and developer access: frequently asked questions answered by Lightbridge
Does turning on SSO for an AI tool mean everyone is covered?
No. Anthropic states that domain verification alone does not change existing users' access, and OpenAI states that a successful sign-in or matching email does not automatically grant access to every product. Invitations, synchronized assignments, and roles decide access. Source links and the 2026-11-03 fetch date are in the sections above. Lightbridge advises checking who still holds a direct or personal login after SSO goes live.
Where does phishing-resistant MFA fit for AI tools?
FIDO/WebAuthn credentials belong at the identity provider, where the AI tool delegates sign-in. CISA lists FIDO/WebAuthn and PKI-based authentication as phishing-resistant MFA, and NIST SP 800-63B-4 states AAL2 applications must offer a phishing-resistant option. Whether each AI vendor enforces MFA itself or relies on your identity provider: Not stated in the documentation we reviewed.
Can SMS codes still be our MFA for AI admins?
CISA states SMS or voice MFA should be a last resort (or a temporary step during migration) because it is vulnerable to phishing, SS7, and SIM swap attacks (CISA fact sheet on implementing phishing-resistant MFA, linked in the sources section of this page). Lightbridge advises phishing-resistant methods for administrators and anyone with access to sensitive data first, then widens coverage as the identity provider allows.
Why move from API keys to workload identity?
A long-lived key can be copied, pasted into a ticket, or committed. Anthropic states that Workload Identity Federation lets workloads authenticate to the Claude API with short-lived OIDC tokens instead of long-lived sk-ant keys. GitHub states Actions OIDC avoids storing long-lived cloud credentials as secrets. Equivalent OpenAI and cloud-provider federation: Not stated in the documentation we reviewed.
Do managed settings in a code assistant stop developers using other AI tools?
No. Anthropic documents that managed settings for Claude Code bind Claude Code only, not other tools, and that a local administrator can edit the managed source. Lightbridge treats managed settings as one control in a set, alongside identity-provider policy, network egress rules, and repository protections.
Will push protection catch every secret an AI assistant writes?
Not on its own. GitHub states push protection is disabled by default for repositories, requires GitHub Secret Protection, and that by default anyone with write access can bypass it by giving a reason, which creates an alert and an audit log event. Coverage of secrets in AI-generated code specifically: Not stated in the documentation we reviewed.
How long can we look back at who did what in GitHub?
GitHub states the enterprise audit log lists events from the last 180 days and retains Git events for seven days. If your contracts or customers expect a longer record, Lightbridge advises exporting or streaming events on a schedule you set, and confirming the current retention terms with GitHub.
Map your AI identities: talk to a Lightbridge advisor.
Bring your identity provider, your AI workspaces, and your repository settings. Lightbridge will help you sequence the controls and show your security team where each one stops.