Focusing on your initial concern ‘anyone can get that code' and write and execute an OPS/MVS rule or OPS/REXX pgm to do xxxxxxx – this can be addressed by ‘locking up’ the gun cabinet. R/W access to only the automation team for your RULES and REXX pgms, SECurity rules to secure who can enable rules and execute OPS/REXX pgms, and based on OSF security parms, potentially a )CMD osfchar rule with logic to allow/disallow the issuance of a command directed to your OPS servers via the OSFCHAR parm. Another effective means and my favorite is the Baseball Bat approach. Using the OPSLOG ,quickly identify the intruders and proceed to their cube with a baseball bat. A few times of that approach would more than likely resolve all future issues.
On the issue with securing logic within rules that ‘you’ created that perform some work that you want to secure (specifically CMD rules) – Directly incorporate logic to allow/disallow (allow to process logic or RETURN ‘REJECT’) the user that triggered the rule and/or utilize the OPSECURE() to determine if the user has access to some specified generalized resource defined within your security package. Based on the returned resource access from the OPSECURE(), determine if the rule logic should performed or not. Specific to CA7 - you can setup CA7 to force that all external CA7 commands require a LOGON command. I'm sure this info is somewhere in CA7 documentation.
I'm sure the user community may have other security methods here that they can share.