Defender apaga el botó d'investigar: AIR deixa de disparar-se a mà

La documentació de Microsoft Defender for Endpoint té des de fa setmanes un requadre «Important» de dos paràgrafs. El primer diu que des de l'1 de setembre del 2026 la investigació i resposta automatitzada —AIR— deixa d'executar-se com una experiència d'investigació separada i deixa d'estar disponible per disparar-se a mà. El segon diu què fer al seu lloc: «per a investigacions sota demanda, executa una anàlisi antivirus completa». Aquest dia és demà.

Venem EDR i MDR gestionat, o sigui que ja saps de quin peu coixegem: ens convé que et preocupi qualsevol cosa que passi a la teva consola de seguretat. Així que comencem pel que no ens convé: a la majoria de la gent que llegeixi aquest article, el canvi de demà no li demana fer res. I després anem al que sí, que és més petit i més incòmode del que suggereix el titular.

Seixanta-un dies d'avís, i tot i així

L'avís va sortir pel lloc pel qual surten aquestes coses: el centre de missatges de l'inquilí, amb l'identificador MC1411577, publicat el 2 de juliol del 2026 i actualitzat a finals d'agost. Del dia de publicació a la data d'efecte hi ha seixanta-un dies. La finestra de desplegament que declara el missatge mateix és «principis de setembre del 2026», i l'abast són tots els entorns: núvol mundial, GCC, GCC High i DoD.

Seixanta-un dies són molt d'avís. I tot i així, l'aposta que faríem —i és una aposta, no una dada— és que a la majoria d'empreses de trenta o cinquanta persones ningú no ha llegit aquest missatge. No per deixadesa: el centre de missatges escup desenes d'avisos al mes, gairebé tots irrellevants per a tu, i el que importa va amb la mateixa tipografia que el que anuncia un canvi d'icona. Ja vam escriure sobre això quan un pedaç d'agost va trencar la impressió: el problema rarament és que no avisin; el problema és que avisen de tot pel mateix lloc.

El que es trenca de debò té nom d'endpoint

Hi ha dues maneres de llançar una investigació a mà, i avui totes dues encara funcionen. Una és humana: obrir la llista de dispositius, veure'n un amb nivell de risc alt, obrir el seu panell lateral i prémer Initiate Automated Investigation. L'altra és una crida:

POST https://api.security.microsoft.com/api/machines/{id}/startInvestigation

Aquesta és la peça que cal buscar avui. L'API demana el permís Alert.ReadWrite.All per a aplicacions o Alert.ReadWrite per a credencials d'usuari, el rol d'Active remediation actions, un cos amb un camp Comment obligatori, i retorna 201 Created amb la investigació creada. Està limitada a cinquanta crides per hora. Si algú del teu equip va muntar en el seu dia un flux del tipus «alerta de gravetat alta fora d'horari → llança investigació → avisa per Teams», aquest flux és exactament el que deixa de funcionar.

I aquí hi ha el que és desagradable de l'assumpte: una integració que crida un endpoint que ha deixat de respondre no t'avisa amb una finestra vermella. Retorna un error en un lloc que ningú mira, o pitjor, es queda a mitges sense retornar res, i el runbook continua apareixent a la llista com si funcionés. Nosaltres tractem les nostres pròpies automatitzacions com a serveis de producció justament per això: inventariades, amb responsable i amb finestra d'actualització.

«Executa una anàlisi completa» respon a una altra pregunta

Comencem donant la raó a Microsoft en la part que la té. El requadre diu que les capacitats de detecció i resposta d'AIR «ja estan incloses a la pila de protecció antivirus predeterminada de Microsoft Defender i s'executen automàticament». No tenim cap motiu per dubtar-ho i no insinuarem que avui el teu parc estigui menys protegit que ahir. No ho està.

El que sí que sostenim, i ho marquem com a lectura nostra, és que la substitució declarada no cobreix el cas d'ús que cobria el botó. Una anàlisi antivirus completa mira fitxers en un equip. Una investigació automatitzada, segons descriu la mateixa documentació, fa quatre coses més:

• S'estén sola. Si l'entitat incriminada apareix en un altre equip, la investigació s'amplia a aquell equip i hi arrenca un manual de seguretat. I hi ha un llindar concret: si l'expansió arriba a deu o més dispositius des de la mateixa entitat, aquella ampliació requereix aprovació i apareix a la pestanya d'accions pendents.
• Emet un veredicte per cada evidència, i només tres: maliciós, sospitós o sense amenaces. Una anàlisi no emet veredictes: troba o no troba.
• Converteix el veredicte en accions —posar un fitxer en quarantena, aturar un servei, esborrar una tasca programada— que queden registrades a l'Action center, pendents o fetes, i es poden desfer.
• Penja de l'alerta i de l'incident. No és una tasca solta: és la resposta a alguna cosa concreta que ha passat, amb el seu rastre.

La pregunta que fa el botó és «què està passant en aquest equip i fins on ha arribat?». La pregunta que fa una anàlisi completa és «hi ha fitxers dolents en aquest disc?». Totes dues són preguntes legítimes i no són la mateixa. Quan ets davant d'un equip rar a les onze de la nit —el cas que vam explicar amb el servidor d'impressió que corria com a SYSTEM—, el que necessites saber no és si hi ha un fitxer dolent: és si el que ha passat allà ha passat també en un altre lloc.

A qui no li demana res això

Si no fas servir Defender for Endpoint, això no va amb tu. Si el fas servir i mai no has premut aquell botó —que és el cas de la immensa majoria—, no tens res a fer: la protecció continua corrent. Si ets a Defender for Business, les capacitats d'AIR venen preconfigurades i no són configurables, amb automatització total activada de fàbrica i aplicada a tots els dispositius: no hi ha cap nivell a ajustar i la remediació ja es fa sola. I si ningú de la teva organització no ha escrit mai un script contra l'API de Defender, no hi ha res a buscar.

Dit d'una altra manera: això no és una bretxa, no és un CVE i no cal quedar-se el dissabte. És un canvi de superfície en una eina. Ho escrivim perquè el missatge diu, amb aquestes paraules, que qualsevol playbook, script o integració que iniciï AIR deixarà de funcionar després de l'1 de setembre del 2026.

El rellotge de set dies que sí que hauries de mirar avui

Mentre llegíem aquelles dues pàgines ens vam trobar una altra cosa, que no té a veure amb el botó i ens sembla força més important per a una empresa mitjana. Defender for Endpoint té cinc nivells d'automatització. L'interessant és el segon, Semi — requerir aprovació per a totes les carpetes: amb aquest nivell, cada acció de remediació espera que una persona l'aprovi a l'Action center. I la documentació hi afegeix una frase que convé llegir dues vegades: les accions pendents caduquen als set dies, i si una acció caduca el comportament és el mateix que si s'hagués rebutjat.

Ara el detall que ho converteix en una tasca concreta. Aquell nivell semiautomàtic és el que va quedar per defecte als inquilins creats abans del 16 d'agost del 2020 que mai no van definir grups de dispositius. Els creats a partir d'aquella data, en les mateixes condicions, van quedar en automatització total. És a dir: si el teu tenant és del 2018 o del 2019 i ningú no va tocar mai els grups de dispositius, és probable que Defender porti anys detectant coses, proposant la remediació i esperant un clic que ningú no fa. I als set dies aquella proposta cau sola, amb el mateix efecte que un «no».

Microsoft recomana l'automatització total i aporta el seu número: diu que, amb les dades recollides i analitzades durant l'últim any, els clients en automatització total van tenir un 40 % més de mostres de programari maliciós d'alta confiança eliminades que els clients en nivells inferiors. És una dada del fabricant i la tractem com a tal, però el mecanisme del darrere no necessita fe: si ningú no aprova, no es remedia.

Hi ha un tercer detall a la mateixa pàgina que va en la mateixa direcció: AIR necessita que Microsoft Defender Antivirus estigui en mode actiu o passiu, i si l'antivirus està desactivat o desinstal·lat, AIR no funciona correctament. Sona obvi fins que recordes que hi ha parcs on algú va desinstal·lar Defender Antivirus en posar-hi un altre producte. És el mateix patró que vam explicar quan van apagar un EDR amb un reinici en mode segur: la part que falla gairebé mai és la detecció, és la condició de la qual la detecció depèn i que ningú comprova.

El que l'avís no diu

Dues coses, i les diem perquè hem vist circular totes dues com si fossin fets. La primera: el missatge va de Defender for Endpoint i de la seva experiència dins del portal de Defender XDR. No diu res sobre la investigació automatitzada de Defender for Office 365, i com que no ho diu, nosaltres tampoc no afirmarem què hi passa; si t'afecta, la casella que cal comprovar és aquella i no aquesta pàgina. La segona: el requadre parla de l'experiència d'investigació i de l'activació manual. No diu que desapareguin l'Action center, les accions pendents ni la possibilitat de desfer una remediació.

Un botó no és un procediment

Ens queda la part d'opinió, i és la que ens interessa de debò. Si has sentit alguna cosa en llegir que treuen el botó, val la pena preguntar-se què era exactament el que aquell botó sostenia. Perquè un botó que cal prémer només serveix si hi ha algú mirant la pantalla en el moment en què cal prémer-lo. Un dimarts a les onze del matí n'hi ha. Un divendres a les vuit del vespre, en una empresa de quaranta persones amb un responsable d'IT que també arregla impressores, no.

La diferència entre comprar una eina i comprar un servei és just aquí, i no a la marca de l'agent. L'agent el tens igual. El que canvia és si existeix algú de guàrdia amb un procediment escrit per al moment en què salta l'alerta, o si el teu pla de resposta era, sense haver-ho dit mai en veu alta, «algú veurà l'avís i premerà». Això és exactament el que venem quan venem EDR/MDR gestionat i suport 24x7, i l'argument és interessat i a més ens el creiem: són les dues coses alhora.

Demà no perds capacitat. Perds un lloc on mirar. I si això et preocupa, el problema no l'ha creat Microsoft: feia temps que hi era, tapat per un botó.

El que sí que té data

De tot l'article, una sola cosa caduca aquesta tarda: busca la cadena startInvestigation als teus runbooks, a les teves Logic Apps, als scripts de PowerShell i a qualsevol integració que parli amb l'API de Defender. Si apareix zero vegades, ja has acabat i pots tancar aquesta pestanya. Si apareix, tens fins aquesta nit per decidir què hi poses al lloc.

La resta no té data i pesa més: en quin nivell d'automatització estan els teus grups de dispositius, si l'Action center acumula pendents de fa dies, i si Defender Antivirus continua en mode actiu o passiu als equips on esperes que tot això funcioni. Cap de les tres coses canvia demà. Fa temps que estan com estan.

Fonts (consultades el 31 d'agost del 2026): l'avís literal de retirada, la frase sobre les capacitats ja incloses a la pila antivirus, la recomanació d'executar una anàlisi completa per a investigacions sota demanda, les dues formes d'arrencada d'una investigació (per alerta i manualment amb Initiate Automated Investigation des del panell del dispositiu), l'expansió d'abast amb el llindar de deu o més dispositius, els tres veredictes, els exemples d'accions de remediació i el requisit de Defender Antivirus en mode actiu o passiu surten de «Use automated investigations to investigate and remediate threats» (Microsoft Learn). Els cinc nivells d'automatització, la caducitat de les accions pendents als set dies amb el mateix efecte que un rebuig, els valors per defecte segons si l'inquilí es va crear abans o a partir del 16 d'agost del 2020, el comportament de Defender for Business i la xifra del 40 % més de mostres de programari maliciós d'alta confiança eliminades surten de «Automation levels in automated investigation and remediation» (Microsoft Learn), que reprodueix el mateix requadre de retirada. El mètode, la ruta POST /api/machines/{id}/startInvestigation, el límit de cinquanta crides per hora, els permisos Alert.ReadWrite.All i Alert.ReadWrite, el rol Active remediation actions, el camp Comment obligatori i la resposta 201 Created surten de la referència de l'API Start Investigation. L'identificador MC1411577, la data de publicació del 2 de juliol del 2026 amb una actualització posterior a finals d'agost (el dia exacte varia entre els resums públics que hem pogut consultar), la finestra de desplegament de «principis de setembre del 2026», l'abast a núvol mundial, GCC, GCC High i DoD, i la frase que els fluxos que facin servir AIR deixaran de funcionar després de l'1 de setembre, provenen del text del missatge del centre de missatges de Microsoft 365. Són nostres, i les marquem com a criteri i no com a fets publicats: el càlcul dels seixanta-un dies entre publicació i data d'efecte; la lectura que l'endpoint startInvestigation deixa de respondre demà, perquè la referència de l'API no porta avís de retirada i qui ho diu és el missatge del centre de missatges, no la documentació de l'endpoint; la lectura que una anàlisi antivirus completa respon a una pregunta diferent de la que responia una investigació; la suposició —declarada com a aposta— que a la majoria de pimes ningú no ha llegit l'avís; l'advertiment sobre integracions que fallen en silenci; la lectura que un inquilí anterior a l'agost del 2020 sense grups de dispositius pot portar anys acumulant accions que caduquen soles; i tota la secció final sobre la diferència entre un botó i un procediment.