The exception occurs whenever any user with read-only permissions uses FADB2 "REDIT" command when browsing relationships. From the main menu of FADB2, select 1. Browse and enter the table name. Then enter a primary key value of the data you want in the Where section of the screen. After the data for that row appears, the read only user type "re" or "redit" in order to view the related records. The data requested returns without error, but our database activity monitoring tool captures exceptions for failed insert, update, and delete for the record under review which is never shown to the user. The monitoring tool captures '' (empty space) for each column in the DML.

1) Why does it try to write something to the tables when merely browsing in REDIT?
2) Is there a way to prevent it from making these fake writes when the user does not have write permissions or is this expected?

In the EDIT(REDIT) function, before displaying EDIT data screen, our product internally builds dummy DELETE, INSERT, UPDATE statements for the target object and issues  EXEC SQL PREPARE  for the statements, to know what access the user has for the target. There is no actual data updates in this authorization check process. 

There is BYPASS_INITIAL_AUTHORITY_CHECK parameter in FAFD00 (00 is default) PARMLIB member.
It's YES/NO type parameter and NO is default. YES is to bypass the authorization check and the user will rely on Db2 authority when performing an UPDATE, INSERT or DELETE.