Email Security Scanner Clicks AI Agent Approval Links

Your email security scanner may be approving actions for your AI agent. When fetching links in messages, the scanner performs a GET request that resembles a human click. If approval occurs during this GET request, a machine has implicitly granted permission. The solution is to require a POST request from a confirmation page, which the scanner cannot submit.

Imagine an agent requesting approval via email; each row in the approval log represents a link, all marked as approved. The timestamps in the log align with delivery, indicating accurate recording of URL requests. However, the log lacks columns for the requester and whether a human ever read the message. So, why does the scanner click approval links?

Email gateways fetch URLs to assess safety, whether or not the message is opened. The scanner is thorough in its checks, regardless of the agent. As documented by Microsoft in Defender for Office 365, Safe Links can scan URLs in messages before and during clicks. Microsoft Learn also notes a reporting cmdlet, Get-SafeLinksDetailReport, which records actions like ClickedDuringScan for users who clicked while a scan was ongoing.

The primary source for this fix is RFC 8058, which specifies one-click unsubscribe as an HTTPS POST to prevent anti-spam software from distinguishing automated requests from human actions. Identity vendors echo this failure. Stytch's consumer documentation states each magic link is one-time use, consumed by a real login, while its B2B guide explicitly notes scanners can consume tokens before the email reaches the inbox.

Supabase users have reported scanners frequently consuming tokens in enterprise, university, and hospital environments, rendering the token invalid before the user clicks. This issue extends beyond authentication vendors. An approval link is a token granting consent, and a scanner consuming it has seemingly approved on your behalf.

Does a scanner's click equate to human approval? If the approval is a GET request, yes. The server cannot differentiate between the scanner and human, so the scanner's click is recorded as consent. It might seem tempting to view this as a bot-detection issue, but the core problem lies in approval not being contingent on identifying the requester.

Stytch's consumer overview confirms that clicks by email security scanners are not treated as authentication attempts, ensuring the token remains unconsumed and no session is granted. However, an agent platform writing its own approval endpoint does not automatically receive this behavior. Simply filtering out scanner clicks is ineffective due to the evolving landscape of non-human clicks.

Bot detection shares have increased from 33.8% in 2025 to around 48% in the first half of 2026, with Gmail bot-clicks jumping to about 22% in late 2025. User-agent blocklists quickly become obsolete, and timing filters often reject legitimate human clicks. Expiry times offer no protection, as scanners arrive swiftly and tokens are exhausted before the human opens the inbox.

Therefore, approval must take a different form. The GET handler should only render a confirmation page and alter no state, while the POST handler performs the action with a valid, unused nonce. Implementing an authenticated approver, requiring a login session prior to rendering the page, and binding the nonce to the intended recipient are essential.

Adding CSRF protection to the form is equally crucial. Without these measures, email forwards and scanners can approve actions indiscriminately, rendering the approval log meaningless.