If a person suspects that their ChatGPT account has been accessed by someone else, the most troublesome issue in the past was often not knowing how to change the password, but rather not knowing from which day the abnormalities began or on which device they occurred. On September 25th, OpenAI added a "Security History" section in its product update, allowing users to view recent logins and logouts, as well as changes to multi-factor authentication, passkeys, and other security settings on the web page. This feature may not be as prominent as the new models, but it touches on a increasingly realistic aspect of AI tools: when chat records, connected applications, and work files are all stored under the same account, account security itself becomes a part of the product experience.
OpenAI Note: The records will display the event time, location, and device information, but some of this information may only be approximate or not available at all. Users can find their security history in the "Settings - Security and Login" section on the web page. It's important to clarify one point here: this is a list of activities for later verification, not an automatic security system that guarantees the detection of intrusions, prevention of phishing attempts, or recovery of users' losses. The location shown cannot be taken as the exact coordinates in reality, as network exits, proxy services, and changes in mobile network connections can all affect the displayed position. The truly valuable use of these records is to compare them with the devices and actions the user was performing at the time.
Why a single record entry deserves special attention
AI Accounts are no longer just simple chat tools. Users may paste work documents into conversations, upload files, authorize plugins to access emails, calendars, or cloud storage, and then incorporate the generated results into team processes. In such cases, the impact of a login anomaly depends on what is connected to that account. A verifiable security history at least allows users to check along the timeline when they receive notifications of unfamiliar logins or notice that their settings have been altered: whether there are devices they do not recognize, whether multi-factor authentication has been disabled, or whether new access keys have been added. While these clues alone cannot prove who has accessed the account, they are certainly better than guessing based on mere memory.
It also makes practical sense to include "login" and "security settings changes" in the same record. If an attacker logs in briefly just once, users may not notice until a few days later; if they then adjust the authentication method, subsequent risks could persist. Conversely, ordinary users who frequently switch devices may also observe many seemingly abnormal events. Therefore, when making judgments, one cannot rely solely on a single geographical location record but must consider factors such as time, device used, whether they have just changed their phone or browser, and whether they are using the company network. For enterprise accounts, administrative audits and permission management represent another layer of security measures; individual security history cannot replace organizational-level logs.
The official account security guidelines for OpenAI still emphasize basic measures: using strong and unique passwords, enabling multi-factor authentication, and checking login activities and related security settings when suspicious behavior is detected. The added value of having a historical record is that it allows for these actions to be investigated based on existing records rather than after the incident has occurred. However, this does not guarantee that the records cover all possible risk details. The official statement only mentions that "recent" events can be viewed; there is no commitment in this update to permanently retain all historical data or provide evidence materials for legal purposes. Claiming to be able to "completely track all account activities" goes beyond what is stated in the announcement.
Another point that can easily lead to misunderstanding is the “logout” event. Just because an account is logged out from a certain device does not mean that the content on that device has not been accessed before; similarly, seeing an unfamiliar location where the account was used does not necessarily indicate that the account has been compromised. The security history provides a starting point for investigation, not a conclusion. A more cautious approach is to first verify your recent device and network usage, then check the authentication methods and connected applications. If you still cannot explain the situation, change your password as soon as possible, re-examine multi-factor authentication and session status, and seek assistance through official support channels. Do not casually post screenshots and complete account information in public forums for help, as this could lead to further exposure of your account information.
After visibility is improved, what else do users need to manage?
Security history can easily create an illusion: just because a platform can display events, it must be able to prevent all abnormalities. In fact, recording, alerting, blocking, and restoring are four different processes. Recording answers the question "what has happened"; alerts address "what the system suspects"; blocking involves balancing between rules and potential collateral damage; and restoration also requires resolving identity verification and permission retraction. This time, OpenAI has explicitly introduced the first of these processes. It can reduce blind spots in troubleshooting, but the user's own authentication habits and the scope of authorization granted by third-party applications still determine the extent of risk.
For those who frequently use ChatGPT on multiple devices, the most practical approach is to first become familiar with the normal usage patterns. When opening the security history for the first time, one can check whether their commonly used computers and phones are listed, and whether there have been any recently added passkeys or changes to multi-factor authentication. This way, when abnormalities occur in the future, there will be a baseline for comparison. For users with plugins and external connections, it is also important to regularly clean up any authorizations that are no longer in use. The security boundaries of an account extend beyond just the login page; the wider the range of connections, the more data that could potentially be accessed through misuse of that account.
This update does not change the capabilities of the AI model, but it does add a very basic trust mechanism when using the AI service. It makes it easier for ordinary users to notice changes at the account level, but there is still a need for judgment and action between "noticing" and "security." What is worth observing next is not how many records can be displayed on the page, but whether users can smoothly revoke sessions, verify their devices, manage connections, and receive clear support when they encounter suspicious events. A security history is like a light; it's not a door lock. Only when the light is on is it easier to determine which doors need to be checked.
Cover photography by: Steve Jurvetson, Wikimedia Commons, CC BY 2.0; The photos have been cropped and the backgrounds blurred.
