Ein After-Read-Trigger kann theoretisch den Inhalt des übergebenen Puffers mit Defaults überschreiben und somit bestimmte Feldinhalte verbergen.
Bedenke aber, dass dann beim Schreiben (Update) auch die veränderten Inhalte dann geschrieben würden, da das Programm ja nichts von der Veränderung weiß.
Du kannst damit ganz schnell ganz viele Daten zerhauen.
Wenn ein Datensatz gar nicht erst gelesen werden darf, so kannst du das nur mit einer ESC-Nachricht (Message-API) verhindern.
Das lesende Programm bekommt dann eine Ausnahme gemeldet, so dass dieses zum Programmabbruch führt (Ausnahme mit Monitor abfangen).

Auch dies führt hier nicht zum gewünschten Effekt.
Ein READE würde dann nämlich immer auf den selben Satz kommen.

Eine Dateninhaltsberechtigung kannst do so leider nicht lösen. Dies musst du per Design in der Anwendung klären.

Ein Read-Trigger macht nur dann Sinn, wenn bestimmte Feldinhalte übersetzt werden müssen, da sich z.B. Defaults o.ä. geändert haben.
Andererseits würde ich das dann eher mit einem SQL-Update einmalig durchführen.

Wofür man eine Read-Trigger wirklich braucht?
Ggf. um zu protokollieren, welche daten von wem gelesen wurden. Ansonsten wüsste ich nicht, wozu das wirklich gut ist.
Aber vielleicht weiß Birgitta da mehr .