Ok, I feel I should clarify a bit since I would think the same upon this request.
First, the program allows only to modify fixed values, not other attributes such as lenght or type.
This reduces tremendously the risks, narrowing them to the deletion or description change of values already used in table records or referenced to in programs, and this is clearfully explained upon running the program with a big warning.
Secondly, the use case is for a specific standard domain, which was modified (repaired) years ago to add fixed values, and is used almost as a table nowadays. I receive monthly requests to add or change values on it, so I though why the heck couldn't the functional analyst update the values himself as he does for regular customizing tables (that's another risk reducer, not ANY user would run the program). It won't even reach quality client, it is to be used in dev only and domain changes to be transported as usual.
I could even restrict the program to only that specific domain, or disallow deletion of values, but I wanted to keep it pretty generic should a similar need arise later.
Now, to the problem at hand, the only workaround I thought of so far is exactly the same you suggest Jamie (create and use an RFC enabled wrapper of RS_CORR_INSERT with my username entered in the destination), and it seems I'll end up trying just that. Any other ideas are welcomed.
I could always program an enhancement at the beginning of DEVELOPER_CHECK to leave if my program is in the call stack, but that seems a bit extreme 
Regards