Why do you want to block CL through iNav? Do your users have sufficient authority to adversely affect things by running commands? If they do, then the system security is insufficient. Remove authority that shouldn't exist and you won't have to worry about all of the ways that users can run commands.
'Run SQL scripts' is not the most likely way commands will be run through iNav. It's easier just to right-click the connection and select 'Run command'. You don't even need iNav at all. You can do it from a Windows command line with RMTCMD. And if you don't have iSeries Access, you can do it with the Windows REXEC command.
There are a variety of ways to run commands remotely. You can restrict CL commands in iNav 'Run SQL scripts' and still be able to run commands through 'Run SQL scripts'. (E.g., call QCMDEXC as a stored proc.)
The point is that you are looking for a way to patch a tiny hole that is only one of many holes. What you should be doing is fixing the authority on your system. It's a waste of time trying to find and close all of the many ways of accessing the authority that shouldn't exist in the first place.
However, if you specifically want only to control 'Run SQL scripts', you can code exit programming against the QIBM_QZDA_SQL2 (or perhaps QIBM_QZDA_SQL1) exit point.
I recommend that you not do it, but rather that you purchase a license for one of the commercial products that are available for this. The ongoing time it will take to study/develop/code/maintain the programming is guaranteed to be less than a license cost. Further, if all of the ins and outs of exit points and server behaviors for different releases and different PTF levels aren't well understood and programmed for, you can open your system to the world without realizing it. Exit point programs can be capable of overriding normal system restrictions. (That's one of their functions.)
One example problem is that the system itself (and clients such as iNav's 'Run SQL scripts') can run CL commands through the server for its own functions. You have to learn how to recognize when to let the commands pass and when to reject them, even if they're coming from the same connection for the same user.
If you block the wrong commands or wrong functions under the wrong circumstances you can block normal system processes. You can even block your own (and everybody's) access to the system through network attachment. Use of a direct-attach or HMC console might be the only entry to the system in order to get control again.
That's also a reason why exit programming is a kind of last resort for security. The control should be through object (and capability) security. When that isn't managed appropriately, there are holes; and the holes can change under different circumstances.