Użytkownik Ela miał nadane uprawnienia SELECT, INSERT, UPDATE i DELETE do tabeli tab1 w bazie baza1. Po wydaniu polecenia SQL prezentowanego w ramce użytkownik Ela będzie mógł
REVOKE INSERT, UPDATE, DELETE ON baza1.tab1 FROM 'Ela'@'localhost';
Polecenie REVOKE odbiera uprawnienia nadane wcześniej poleceniem GRANT. Ela miała cztery prawa do danych tabeli tab1, a polecenie zabiera jej trzy z nich: INSERT, UPDATE i DELETE. Zostaje tylko SELECT, czyli odczytywanie danych - Ela może wykonywać zapytania wyszukujące, ale nie doda, nie zmieni ani nie usunie żadnego rekordu. Składnia jest lustrzana wobec nadawania: w GRANT po nazwie obiektu stoi TO, a w REVOKE - FROM. Bieżące uprawnienia konta sprawdza się poleceniem SHOW GRANTS FOR 'Ela'@'localhost'. Do zapamiętania: GRANT dodaje prawa, REVOKE je odbiera. Zmiana działa przy kolejnym zapytaniu Eli. Prawa można później przywrócić poleceniem GRANT.
Każdy z błędnych wyborów pomija któryś szczegół polecenia. Pełne prawa do danych Ela miała przed wydaniem polecenia, ale REVOKE zabrało jej trzy z nich, więc nie może już wykonywać wszystkich akcji. Odpowiedź z dodawaniem, modyfikowaniem i usuwaniem wskazuje dokładnie te uprawnienia, które zostały odebrane, zamiast tego, które zostało. Tworzenie i modyfikacja struktury wymagałyby uprawnień CREATE i ALTER, których Ela nie miała ani przed, ani po zmianie. Wystarczy odjąć od listy nadanych praw te wymienione w REVOKE: z SELECT, INSERT, UPDATE i DELETE zostaje samo SELECT, czyli odczyt danych. Taki zabieg stosuje się w praktyce, gdy pracownik ma tylko przeglądać dane, np. sporządzać zestawienia, a nie powinien ich zmieniać. Odbieranie uprawnień zgodnie z zasadą najmniejszych przywilejów ogranicza skutki pomyłek i włamań.