> For the complete documentation index, see [llms.txt](https://helpdesk.augmentt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://helpdesk.augmentt.com/modules/secure/alerts/safe-locations.md).

# Safe Locations

Location-based alerts — a sign-in from outside a country, security info registered from an unexpected place — are only useful if Augmentt knows what "normal" looks like for a given client. Safe Locations is how you tell it, and it's a real suppression rule: sign-ins and registrations from a safe location don't just get labeled, they don't trigger the alert at all.

You configure it from **Secure > Alerts > Safe Locations**, at three levels:

1. **Global defaults** — your baseline allowlist (countries and/or IP addresses), applied to every client unless overridden.
2. **Company exceptions** — a client-specific allowlist.
3. **User exceptions** — an allowlist for a single user, optionally **time-bound** (a start and end date, for something like an employee traveling abroad) instead of indefinite. Time-bound exceptions expire automatically so you don't have to remember to remove them.

## The levels override, they don't stack

This is the part that trips people up: a more specific level completely replaces the level above it for that scope — it doesn't add to it, and it doesn't inherit anything from it.

If you set a **company exception** for a client, that client is now evaluated only against the company exception's list. The global defaults no longer apply to that client at all, even in part — if a country was safe globally and you still want it safe for this client, it has to be re-added in the company exception's own list. The same relationship holds one level down: if a **user exception** exists and is currently active for a user, that user is evaluated only against their own exception, not the company (or global) list underneath it.

In short: whichever level is the most specific configured one for a given login wins outright, and everything above it is ignored for that scope until you either remove the override or add those locations back into it explicitly.

## Augmentt's built-in risky countries

Separately from anything you configure, Augmentt maintains its own fixed list of countries associated with a disproportionate amount of malicious sign-in activity: **Russia, China, Turkey, Brazil, Bangladesh, Pakistan, India, Nepal, Romania,** and **Afghanistan**. This list isn't configurable and isn't part of Safe Locations — it's the opposite concept: Safe Locations is where you tell Augmentt what's *expected*, while this is Augmentt's own standing opinion about what's *risky*.

The two interact at alert time rather than being merged into one list. If a client has **no** Safe Locations configured at all, a sign-in from one of these countries is flagged directly — as **Sign-in attempt from typically malicious country** (failed sign-in) or **Successful sign-in from typically malicious country** (successful sign-in). Once you configure Safe Locations for that client, this built-in list stops being the deciding factor for that client: any sign-in from a country or IP outside your configured list is treated as an out-of-operating-country sign-in instead, whether or not that country happens to be on Augmentt's list.

## How location-based alerts work

Every sign-in (successful or failed) is checked against whichever Safe Locations list applies at that moment — user, then company, then global, per the override rule above. A sign-in that matches is safe and generates nothing further. A sign-in that doesn't match feeds into a small set of rules:

* **Successful sign-in outside of operating country** — a successful sign-in from a country or IP not in the applicable Safe Locations list. If the user who signed in isn't MFA-protected, that's called out directly in the alert's own description, and those cases are prioritized ahead of MFA-protected ones when Augmentt processes a batch of sign-ins.
* **At least 3 sign-in attempts from outside operating country within an hour** and **at least 5 within 24 hours** — escalating alerts for repeated failed sign-ins from outside the applicable list, tracked per user.
* **Successful Signin from unidentifiable location/Ip** — the sign-in's country or IP couldn't be resolved at all, so it can't be matched against Safe Locations one way or the other.
* **Sign-in attempt from typically malicious country** / **Successful sign-in from typically malicious country** — covered above, and only relevant when no Safe Locations are configured for that client.

{% hint style="info" %}
Security-info registration alerts (a user or admin registering MFA methods from inside or outside a safe country) are checked against the same Safe Locations configuration as sign-ins, so setting it up tightens both at once.
{% endhint %}

{% hint style="warning" %}
Safe Locations does not affect M365 Risk Detections — those come from Microsoft's own risk model and aren't suppressible from Augmentt's side.
{% endhint %}

## Auto Remediation

Auto Remediation takes action on a user automatically the moment one of a chosen set of alerts fires, instead of waiting for someone to notice and step in. It's configured from the same **Global defaults** and **Company exceptions** setup as the rest of Safe Locations — open **Events Setup** for either one and expand **Auto Remediate**.

{% hint style="warning" %}
Auto Remediation is only available at the **Global defaults** and **Company exceptions** levels. There's no equivalent for User exceptions — a user-level entry only ever narrows Safe Locations, it can't trigger a remediation action.
{% endhint %}

It follows the same override relationship as the rest of Safe Locations: if a company exception has its own Auto Remediation configuration, that's what applies to the client — the global configuration underneath it is ignored, not blended with it.

Turning on **Enable auto remediate** exposes three things to configure:

* **Select alerts** — which alerts should trigger a remediation action, from a fixed list of six: **Successful sign-in outside of operating country**, **User registered additional security info outside of safe country**, **Admin registered additional security info outside of safe country**, **Activity from a Tor IP address**, **Impossible travel activity**, and **Atypical travel**. Only these six are eligible; you can't add an arbitrary alert type to the list.
* **Select actions** — what happens to the affected user when one of the selected alerts fires. You can pick either or both:
  * **Block sign-in** — disables the user's account in Microsoft 365, so they can't sign in again until an admin re-enables it.
  * **Sign out of all apps** — revokes the user's active sessions everywhere, forcing a fresh sign-in, without disabling the account itself.
* **Select dates** — one or more recurring weekly windows (a start day/time and end day/time, plus a time zone) that Auto Remediation is limited to. Alerts that fire outside of every configured window don't trigger a remediation action, even if they'd otherwise qualify. You can add more than one window — for example, to cover both a weekday after-hours block and the full weekend.

{% hint style="info" %}
Auto Remediation is a Secure Autopilot feature — the toggle is disabled until your organization has a valid Secure Autopilot subscription.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://helpdesk.augmentt.com/modules/secure/alerts/safe-locations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.