A question came up recently in my Patrons community that I think lots of MSPs will hit as agents move into tenants. If you have a Conditional Access policy that geo-blocks sign-ins from outside Australia, it will block Grok Bot. I use Grok bots throughout my own Australian tenant, so here’s a summary of what I shared about how to handle it without throwing away your geo policy.
Why it happens
Grok Bot works from cloud infrastructure, not from your desk. When it signs in or refreshes a token for your account, Entra ID sees an IP that isn’t in Australia, so your geo-block policy does exactly what you told it to. Conditional Access works out location from the client’s public IP. There’s no published egress IP list, so don’t guess ranges.
Start by confirming what’s being blocked. In the Entra admin center open Sign-in logs, filter on the account and Status = Failure, then check the Location, IP address, Application and Conditional Access tabs. That shows which policy blocked it and from where.
Option A: a dedicated bot account, excluded and compensated
This is the most practical option and my pick for most SMB tenants.
- Run the bot under its own account, not your daily admin identity, with only the licences and access it needs.
- Put that account in a small, named group, such as CA-Exclude-Geo-GrokBot, and exclude only that group from the geo-block policy. Keep every other policy applied.
- Compensate with phishing-resistant authentication strength for that account, and a sign-in risk policy if you have Entra ID P2.
- Review its sign-ins regularly and use an access review so the exclusion doesn’t live forever.
Option B: trusted named locations
If a vendor publishes fixed, stable egress IPs, you can add them as an IP-range named location and exclude that location. Without a documented list this isn’t an option, and never add whole cloud provider ranges.
Option C: app-only access and workload identities
If the bot or connector lets you plug in your own app registration, it can use the OAuth 2.0 client credentials flow with application permissions. No user signs in, so user-targeted Conditional Access isn’t evaluated. That’s the upside, and also the risk. If you go this way:
- Register a single-tenant app and grant only the Graph application permissions the job needs, e.g. Mail.Send rather than Mail.ReadWrite, Sites.Selected rather than Sites.ReadWrite.All.
- Use a certificate, not a client secret, stored in Azure Key Vault with a short lifetime and scheduled rotation.
- Scope it down with RBAC for Applications in Exchange Online and Sites.Selected in SharePoint.
- Use Conditional Access for workload identities to block the service principal from unknown locations or when it’s flagged risky. This needs Workload Identities Premium and only covers single-tenant service principals.
- Monitor Service principal sign-ins and turn on workload identity risk detections.
The trade-offs are real. Most bot connectors use delegated sign-in, so this only works if the bot supports it. A leaked credential can reach across the tenant with no MFA in the way, and audit trails show the app, not a person.
What about a local PC or Global Secure Access?
Routing through a local computer only helps for work the bot runs on that machine. Its cloud connectors still sign in from the cloud, so at best it’s a partial fix. Entra Global Secure Access is great for people and managed devices, but a cloud-hosted bot can’t run the GSA client, so treat it as an extra layer for your people.
Test, and what not to do
Make changes in report-only mode first and check the results before enforcing. Keep break-glass accounts excluded as normal. Don’t turn off the geo policy, exclude All users or admin groups, or add big IP ranges you can’t verify. Keep the exclusion narrow: one account, one group, one policy.
My verdict: if your bot supports bring-your-own app credentials and the job is narrow, app-only with a certificate, tight scoping and a workload identity policy is the stronger design. Otherwise, which is most cases today, stick with the dedicated, excluded bot account.
