Copilot Studio: 10 błędnych konfiguracji i wykrywanie

Wprowadzenie: dlaczego to ma znaczenie

Agenci szybko stają się nową płaszczyzną sterowania dla dostępu do danych i automatyzacji przepływów pracy — często tworzeni i wdrażani w krótkim czasie przy użyciu narzędzi low-code, takich jak Copilot Studio. Microsoft ostrzega, że drobne wybory konfiguracyjne (szerokie udostępnianie, niebezpieczne akcje, słabe uwierzytelnianie, nieaktualne przypisanie właściciela) mogą tworzyć ścieżki tożsamości i dostępu do danych, których tradycyjne mechanizmy bezpieczeństwa mogą nie monitorować. Efekt: błędnie skonfigurowani agenci mogą po cichu zwiększać powierzchnię ataku i umożliwiać nadużycia sterowane promptami lub eksfiltrację danych.

Co nowego: 10 typowych błędnych konfiguracji agentów (i jak je wykrywać)

Microsoft opisuje dziesięć błędnych konfiguracji „spotykanych w praktyce” i mapuje każdą z nich na Defender Advanced Hunting Community Queries (Security portal → Advanced hunting → Queries → Community Queries → folder AI Agent) oraz rekomendowane działania naprawcze w Copilot Studio/Power Platform.

Kluczowe motywy obejmują:

1) Nadmierne udostępnianie i słabe granice dostępu

• Ryzyko: Agenci udostępniani całej organizacji lub szerokim grupom.
• Wykrywanie: Zapytania takie jak AI Agents – Organization or Multitenant Shared.
• Ograniczanie ryzyka: Używaj Managed Environments i agent sharing limits; weryfikuj strategię środowisk i zakres udostępniania.

2) Brakujące lub niespójne uwierzytelnianie

• Ryzyko: Agenci, którzy nie wymagają uwierzytelniania, stają się publicznym punktem wejścia.
• Wykrywanie: AI Agents – No Authentication Required.
• Ograniczanie ryzyka: Wymuszaj agent authentication at the environment level (uwierzytelnianie jest domyślnie włączone — nie luzuj go do testów bez zabezpieczeń).

3) Ryzykowne akcje, konektory i ścieżki eksfiltracji

• Ryzyko: Akcje HTTP Request z niebezpiecznymi ustawieniami (bez HTTPS, niestandardowe porty) lub akcje e-mail umożliwiające eksfiltrację danych.
• Wykrywanie: Zapytania obejmujące wzorce żądań HTTP oraz e-mail do podmiotów zewnętrznych/wejścia kontrolowane przez AI.
• Ograniczanie ryzyka: Stosuj Data Policies / Advanced Connector Policies oraz rozważ Microsoft Defender Real-time Protection i kontrolę akcji konektorów.

4) Dryf ładu: uśpieni, osieroceni i nadmiernie uprzywilejowani agenci

• Ryzyko: Uśpieni agenci/połączenia, uwierzytelnianie autora (maker), osieroceni agenci z wyłączonymi właścicielami, zakodowane na stałe poświadczenia.
• Wykrywanie: Zapytania dla uśpionych/niemodyfikowanych agentów, author auth, hardcoded credentials, orphaned owners.
• Ograniczanie ryzyka: Regularnie przeglądaj inwentarz, ograniczaj poświadczenia maker, przechowuj sekrety w Azure Key Vault przez zmienne środowiskowe oraz izoluj/wycofuj nieaktualne agenty.

5) Nowe narzędzia i ryzyka orkiestracji

• Ryzyko: Narzędzia MCP i generatywna orkiestracja bez jasnych instrukcji (dryf zachowania/nadużycia promptów).
• Wykrywanie: Skonfigurowane MCP oraz orkiestracja bez instrukcji.
• Ograniczanie ryzyka: Ograniczaj narzędzia MCP przez polityki; polegaj na wbudowanych zabezpieczeniach (np. Azure Prompt Shield/RAI controls) i publikuj z jasnymi instrukcjami.

Znaczenie dla administratorów IT i zespołów bezpieczeństwa

• Spodziewaj się, że agenci wprowadzą nietradycyjne ścieżki dostępu (konektory, narzędzia MCP, akcje e-mail), które mogą omijać starsze mechanizmy monitorowania.
• Tempo low-code zwiększa prawdopodobieństwo błędnej konfiguracji na dużą skalę, zwłaszcza w wielu środowiskach Power Platform.
• Problemy ładu (własność, uśpienie, poświadczenia maker) mogą tworzyć trwałe, trudne do zauważenia ryzyko.

Rekomendowane kolejne kroki

1. Uruchom AI Agent Community Queries w Defender Advanced Hunting i ustal bazę wyników dla każdego środowiska.
2. Wymuś uwierzytelnianie na poziomie środowiska i przejrzyj wszelkie wyjątki.
3. Wdróż/zweryfikuj Managed Environments, sharing limits oraz Data/Connector policies.
4. Sprawdź author authentication, hardcoded secrets oraz orphaned/dormant agents; napraw i wycofaj tam, gdzie to właściwe.
5. Udokumentuj wytyczne bezpiecznego tworzenia dla maker (dobre praktyki HTTP, obsługa sekretów, jakość instrukcji) i dodaj je do wewnętrznego onboardingu.