Your AI Vendor Is Now an Identity Provider

Your access review lists accounts. It does not list issuers.

On 29 July 2026 OpenAI's release notes recorded that it had begun rolling out Sign in with ChatGPT "across select plugins and partner sites, starting with Airtable, GitLab, HubSpot, Notion, Supabase, and Vercel". The help documentation describes it plainly as "an identity-provider sign-in option that lets you use identity information from your ChatGPT account to create, link, or access an account with a supported external application".

Read that sentence again with a governance hat on. An AI vendor is now in a position to mint the credential that gets a member of your staff into a business system holding your data.

What actually shipped?

The flow is ordinary federated login. OpenAI acts as the identity provider, the partner product as the relying party. A person clicks Sign in with ChatGPT on the partner's login page, or when connecting an app from the ChatGPT plugin directory, authenticates at OpenAI, and the partner then creates a new local account, links an existing one, or logs them in.

The claims released are narrow and stated: "the external application receives only your name, email address, and profile picture, if you have one". OpenAI is explicit that signing in is separate from granting access, and that any application wanting more must ask for it in its own permission flow.

None of that is alarming on its own. Two other facts are.

It is also the opposite direction of travel from the AI vendor risk most organisations have already logged. When a government began vetting who could use a frontier model, the exposure was the vendor restricting your access to the model, and the right home for it was the vendor risk register. This is the reverse. The vendor is not withholding something from you. It is granting something into you, and the owner is identity and access management rather than vendor management. Both can be true about the same supplier at the same time, which is why the two land in different registers.

The default is on

From the same help page: "By default, Sign in with ChatGPT is enabled for organizations that have not set an explicit policy. Existing allow or deny policies, including approved-application lists, remain in effect and are not overwritten."

The control is opt out, not opt in. Global admins have two levers, sitting under Access, then External Access in the global admin console as at 10 September 2026: an organisation-wide switch that prevents members using Sign in with ChatGPT at all, and an Approved applications mode that limits it to applications the organisation has approved.

If nobody in your organisation has opened that console, a decision has been made on your behalf, and it was made in the permissive direction. That is the difference between a setting you chose and a setting you inherited, and it is exactly the distinction an auditor will draw.

Count the trust hops, and notice one can be missing

In the well-governed case there are two hops. Your corporate identity provider authenticates the person into their corporate ChatGPT account, and ChatGPT then authenticates them into the partner product. Your conditional access policy, your multi-factor posture and your session rules sit at hop one and propagate, imperfectly, through hop two.

In the other case there is one hop. A staff member with a personal ChatGPT account, created with a personal email, uses it to sign into a business product your team already runs. Your identity provider was never in the path. There is no conditional access, no corporate session lifetime, and no log entry on your side. The account still exists in a system holding your data.

The join is the email address. Supabase's own launch post for the beta describes linking an existing Supabase account when the email addresses match, which is the standard way federated login is bolted onto an existing user table. The strength of the whole chain therefore rests on email verification quality and on which ChatGPT account the person happened to use. Nothing in the flow requires it to be the corporate one.

Revocation is the harder half, and the vendor says so

This is the part worth taking to your identity team.

OpenAI shipped an Active sessions control for business accounts in June 2026 so users can review and end sessions. Its release notes carry two limits that matter more than the feature.

First: "Active sessions shows sessions known through session management, including ChatGPT, Codex, and API Platform sessions where available. It does not manage third-party app sessions, connected apps, Sign in with ChatGPT sessions used only for third-party services, or Codex CLI sessions."

Second: "This feature is not available for accounts linked to an organization's SSO sign-in, including SAML or OIDC."

So a user who signs out of everything in ChatGPT does not thereby end the downstream sessions that Sign in with ChatGPT created at the partner products. And the corporately managed population, the one a regulated organisation cares about most, cannot see the page at all.

Whether disabling an account in your directory propagates through to a federated session at a partner product is a question of how each relying party is configured. It is not a property of the protocol. That makes it something to test with a real leaver, not something to assume in a control description.

The same shift is running on the machine side

Human federation is only half of it. Agents are being issued their own first-class identities rather than borrowing a person's. Microsoft's Entra Agent ID creates directory accounts for non-human principals, describing agent identities as accounts "that provide unique identification and authentication capabilities for AI agents", on the reasoning that "identity models designed for human users and applications prove insufficient". The stated payoff is retiring agents "without leaving orphaned credentials or permission assignments behind".

The Model Context Protocol revision dated 28 July 2026 moved the same way on authorisation, requiring clients to validate the issuer parameter per RFC 9207 before redeeming a code, binding client credentials to the issuer that minted them with no reuse across authorisation servers, and formally deprecating Dynamic Client Registration in favour of Client ID Metadata Documents.

Both changes are about the same question. Which issuer minted this, and are we sure. That is a narrower question than the one raised by governing the connectors an agent can reach, and it sits underneath it: connector governance decides what a principal may touch, issuer governance decides whether the principal should exist at all.

What the Australian guidance already tells you to do

The joint guidance on careful adoption of agentic AI services, first published 1 May 2026 and co-authored by ASD's ACSC with CISA, the NSA, the Canadian Centre for Cyber Security, NCSC-NZ and NCSC-UK, states the principle in one line: "Identity is every bit as important as privilege."

Its recommended practices are written for agents but read across cleanly. Construct each agent as "a distinct principal, a cryptographically anchored identity with its own unique keys or certificates". "Maintain a trusted registry and bind identities to authorised roles; periodically reconcile the registry against the live set of agents." And then the sentence that generalises: "Deny access for any agent or cryptographic key that is not present in the trusted registry."

A registry of permitted principals, reconciled against reality, with deny-by-default for anything absent. That is the control. It was written for machines and it is precisely what human federation now needs.

The guidance also names the organisational mistake to avoid: address AI security "within established cyber security frameworks rather than treating it as a separate or standalone discipline". This belongs in your identity and access management process, not in a new AI committee.

For APRA-regulated entities there is a harder edge. If a vendor sits in the authentication path for a system holding your information assets, it is a third party in a control path. CPS 234 paragraph 16 requires the entity to "assess the information security capability of that party, commensurate with the potential consequences of an information security incident affecting those assets", and footnote 7 removes the obvious escape hatch: paragraph 16 "applies to all information assets managed by related parties and third parties, not only those captured under agreements with service providers of outsourced material business activities". Paragraph 22 goes further and requires the entity to "evaluate the design of that party's information security controls". There is no outsourcing contract to point at here. Footnote 7 anticipates exactly that.

Practically, that means the identity path belongs in the questions you already ask an AI vendor under CPS 234, and it belongs in the same file as the notification terms, because a vendor incident starts clocks on your side whether or not you signed anything with them.

Do this Monday

1. Open the console and make the decision. Access, then External Access. Choose off, or on with Approved applications and a named allowlist. Record the decision, the date and who made it, because the audit question is whether it was chosen or inherited.
2. Check the six named partners against your software register. Airtable, GitLab, HubSpot, Notion, Supabase and Vercel are common in Australian engineering, product and marketing teams. Start where you already have data.
3. Add one column to the next access review. Head it "issuers accepted" and populate it per system. An account list that does not say who may create accounts is not a complete review.
4. Ask every SaaS vendor three questions. Does account linking require a verified email address. Can we restrict which identity providers this tenant accepts. Does your deprovisioning cover accounts created through federation.
5. Test one leaver. Take a recent departure and prove their access to one federated product actually ended. That test, with its date and result, is the record worth keeping.

Bottom line

Nothing here is a breach, a vulnerability or a vendor behaving badly. It is a quiet expansion of the set of parties who can issue a credential into your systems, shipped with a permissive default and a documented gap between signing out and being out. The reason it matters beyond one product is that Sign in with X will keep spreading, on both the human and the machine side, because it removes friction and every AI vendor wants to sit in the middle of the workflow. An access review that enumerates accounts, roles and entitlements no longer answers the question that decides whether those entitlements can be reached. It is the same counting error that lets a long vendor list hide a single foundation model: the register records the names, not the dependency underneath them. Add the issuer column.

References

1. OpenAI, Sign in with ChatGPT, help documentation, updated August 2026. https://help.openai.com/en/articles/20001410-sign-in-with-chatgpt
2. OpenAI, ChatGPT Release Notes, entry dated 29 July 2026. https://help.openai.com/en/articles/6825453-chatgpt-release-notes
3. OpenAI, ChatGPT Business Release Notes, Active account session controls, entry dated 2 June 2026. https://help.openai.com/en/articles/11391654-chatgpt-business-release-notes
4. Supabase, Sign in with ChatGPT is in beta on Supabase, 29 July 2026. https://supabase.com/blog/sign-in-with-chatgpt-beta
5. Australian Signals Directorate's Australian Cyber Security Centre and partner agencies, Careful adoption of agentic AI services, first published 1 May 2026. https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/careful-adoption-of-agentic-ai-services
6. Australian Prudential Regulation Authority, Prudential Standard CPS 234 Information Security, July 2019, paragraphs 16 and 22 and footnotes 7 and 10. https://www.apra.gov.au/sites/default/files/cps_234_july_2019_for_public_release.pdf
7. Model Context Protocol, The 2026-07-28 Specification, 28 July 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28/
8. Microsoft Learn, What are agent identities?, Microsoft Entra Agent ID, updated 15 June 2026. https://learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities