Blog Mejlo

Podłączyłem AI do tenanta Microsoft 365. Co zadziałało, a co nie

Kamil Milewski
Robot przy trzech monitorach konfiguruje Microsoft 365, a obok na leżaku z drinkiem odpoczywa mężczyzna w kraciastej koszuli i zatwierdza jego pracę zielonym przyciskiem

Jeśli oglądasz moją serię „Agent w tenancie”, to widziałeś, jak mówię do agenta AI zwykłym zdaniem. On w tym czasie zakłada grupy, szuka oversharingu w SharePoincie i sprawdza, kto nie ma wymuszonego MFA. Wygląda to jak magia. Tak naprawdę za każdym takim filmem stoi konfiguracja, kilka błędów i parę rzeczy, które po prostu nie zadziałały.

Ten wpis jest o tym, co dzieje się za kulisami. Bez marketingu, z granicami, bo te są dla Ciebie najważniejsze, jeśli kiedyś będziesz chciał dać AI dostęp do swojego Microsoft 365.

Czy AI może zarządzać Microsoft 365 za Ciebie?

Częściowo tak. W moim teście agent dobrze sobie radził z odczytem tenanta, z grupami Microsoft 365 i z poleceniami dla Teams. Nie poradził sobie przez MCP z Intune ani z Activity Explorer w Purview. Tam, gdzie nie miał narzędzia, potrafił otworzyć portal w przeglądarce i klikać sam. O tym za chwilę, bo to akurat rzecz, którą dziś bym wyłączył.

Najważniejszy wniosek jest prosty: AI upraszcza rozmowę z tenantem, ale nie zwalnia z rozumienia uprawnień i granic usług. Ktoś dalej musi wiedzieć, co agent może, a czego nie powinien.

Jak to było zbudowane, po ludzku

Agentem był GitHub Copilot w Visual Studio Code, w trybie Agent. W filmach nazywam go Agentostratorem. Sam z siebie Copilot niczego w tenancie nie widzi. Podłączyłem mu dwa serwery MCP, czyli dwa „kable” do Microsoft 365, każdy z inną rolą:

  • oficjalny Microsoft MCP Server for Enterprise tylko czyta, nic nie zmienia i służył mi do sprawdzania wyników,
  • CLI for Microsoft 365 MCP Server wykonuje zmiany, czyli zakłada, ustawia i usuwa.

Ten podział był najlepszą decyzją całego projektu. To trochę jak w księgowości, gdzie jedna osoba płaci przelew, a druga go zatwierdza. Jeden serwer coś zmienia, drugi niezależnie sprawdza, czy zmiana naprawdę się wydarzyła.

Serwery dostały jednoznaczne nazwy: jeden do odczytu, drugi do zapisu. W poleceniach wskazywałem, którego agent ma użyć, a w testach, które miały coś udowodnić, drugi po prostu wyłączałem. Dzięki temu zawsze wiedziałem, co faktycznie zadziałało.

Pierwszy sukces: grupa założona i sprawdzona przez kogoś innego

Pierwszy prawdziwy test wyglądał tak. Poprosiłem o grupę Microsoft 365 o nazwie MCP-DEMO-Marketing.

  1. Serwer od zapisu najpierw sprawdził, czy taka grupa już nie istnieje.
  2. Założył prywatną grupę.
  3. Oficjalny serwer Microsoftu niezależnie odczytał nowy obiekt i potwierdził identyfikator, adres, widoczność i godzinę utworzenia.

Najbardziej spodobało mi się to, że przy każdym kroku widziałem, jakiego serwera i jakiego narzędzia agent użył oraz jaką dokładnie komendę albo zapytanie wysłał. Nie było „zrobione, zaufaj mi”. Było „zrobiłem to tą komendą, a tu masz dowód z drugiego źródła”.

Błąd, który nauczył mnie najwięcej

Serwer od zapisu pokazywał status „Running”. Znane polecenia wykonywał bez problemu. A mimo to nie umiał wyszukać komend dla Teams. Jedna z jego funkcji wymagała programu zainstalowanego globalnie na komputerze, a ja trzymałem wszystko w folderze projektu. Pomogła instalacja globalna i dopisanie jej ścieżki do konfiguracji.

Lekcja jest szersza niż ten jeden przypadek. Zielona kontrolka nie znaczy, że wszystko działa. Dopóki nie sprawdzisz konkretnego zadania od początku do końca, „Running” mówi tylko tyle, że proces się uruchomił.

Gdzie się skończyło

Tu jest część, którą uważam za najważniejszą w całym wpisie.

Intune. Odczyt zgodności urządzeń przez oficjalny serwer zwrócił błąd 403, czyli brak uprawnień. Zakresy tego serwera po prostu nie obejmowały tego, czego Intune wymaga. Przez MCP ten scenariusz nie został wdrożony.

Purview i Activity Explorer. Wybrane serwery nie mają do tego odpowiedniego narzędzia. Ten scenariusz też został poza projektem.

Global Administrator to nie wszystko. Byłem zalogowany jako administrator globalny, a i tak dostawałem odmowy. Uprawnienia aplikacji, przez którą działa agent, to osobna sprawa od Twojej roli w tenancie. Najwyższa rola nie załata brakującego uprawnienia aplikacji ani brakującej funkcji narzędzia.

Uczciwie o filmach

W filmach z serii są momenty, kiedy agent otwiera portal Intune albo Purview w przeglądarce i klika sam. Polityka zgodności w Intune z jednego z odcinków powstała właśnie tak, kliknięciami w portalu, a nie przez MCP.

Wygląda to efektownie, ale to nie jest wykonanie przez serwer MCP. To obejście, które Copilot wybiera sam, kiedy brakuje mu narzędzia. Działa na Twojej zalogowanej sesji, z Twoimi uprawnieniami, i trudniej je potem prześledzić niż konkretną komendę. Dziś w teście, w którym chcę wiedzieć, co dokładnie się wydarzyło, wyłączyłbym je i kazał agentowi zatrzymać się z informacją o błędzie.

Sześć zasad, zanim podłączysz AI do swojego tenanta

Jeśli kiedyś Ty albo Twój admin będziecie chcieli spróbować, to są zasady, które wyniosłem z tego labu:

  1. Rozdziel odczyt od zapisu. Jeden kanał do sprawdzania, drugi do zmian, i każda zmiana potwierdzona z drugiego źródła.
  2. Wskazuj w poleceniu, którego narzędzia agent ma użyć. Niejasne polecenie daje niejasny wynik, co pokazałem w jednym z filmów.
  3. Zatwierdzaj każdą zmianę osobno. Nie dawaj zgody z góry na wszystkie przyszłe operacje zapisu.
  4. Przed zmianą proś o plan wycofania. Jeśli agent nie umie powiedzieć, jak cofnąć zmianę, nie pozwalaj mu jej robić.
  5. Zakaż cichego obchodzenia. Gdy coś się nie uda, agent ma pokazać serwer, narzędzie, dokładny błąd i brakujące uprawnienie. Potem czeka na Twoją decyzję, zamiast otwierać portal na własną rękę.
  6. Testuj na tenancie testowym. Wszystko, co opisuję, robiłem na osobnym tenancie testowym, nie na firmowym.

Czego jeszcze nie zrobiłem

Dwie rzeczy były omawiane, ale nie zostały skonfigurowane, więc traktuj je wyłącznie jako możliwy dalszy krok. Pierwsza to Lokka, kolejny serwer MCP do szerszych operacji przez Microsoft Graph, między innymi pod Intune. Druga to Microsoft365DSC do robienia zdjęć konfiguracji przed zmianą i po niej oraz do wyłapywania, kiedy ktoś coś przestawił bez wiedzy reszty.

Czy to jest coś dla Twojej firmy?

Jeśli masz Microsoft 365, a nie masz admina albo Twój admin tonie w zgłoszeniach, to agent podpięty do tenanta może kiedyś realnie pomóc. Ale nie zaczynałbym od podłączania AI do firmowego tenanta. Zacząłbym od sprawdzenia, czy podstawy bezpieczeństwa są na miejscu, bo agent czyta i zmienia dokładnie to, do czego dostanie dostęp.

Na początek możesz przejść moją bezpłatną checklistę bezpieczeństwa Microsoft 365. A jeśli chcesz pomocy w zarządzaniu tenantem, z AI albo bez, napisz do mnie. Obejrzymy Twój Microsoft 365 i powiem wprost, co jest pilne, a co spokojnie może poczekać.

Dla Twojego admina: konfiguracja w skrócie

Ta sekcja jest dla osoby, która będzie to stawiać. Środowisko z labu:

  • Visual Studio Code z GitHub Copilot Chat w trybie Agent,
  • Node.js v26.10.0 i npm v11.19.1,
  • CLI for Microsoft 365 v11.11.0 i CLI for Microsoft 365 MCP Server v0.1.24,
  • Microsoft.Entra.Beta v1.3.0 i Microsoft.Graph.Authentication v2.41.0, zapisane lokalnie w projekcie,
  • Microsoft MCP Server for Enterprise jako zdalny serwer HTTP,
  • testowy tenant Microsoft 365 i konto Global Administrator.

Najważniejsze kroki:

  1. m365 setup utworzył osobną aplikację Entra dla CLI. Po setupie trzeba było wylogować tymczasową sesję Azure CLI i zalogować się ponownie przez nową aplikację.
  2. Ustawienia CLI pod MCP: output text, helpMode full, printErrorsAsPlainText true.
  3. Provisioning serwera Enterprise: Connect-Entra zwracał błąd ContextScope, więc zadziałał bezpośredni Connect-MgGraph z zakresami Application.ReadWrite.All, Directory.Read.All i DelegatedPermissionGrant.ReadWrite.All, a potem Grant-EntraBetaMcpServerPermission -ApplicationName VisualStudioCode.
  4. Konfiguracja w .vscode/mcp.json. Plik w .github/mcp.json nie był rozpoznawany jako aktywna konfiguracja.
  5. CLI for Microsoft 365 musi być dostępne globalnie, inaczej m365_search_commands nie znajduje katalogu komend. Wymaga tego też README projektu.

Końcowy mcp.json. Ścieżkę użytkownika zastąpiłem przykładem, a adres serwera Enterprise znajdziesz w dokumentacji Microsoftu podlinkowanej w źródłach, bo to punkt usługi do logowania, a nie strona do kliknięcia:

{
  "servers": {
    "ms-enterprise-read": {
      "type": "http",
      "url": "<adres Enterprise MCP z dokumentacji Microsoft, sekcja Connect your MCP client>"
    },
    "m365-cli-write": {
      "type": "stdio",
      "command": "npx",
      "args": ["--no-install", "@pnp/cli-microsoft365-mcp-server"],
      "cwd": "${workspaceFolder}",
      "env": {
        "PATH": "C:\\Users\\<user>\\AppData\\Roaming\\npm;${workspaceFolder}\\node_modules\\.bin;${env:PATH}"
      }
    }
  }
}

Najsilniejszy wzorzec z tego labu: zapis przez CLI MCP, odczyt i potwierdzenie przez Enterprise MCP.

Źródła

← Wszystkie wpisy