As of 13 August 2026, AI can only partly alert you to suspicious login activity.

What to actually do

1. Hand it to a person

   The route this page recommends

   A person who owns the outcome does this end to end, worth it when the failure is dear.

2. Use a tool built for this

   Second choice

3. Do it yourself

   The distant third

   A chat interface, power-user skill, and roughly 1 hour until you can act on the result.

   How to actually do it

   1. Open your identity provider's audit or sign-in log documentation and export a small, redacted sample of successful and failed events, including timestamps, user identifiers, source locations, devices and risk fields where available.
   2. Write down your normal working hours, expected countries, remote-working arrangements, trusted devices and the team that will investigate an alert.
   3. Paste the redacted event fields and your written context into the prompt, then ask the model to produce detection conditions, assumptions, false positives and a platform-neutral workflow.
   4. Open the administration area for your identity provider and alert destination, and compare the proposed fields and permissions with the features those systems actually support.
   5. Ask your IT or security colleague to turn the approved conditions into native rules or a controlled integration, using least-privilege access and synthetic or redacted data.
   6. Trigger test events that represent each suspicious condition and each expected normal condition, then compare the resulting notifications with the source audit logs and record missed alerts, duplicates and false positives.
   7. Send the test results and proposed thresholds to the person responsible for security monitoring, and enable the workflow only after they approve the rule coverage, escalation route and data handling.

   Prompt

   Help me design a safe alert for suspicious login activity in our workplace identity system.
   
   Context:
   - Identity provider or login system: [name]
   - Available event fields: [paste the field names or a redacted example]
   - Alert destination: [email, Teams, Slack, ticketing system or other]
   - Normal sign-in patterns: [countries, working hours, devices and travel patterns]
   - Existing security rules: [paste them]
   - People responsible for investigating alerts: [role or team]
   
   Produce:
   1. A short list of high-value detection conditions, such as impossible travel, a new country, repeated failed sign-ins, a new device or unusual administrative access. Do not treat any single condition as proof of compromise.
   2. A plain-English explanation of each condition, including likely false positives.
   3. A proposed severity, evidence to include in the alert and an investigation action for each condition.
   4. A platform-neutral workflow showing the event source, filtering, deduplication, notification and escalation steps.
   5. If code or configuration is useful, provide a clearly labelled example and state exactly which fields, permissions and platform features it assumes.
   6. A test plan using synthetic or redacted events only, covering both alerts and expected non-alerts.
   
   Do not request passwords, access tokens, unredacted personal data or live credentials. Do not claim that the rules are complete or that an alert proves an account was compromised. List every assumption and every part that an IT or security professional must verify before enabling it.

   Open it prefilled in ChatGPT or Claude, or copy it into Gemini, which takes no prefill link.