Skip to main content
AI & Technology

What ChatGPT Security History Shows, and What Business Teams Still Need to Do

Security history gives individual OpenAI account holders a recent activity view. This article explains how it differs from Active sessions and sets out a practical response checklist for business AI users.

26 Sep 20266 minOpenAI Help Center
ChatGPTAccount SecurityOpenAIBusiness Security
AI-generated illustration of a professional reviewing an activity list on a laptop; it does not depict real Enersys personnel, premises, or account data
AI-generated illustration of a professional reviewing an activity list on a laptop. It is a generic visual and does not depict real Enersys personnel, premises, or account data.

What ChatGPT Security History Shows, and What Business Teams Still Need to Do

Consider an employee who opens Security history and sees a sign-in from an unfamiliar city. Active sessions shows no device they recognize.

Should the employee change the password immediately, or could the location be an approximation caused by the company network or a VPN? The answer should not come from the city name alone. A clean Active sessions view is not proof that the account is safe, either.

On September 25, 2026, OpenAI announced Security history in ChatGPT. It gives users a way to review recent security events for an OpenAI account. A business team should use that view as a starting point, then know what other evidence to check when an event has no clear explanation.

What the announcement adds

OpenAI’s release notes describe Security history as a view of recent sign-ins, sign-outs, and changes to MFA, passkeys, and other security settings. Events may include time, location, and device details; some details may be approximate or unavailable. OpenAI, ChatGPT Release Notes, September 25, 2026

On the web, open ChatGPT and go to Settings > Security and login > Security history. Availability and menu visibility can vary by account, so check the actual account when running a review.

The practical use is simple: an account owner can ask, “What recently happened to this account?” and then compare the result with other records. The view does not by itself identify the person who performed an action.

Security history is different from Active sessions

The two views answer different questions.

  • Security history focuses on past security events, such as sign-ins, sign-outs, and security-setting changes.
  • Active sessions focuses on sessions that are still active and trusted devices. It lets a user review details and log out of an individual session or all sessions.

OpenAI’s Active sessions guidance says a row may show browser or device information, first-party app context, approximate location, sign-in time, trusted-device status, and whether it is the current session. Details may be incomplete. The view does not show or manage third-party app sessions, connected apps, Sign in with ChatGPT sessions used only for third-party services, or Codex CLI sessions. It also does not show sessions that have already been signed out. OpenAI, Managing active sessions in ChatGPT

Active sessions is unavailable for accounts linked to an organization’s SSO sign-in, including SAML and OIDC. Teams using SSO should check their identity provider for the relevant records.

Use the two views together, then add identity-provider records, downstream application logs, and API activity data when investigating an organization-level incident.

Read time and location with context

The displayed location is not a precise geographic record. OpenAI says details in Security history and Active sessions may be approximate or unavailable. A company gateway, VPN, mobile network, or internet provider can make the displayed city differ from the employee’s actual workplace.

Start by comparing three things: time, event type, and device. A sign-in that matches a planned trip, a known device, and the company network may be explainable even if the city is unexpected. A change to MFA or a passkey that nobody on the team approved deserves follow-up even if the location looks familiar.

Do not delete or dismiss an unexplained event before preserving the available time, event type, and device details in line with company policy. A shared evidence set helps the account owner, identity provider, and OpenAI Support discuss the same facts. If a screenshot is needed, request only what the incident requires through an agreed, privacy-aware procedure. Do not routinely ask employees to send screenshots of personal security data.

Define who can access the evidence, how long it is kept, and which events require escalation. An individual account review should stay limited to the work it needs to support.

A business account-security checklist

Use this checklist for accounts that perform important work or connect to company information. Make the owner of each decision explicit.

  1. Identify the account type and sign-in method. Personal accounts, managed workspaces, and accounts linked to SSO may expose different screens or controls. Active sessions is unavailable for organization SSO accounts, including SAML and OIDC. Do not assume that one user’s view represents everyone’s.
  2. Open Security history for the review period. Compare sign-ins, sign-outs, MFA, passkeys, and other security changes with the work schedule, travel, and approved changes.
  3. Open Active sessions. Review current sessions and trusted devices. If a session is unfamiliar, log out of that session or all sessions according to the incident plan. OpenAI says logging out of all devices can take up to 30 minutes to complete across sessions.
  4. Check sign-in protection. Use a unique password, enable MFA, and review the passkeys or sign-in methods allowed by company policy. If a password may have been exposed, reused, or shared, change it immediately. OpenAI, Keeping your OpenAI account secure
  5. Separate the account from keys and connections. Inventory API keys, connected apps, plugins, and tools that use the account. If a key may be exposed, rotate it through the platform’s procedure and review API activity in the Platform separately from Security history.
  6. Define the response path. For an event the owner cannot explain, change the password, log out of all sessions, review sign-in methods, preserve evidence, and contact OpenAI Support as appropriate. Employees should not have to decide alone whether a signal is an incident.
  7. Recheck access after role changes. Review devices, apps, and keys that remain connected when someone changes role or leaves, then coordinate with the workspace owner, identity provider, and downstream system owners.

What Security history does not do

When a business has many accounts, several sign-in paths, or shared use of APIs and connected apps, remember that Security history remains an account-level tool. It is not organization-wide user monitoring, a complete record of data use, or evidence that a company meets a particular compliance obligation.

Organization-level controls still need records from the SSO or identity provider, device and network management, API usage and cost monitoring, connected-app reviews, and joiner, mover, and leaver procedures. Those controls belong to the systems and processes the organization chooses; they do not appear simply because Security history is enabled.

If an event cannot be explained, start by reducing the immediate account risk, then separate whether the issue concerns the account, a session, a sign-in method, an API key, or an external system. Better visibility can shorten the first response, but it should not make a team ignore evidence from the other tools in the same path.

"Empowering Innovation,
Transforming Futures."

Contact us to make your project a reality.