Notion 3.8 wpuszcza agentów do baz — uprawnienia kolumn stają się zaporą

Notion wydał wersję 3.8 13 października 2026 r. i połączył w niej dostęp zewnętrznych agentów przez MCP z uprawnieniami do kolumn baz danych oraz dokładniejszą historią zmian. Agent może korzystać ze wspólnego kontekstu obszaru roboczego, a także aktualizować dokumenty i rejestry zadań. Dla małej redakcji trzymającej w jednej bazie plan publikacji i informacje o partnerach kluczowe jest to, że dostęp do harmonogramu nie musi oznaczać dostępu do każdej właściwości rekordu.

Połączenie agenta wymaga autoryzacji konta Notion, a zakres jego pracy wynika z praw tego konta. Uprawnienia kolumn pozwalają osobno określić, kto widzi pole, kto odczytuje jego wartość i kto może ją zmieniać. Stają się skuteczną granicą dla stawek i danych partnerów wtedy, gdy użytkownik, który łączy klienta MCP, sam nie ma do tych pól dostępu; polecenie wpisane agentowi nie zastępuje tej reguły.

Jak agent uzyskuje dostęp do Notion

Zewnętrzny klient zgodny z MCP łączy się z serwerem Notion pod adresem mcp.notion.com/mcp. Instrukcja podłączenia Notion MCP opisuje połączenie przez HTTP i logowanie OAuth: użytkownik zatwierdza dostęp do wybranego obszaru roboczego, po czym klient może czytać i aktualizować treści dostępne dla jego konta. Jest to połączenie zewnętrznego narzędzia z Notion; nie należy go mylić z nadawaniem własnych praw wewnętrznemu agentowi utworzonemu w Notion.

Wybór konta ma więc większe znaczenie niż brzmienie zadania. Jeżeli osoba autoryzująca widzi również prywatne wyceny, korespondencję z klientami i wszystkie rekordy partnerów, jej klient MCP może korzystać z tego samego zakresu. Agent poproszony wyłącznie o uzupełnianie terminów publikacji nie dostaje przez samo polecenie technicznego ograniczenia do kolumny z datą. Wspólny kontekst ułatwia zmianę narzędzia AI, lecz jednocześnie wymaga przemyślenia, jakie dane pozostają wspólne.

Dla kalendarza treści sensowny zakres obejmuje temat, etap przygotowania, termin i osobę odpowiedzialną. Kwota umowy, prywatny numer telefonu partnera czy uwagi z negocjacji służą innemu procesowi. To przykładowy podział danych dla redakcji, nie ustawienie włączane automatycznie po podłączeniu MCP. Jeśli te informacje znajdują się w treści strony lub w tytule rekordu, ograniczenie wybranej kolumny ich nie zasłoni.

Kiedy uprawnienia kolumn chronią stawki

Reguły dotyczą właściwości bazy, czyli pól widocznych jako kolumny w tabeli. Według omówienia WorkManagementHub funkcja jest dostępna w planach Business i Enterprise, a osobne reguły można ustawić dla maksymalnie 20 właściwości jednej bazy. To ważny warunek dla małego zespołu: samo połączenie MCP może działać na innych planach, lecz opisanej ochrony poufnych kolumn nie należy tam zakładać.

Właściciel bazy ustawia domyślne prawo do pola i wyjątki dla osób albo grup. Może pozwolić redaktorowi zmienić status tekstu, pozostawiając wartość pola ze stawką niewidoczną; może też ujawnić nazwę kolumny bez jej wartości albo dopuścić odczyt bez edycji. Regułę konfiguruje się w oryginalnej bazie, w widoku tabeli na komputerze lub w przeglądarce. Widok połączony i ukrycie pola w samym układzie kalendarza nie ustanawiają nowego prawa dostępu.

Ochrona pola działa dopiero po sprawdzeniu dostępu do samej strony. Kto nie może otworzyć rekordu, nie otrzyma go dzięki regule kolumny; kto ma pełny dostęp do bazy, zachowuje dostęp do wszystkich jej właściwości. Jeśli kilka wyjątków obejmuje tę samą osobę, obowiązuje najszersze przyznane jej uprawnienie. Dlatego podgląd praw na koncie właściciela może dawać mylący obraz tego, co zobaczy agent połączony przez konto współpracownika.

Są też pola, których nie da się objąć taką regułą, w tym tytuł rekordu, identyfikator i część właściwości systemowych oraz relacji. W kalendarzu publikacji tytuł powinien więc identyfikować materiał, a nie zawierać stawkę lub poufny szczegół umowy. Gdy partnerzy i redakcja mają zasadniczo różne kręgi dostępu, oddzielna baza dla rozliczeń może być prostszą granicą niż wiele wyjątków w jednej tabeli.

Historia zmian pokazuje, co agent zrobił w bazie

Po dopuszczeniu agenta do harmonogramu historia wersji pomaga odróżnić jego edycje od pracy ludzi. Wydanie 3.8 wprowadza wyraźniej oznaczone zmiany na stronach, dokładniejszy zapis zmian w bazach i przypisanie działania jego autorowi. Poprzednią wersję można przywrócić. Przy przesunięciu terminu albo zmianie etapu produkcji taki zapis pozwala ustalić, kto wprowadził korektę i odtworzyć wcześniejszy stan.

Historia dotyczy tego, co zostało zmienione. Nie cofa informacji, którą agent zdążył odczytać, i nie ogranicza uprawnień do kolejnych odczytów. W praktyce najpierw rozstrzyga się dostęp do stron i właściwości, potem autoryzuje klienta MCP, a następnie korzysta z historii do kontroli edycji. Rozdzielenie prawa odczytu od prawa zmiany pomaga także ustalić, czy agent ma jedynie znać plan, czy wolno mu samodzielnie przesuwać terminy.

Połączenia i cofnięcie dostępu

Kontrola połączeń odpowiada na inne pytanie niż historia wersji: które narzędzie może nadal wejść do Notion. Administratorzy planu Enterprise mogą ograniczać listę klientów MCP dopuszczonych do obszaru roboczego. Informacja o aktywnym połączeniu nie jest jednak pełnym dziennikiem działań agenta; zakres szczegółowego wglądu w użycie narzędzi przez poszczególne osoby pozostaje niejednolicie opisany w dokumentacji.

Gdy zewnętrzny agent kończy pracę nad kalendarzem, połączenie można zakończyć w ustawieniach MCP używanego klienta, a następnie sprawdzić uprawnienia konta, którym je autoryzowano. Te działania rozwiązują dwa różne problemy: rozłączenie zamyka drogę narzędzia, a zmiana praw odbiera dostęp do rekordów i pól. Jeżeli współpracownik odchodzi z zespołu, pozostawienie mu prawa do bazy utrzymuje dostęp do danych niezależnie od tego, czy w planie publikacji nadal ma przypisane zadania.

Przeczytaj także:

• OpenAI oddaje agentom komputer — zgody stają się kluczową barierą
• Google Takeout tworzy archiwum, ale nie zachowuje uprawnień do plików
• Notion czy Airtable do treści? Skala ujawnia koszt każdego edytora