Microsoft Defender automated URL access triggering Controlled/Uncontrolled Logic App actions from Microsoft-owned IP addresses

Question

Microsoft Defender automated URL access triggering Controlled/Uncontrolled Logic App actions from Microsoft-owned IP addresses

Sayan Dutta 105

We are experiencing an issue with our Microsoft Sentinel incident validation playbook. We have a playbook that shares email with two actionable buttons: Controlled and Uncontrolled. Each button contains an Azure Logic App HTTP URL. When a user intentionally clicks either button, the corresponding Logic App endpoint is invoked, and the selected response is recorded against the Microsoft Sentinel incident.

Issue observed:

Recently, we have observed that shortly after the Validate playbook sends the incident notification email, typically within approximately one minute, either the Controlled or Uncontrolled action is automatically triggered even when the recipient has not clicked either button. During our investigation, we reviewed the Logic App run history and observed that these unexpected HTTP requests are originating from various Microsoft-owned IP addresses. This is causing incorrect or duplicate incident responses to be recorded without legitimate user interaction.

Troubleshooting performed:

Validated Safe Links DoNotRewriteUrls Confirmed that the actual Controlled/Uncontrolled Logic App URLs present in the notification emails correctly match the URLs configured under: Safe Links → Do not rewrite the following URLs in email.
Tested Safe Links API-only / DisableURLRewrite: We identified that the setting “Do not rewrite URLs, do checks via Safe Links API only" was enabled in an affected tenant while disabled in a working tenant. As a troubleshooting step, we disabled this option in the affected tenant and retested. Result: Automatic requests from Microsoft-owned IP addresses continued.
Tested Tenant Allow/Block List: Added the corresponding Logic App URLs under: Tenant Allow/Block List → URLs → Allow. Result: The issue continued and automatic Controlled/Uncontrolled actions were still observed.

We suspect that a Microsoft 365/Defender security component may be automatically accessing the Logic App URLs as part of URL inspection, reputation analysis, detonation, pre-fetching, or another security validation process. However, we cannot currently identify which Microsoft component is responsible.

Assistance required:

Why are the Logic App URLs still being automatically accessed even though they are configured under Safe Links DoNotRewriteUrls?
Is there a supported method to exclude only these specific Logic App URLs from automated Microsoft URL access/scanning, while retaining normal Safe Links protection for the rest of the email and for the recipients?
Is there any Microsoft-supported configuration that allows Safe Links protection to remain enabled while ensuring that these URLs are only accessed following an intentional end-user click?
Are there any recent changes to Microsoft Defender for Office 365/Safe Links URL-processing behaviour that could explain why this previously worked correctly and is now occurring issues?

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hello @Sayan Dutta

Based on the testing you've already performed, I don't think the issue is with the Logic App itself. The important distinction here is between URL rewriting and URL inspection/access by Microsoft security services.

The Do not rewrite the following URLs setting primarily prevents Safe Links from rewriting those URLs. Microsoft notes that URLs in this list aren't scanned or wrapped by Safe Links during mail flow, but this shouldn't be interpreted as a guarantee that another Microsoft security-processing component can never access the URL.

Microsoft Defender for Office 365 also performs URL reputation analysis and detonation. Microsoft documents URL detonation as a detection technology in which Safe Links evaluates a URL in a sandbox, and a single URL can trigger a detonation chain involving additional URLs.

That makes the behavior you're seeing technically consistent with an automated security service following the HTTP endpoint, although the Microsoft-owned source IP by itself isn't enough to identify exactly which Defender/Microsoft 365 component generated the request.

There's also an architectural problem here that I think is worth addressing. Your URLs aren't ordinary navigation links—they perform a state-changing operation:

GET/HTTP request → Logic App runs → Sentinel incident state changes

I wouldn't rely on receiving an HTTP request to that URL as proof of intentional human interaction. Email security scanners, URL reputation systems, preview services, and similar automated systems can potentially dereference URLs without the recipient consciously clicking them.

A safer design would be:

Email link → confirmation page → authenticated user confirmation → Logic App action

In other words, the URL contained in the email should ideally be non-destructive/idempotent. The actual Controlled/Uncontrolled operation should occur only after a second explicit action, preferably with authentication and a short-lived signed token or another mechanism that can validate the request.

This would also protect you from duplicate requests, link previews, and other automated HTTP clients—not only Defender.

Regarding the specific questions:

1. Why does this happen despite DoNotRewriteUrls?

Excluding a URL from Safe Links rewriting doesn't guarantee that no Microsoft security component will ever access the URL. Your results also show that changing API-only rewriting behavior and adding the URL to the Tenant Allow/Block List hasn't stopped the requests.

2. Can individual URLs be guaranteed to be accessed only by users while keeping Safe Links enabled?

I can't find Microsoft documentation that provides such a guarantee. The documented exclusions control Safe Links processing behavior, but I wouldn't use them as a security boundary for a state-changing HTTP endpoint.

3. Can Safe Links remain enabled?

Yes, and I wouldn't recommend weakening Safe Links tenant-wide to solve this. Instead, make the Logic App endpoint resistant to automated URL retrieval.

4. Has Microsoft recently changed this behavior?

I couldn't find a published Microsoft advisory or documented change that confirms a recent change specifically responsible for this behavior. So I wouldn't say this is a confirmed Safe Links regression yet.

Since you have already reproduced the issue and identified Microsoft-owned source IPs, one additional step would be valuable before changing the playbook.

Capture one occurrence with:

UTC timestamp, Source IP, HTTP method, User-Agent, Request headers, Logic App run ID, and Message/notification timestamp

If possible, compare the headers from an automatic invocation against an actual user click. That could provide useful evidence about whether the request originates from Defender URL inspection, another Microsoft 365 component, or something else.

At this stage, I also think this warrants Microsoft-side investigation.

Microsoft Moderator: Could you please help escalate this to the Defender for Office 365/Safe Links engineering team? The key question is which Microsoft service is dereferencing these URLs despite Safe Links and the Tenant Allow/Block List configuration, and whether there is a supported exclusion specifically for this scenario.

Sharing these references with you:

Microsoft – Safe Links overview

Microsoft – Configure Safe Links policies

Microsoft – Understand Defender URL detection technology

Given the evidence you've collected, I wouldn't disable Safe Links globally. I'd treat the actionable email URL as potentially callable by automated systems and require an explicit second-step confirmation before modifying the Sentinel incident.

Please "Accept the Answer" if this information helped you. This will help us and others in the community.