Investigate a GitHub security-log event you do not recognize

A security-log entry can show a sign-in, authorization or account-setting change, but a single unfamiliar location is not proof of an intruder. VPNs, browser changes and legitimate tools can generate surprising entries. The event category, timestamp and related token or repository are more useful than a city label. GitHub lets personal-account owners review and export their security log; use it as a timeline for containment, not as a complete record of everything an attacker viewed.

Before you start​

Use a trusted session and preserve the event details without publishing them. Know the recent work you and your automation performed. If the account belongs to an organization, also tell the organization security owner because its audit log and app installations may hold additional evidence.

Do it step by step​

1. Open GitHub Settings, Security log and select the relevant timeframe. Filter or search for the event action and note the precise timestamp, actor, repository and token information shown. Export the log if a structured copy is needed for an incident review.
2. Compare the event with your known device, browser, VPN and CI schedule. Check View and manage sessions for an unexplained login. Avoid dismissing a suspicious token event merely because its location resembles your own cloud provider.
3. Inspect authorized OAuth apps, GitHub Apps and personal access tokens for a new or expanded grant. Revoke what you cannot explain and record the app name or token metadata before removing it.
4. Review SSH and deploy keys, repository collaborators, new commits, releases and workflow runs around the same time. A repository change may be the consequence you need to contain, while a session row alone is only an access clue.
5. If compromise remains plausible, revoke credentials or sessions using GitHub's official controls, change the password, secure your email and check 2FA methods. Rotate exposed repository secrets and coordinate with organization owners if shared resources were affected.
6. Document the sequence of evidence and actions, then monitor for a repeat. Test a legitimate automation after revoking its token so an emergency security step does not silently halt a needed release.

Check the result​

You can link or explain each relevant event, no unknown session or grant remains, and affected repositories and workflows have been checked for changes. Keep the exported log securely because it may include sensitive metadata.

If something goes wrong​

If a filter shows nothing, expand the timeframe and inspect related event categories; not every action has the label you expected. If you cannot resolve an event, contact GitHub Support through its official site and your organization owner if applicable. Do not paste a token into a support ticket.

Know the limit​

The personal security log is not a network-packet capture or proof no data was copied. Some app actions appear in organization audit logs or service logs instead. Event names and retained history can change, so consult GitHub's current event reference during an investigation. GitHub security-log guide GitHub key review