Audyt dostępu do rekordów przed wdrożeniem agenta AI

Najbezpieczniejszy moment, by odkryć, że Twój agent AI może odczytać każdy rekord wynagrodzenia w organizacji, jest przed jego wdrożeniem — a nie wtedy, gdy użytkownik o to poprosi. Ponieważ agent Agentforce dziedziczy dostęp użytkownika, w którego kontekście działa, włączenie go to w istocie decyzja o ujawnieniu — konwersacyjnie i z prędkością maszyny — wszystkiego, co ten użytkownik widzi. Ten plan najpierw audytuje ten dostęp.

Dlaczego ten audyt znaczy więcej dla agentów niż dla ludzi

Człowiek rzadko natrafia na pełny zakres swojego dostępu — otwiera rekordy, nad którymi pracuje, a resztę ignoruje. Agent nie. Zadaj mu pytanie, a pobierze, połączy i podsumuje wszystko w zasięgu. Agent nie tworzy żadnego nowego dostępu; on ujawnia dostęp, który już istnieje — w tym ten, o którym wszyscy zapomnieli.

Audyt nie dotyczy więc AI. Chodzi o odpowiedź na jedno stare pytanie z nową pilnością: co ten użytkownik faktycznie widzi?

Krok 1 — Ustal tożsamość, w której działa agent

Określ dokładnie, jako który użytkownik (lub w jakiej konfiguracji użytkownika) wykonuje się agent. Wszystko, co agent może odczytać, definiują uprawnienia i udostępnienia tej tożsamości. Jeśli wykorzystuje szeroki profil człowieka, to już jest odkrycie numer jeden — zobacz Krok 5.

Krok 2 — Audytuj dostęp na poziomie obiektu

Dla tej tożsamości przejrzyj uprawnienia do obiektów wynikające z jej profilu i permission sets:

• CRUD — które obiekty może odczytywać (Read) / tworzyć (Create) / edytować (Edit) / usuwać (Delete)?
• Field-level security — które wrażliwe pola są widoczne?
• View All / Modify All — każde z nich na obiekcie (lub “View All Data”) całkowicie omija model udostępniania i jest najwyższym priorytetem do wykrycia.

Dostęp do obiektu to brama; jeśli agent nie ma powodu, by odczytywać dany obiekt, napraw to tutaj, zanim zaczniesz się martwić o rekordy.

Krok 3 — Audytuj dostęp na poziomie rekordu

Dla obiektów, które może odczytywać, ustal, które rekordy widzi, w obrębie każdego mechanizmu udostępniania:

• Org-wide defaults — czy poziom bazowy to Private czy Public? Publiczny OWD oznacza, że agent widzi każdy rekord tego obiektu.
• Hierarchia ról — czy tożsamość znajduje się wysoko w hierarchii, dziedzicząc dostęp po wszystkich poniżej?
• Reguły udostępniania — które reguły oparte na właścicielu i na kryteriach ją obejmują?
• Udostępnienia ręczne — czy są jakieś jednorazowe nadania?
• Udostępnianie niejawne — dostęp do kont pociągający za sobą rekordy podrzędne, warstwa, o której audyty zapominają.

Wynik, którego potrzebujesz: oto faktyczny zbiór rekordów, które ten agent może odczytać, oraz mechanizm stojący za każdym z nich.

Krok 4 — Wytrop zbyt szeroki i przeterminowany dostęp

Mając pełen obraz, szukaj nadań, których nie powinno tam być:

• OWD Public Read, które powinno być Private.
• Reguły udostępniania oparte na kryteriach pasujące do znacznie większej liczby rekordów niż zamierzono.
• Permission sets z włączonym “View All” pozostawionym po dawnym projekcie.
• Udostępnienia ręczne, które miały być tymczasowe.

Każde z nich to coś, co agent inaczej by ujawnił. Usuń je.

Krok 5 — Daj agentowi najmniejsze uprawnienia

Nie wykorzystuj szerokiego profilu człowieka. Utwórz dedykowaną tożsamość o najmniejszych uprawnieniach, ograniczoną do zadania agenta, i nałóż na nią polityki oparte na atrybutach, by uzyskać precyzyjne reguły. Agent powinien mieć minimalny wymagany dostęp — nic odziedziczonego przez przypadek.

Krok 6 — Powtarzaj audyt przy każdej zmianie

Faktyczny dostęp dryfuje: nowa reguła udostępniania, przeniesienie roli, drobna zmiana w permission set — i zasięg agenta po cichu się rozszerza. Powtórz audyt po każdej zmianie w udostępnianiu, a niezależnie od tego również regularnie. “Poprawnie ograniczony w momencie startu” to nie to samo co “poprawnie ograniczony dzisiaj.”

Jak zamienić wielodniowy audyt w jedno pytanie

Kroki 2–6 to najtrudniejsza część: zrekonstruowanie prawdziwego faktycznego dostępu użytkownika w obrębie CRUD, field-level security i sześciu mechanizmów udostępniania — a następnie utrzymanie go na bieżąco. Ręcznie to dni pracy, w której łatwo o pomyłkę.

AgentForceAccess jest stworzony właśnie do tego. Zapytaj prostym językiem, co faktycznie widzi użytkownik działającego agenta, a narzędzie prześledzi każde nadanie — uprawnienie do obiektu, regułę udostępniania, udostępnienie ręczne lub niejawne — i wskaże mechanizm. Zamienia “wydaje nam się, że agent jest dobrze ograniczony” w “wiemy, że jest”, przed wdrożeniem i po każdej zmianie.

Najczęściej zadawane pytania

Po co w ogóle audytować dostęp przed wdrożeniem agenta?

Bo agent ujawni wszystko, do czego sięga jego użytkownik — natychmiast i na żądanie. Większość organizacji ma bardziej otwarte udostępnianie, niż ktokolwiek pamięta, więc audyt wykrywa ten ukryty dostęp, który agent inaczej by ujawnił — zanim to zrobi.

Co tak naprawdę powinien obejmować audyt?

Dwie warstwy. Poziom obiektu: uprawnienia CRUD i field-level security użytkownika działającego agenta, pochodzące z jego profilu i permission sets. Poziom rekordu: które konkretne rekordy widzi poprzez org-wide defaults, hierarchię ról, reguły udostępniania, udostępnienia ręczne i niejawne.

Czy agent powinien korzystać z konta prawdziwego pracownika?

Nie. Utwórz dedykowaną tożsamość o najmniejszych uprawnieniach, ograniczoną do zadania agenta, zamiast wykorzystywać szeroki profil człowieka. Agent powinien mieć minimalny potrzebny dostęp i nic odziedziczonego przez przypadek.

Jak często powtarzać audyt?

Po każdej zmianie org-wide defaults, reguł udostępniania, hierarchii ról, profili lub permission sets — a niezależnie od tego również regularnie. Faktyczny dostęp z czasem się zmienia, a wraz z nim zmienia się zasięg agenta.