Czy agenci Agentforce omijają reguły udostępniania Salesforce?

Każda rozmowa o bezpieczeństwie Agentforce zaczyna się od tego samego pytania: czy agenci omijają nasze reguły udostępniania? Krótka odpowiedź brzmi nie — a zrozumienie dlaczego wyjaśnia zarówno to, dlaczego Agentforce jest bezpieczny z założenia, jak i to, gdzie kryje się prawdziwe ryzyko.

Agenci działają jako użytkownik — i dziedziczą jego dostęp

Agent Agentforce nie ma własnego, magicznego wglądu w Twoje dane. Wykonuje operacje jako użytkownik Salesforce, a każde pobranie danych jest sprawdzane względem przypisanych temu użytkownikowi:

• Uprawnień do obiektów (profil + zestawy uprawnień)
• Zabezpieczeń na poziomie pól
• Udostępniania na poziomie rekordów — domyślne ustawienia obejmujące całą organizację, hierarchia ról, reguły udostępniania, udostępnienia ręczne i niejawne

Jeśli uruchamiający użytkownik nie widzi rekordu, agent również go nie zobaczy. Agentforce działa wewnątrz tego samego korporacyjnego modelu bezpieczeństwa — profile, zestawy uprawnień, udostępnianie, dostęp oparty na rolach — który rządzi resztą Twojej organizacji. Dodatkowo obsługuje nakładane na wierzch zasady oparte na atrybutach, na przykład reguły typu „tylko handlowcy z UE mogą uruchomić ten przepływ pracy”.

Agenci Agentforce nie omijają uprawnień Salesforce. Agresywnie wykorzystują każdy dostęp, który już istnieje.

To drugie zdanie to cała istota sprawy.

Prawdziwe ryzyko: wzmocnione ujawnienie, a nie obejście

I tu pojawia się niewygodna część. Większość organizacji ma znacznie więcej otwartego udostępniania, niż ktokolwiek pamięta, że konfigurował — lata reguł udostępniania, szerokie zestawy uprawnień, kumulacje wynikające z hierarchii ról oraz „tymczasowe” udostępnienia ręczne, które nigdy nie zostały usunięte.

Człowiek niemal nigdy nie natrafia na pełny zakres tego, do czego technicznie ma dostęp. Otwiera rekordy, nad którymi pracuje, a resztę ignoruje. Agent tego nie robi. Zadaj mu pytanie, a pobierze, połączy i podsumuje wszystko w zasięgu uruchamiającego użytkownika — w tym dane, o których ten użytkownik zapomniał, że może je zobaczyć.

Agent nie przyznaje więc nowego dostępu. Wydobywa dostęp, który już miałeś — konwersacyjnie i natychmiast. Zbyt szerokie udostępnianie, które przez lata pozostawało uśpione, jest teraz oddalone o jedno zdanie promptu.

Dlaczego agenci zmieniają rachunek ryzyka

Dwie rzeczy odróżniają to od osoby z tymi samymi uprawnieniami:

1. Szybkość i skala. Agent odczytuje i łączy rekordy znacznie szybciej niż jakikolwiek człowiek, więc źle dobrane uprawnienie jest wykorzystywane natychmiast i wielokrotnie.
2. Brak punktu zatwierdzenia. Po wdrożeniu agenci działają na podstawie konfiguracji i kontekstu, nie zatrzymując się na ludzką weryfikację — usuwając punkt kontrolny, na którym po cichu opierał się tradycyjny model bezpieczeństwa.

Model uprawnień nie stał się słabszy. To, co go używa, stało się znacznie bardziej skrupulatne.

Co zrobić przed wdrożeniem

Rozwiązaniem nie jest brak zaufania do Agentforce — jest nim wiedza o tym, co widzi jego użytkownik, zanim go włączysz:

1. Przeprowadź przegląd dostępu dla uruchamiającego agenta użytkownika — na poziomie obiektów i rekordów. Istotne pytanie jest tym samym, o którym jest cały ten blog: kto co widzi i dlaczego. Krok po kroku opisuje to audyt dostępu do rekordów przed wdrożeniem agenta AI.
2. Zaostrz punkt wyjścia. Ustaw domyślne ustawienia obejmujące całą organizację tak restrykcyjnie, jak pozwala na to biznes; dostęp od tego momentu można tylko poszerzać.
3. Przejrzyj i ogranicz reguły udostępniania oraz zestawy uprawnień. Usuń szerokie, nieaktualne nadania, które agent w przeciwnym razie odziedziczyłby.
4. Nadaj agentowi własną tożsamość o najmniejszych przywilejach zamiast szerokiego profilu ludzkiego, wraz z zasadami opartymi na atrybutach.
5. Sprawdzaj ponownie po każdej zmianie udostępniania — dostęp dryfuje, a wraz z nim to, do czego agent może sięgnąć.

Wiedza o tym, co widzi agent — w prostym języku

Kroki 1 i 5 są tymi trudnymi: zrekonstruowanie rzeczywistego efektywnego dostępu użytkownika w zakresie CRUD, zabezpieczeń na poziomie pól i sześciu mechanizmów udostępniania, a następnie utrzymywanie tego na bieżąco w miarę zmian w organizacji.

I właśnie to robi AgentForceAccess. Zapytaj prostym językiem, co dany użytkownik — lub uruchamiający Twojego agenta użytkownik — faktycznie widzi, a narzędzie prześledzi każde nadanie i wskaże stojący za nim mechanizm. To przegląd dostępu, który zamienia „myślimy, że agent ma poprawny zakres” w „wiemy, że tak jest” — jeszcze przed wdrożeniem.

Najczęściej zadawane pytania

Czy agenci Agentforce ignorują reguły udostępniania i działają jako administrator?

Nie. Agent wykonuje operacje jako konkretny użytkownik Salesforce i jest ograniczony jego profilem, zestawami uprawnień, zabezpieczeniami na poziomie pól oraz modelem udostępniania rekordów. Nie może zobaczyć rekordów, których ten użytkownik nie mógłby zobaczyć. Jeśli jednak uruchamiający użytkownik ma nadmierne uprawnienia, agent dziedziczy tę nadmiarowość.

Skoro respektuje uprawnienia, to dlaczego dostęp AI uznaje się za zagrożenie bezpieczeństwa?

Ponieważ większość organizacji nagromadziła więcej otwartego udostępniania, niż ktokolwiek zdaje sobie sprawę. Człowiek rzadko natrafia na każdy rekord, do którego technicznie ma dostęp; agent na żądanie chętnie je pobierze i podsumuje. Agent nie tworzy nowego dostępu — ujawnia ten, który już miałeś.

Co jest najważniejszą rzeczą do zrobienia przed wdrożeniem agenta?

Zaudytuj to, co uruchamiający agenta użytkownik faktycznie widzi — obiekt po obiekcie i na poziomie rekordów. Zaostrz domyślne ustawienia obejmujące całą organizację, reguły udostępniania i zestawy uprawnień tak, aby użytkownik (a więc i agent) miał tylko niezbędny dostęp, a następnie wdrażaj.

Czy mogę nadać agentowi węższy dostęp niż użytkownikowi, który go uruchamia?

Tak. Zamiast wykorzystywać szeroki profil ludzki, udostępnij dla agenta dedykowanego użytkownika lub konfigurację zestawu uprawnień o najmniejszych przywilejach i nałóż na to zasady oparte na atrybutach. Agent powinien mieć minimalny dostęp wymagany do swojego zadania.