This started as a response to your comment here but made more sense as a full answer.
Right now, the system automatically changes my file permissions to add executable capability every time I plug in a drive.
No it doesn't! The files are already executable, in the sense that this is the default behavior of files on those file systems. The system is not changing any file permissions because the *FAT file systems literally don't support an "execute" permission. NTFS does, but it's set by default on all files, and in any case the usual behavior of the NTFS driver on Linux is to ignore file ACLs since they pertain to users who do not exist on the system. I don't know what would happen if you used Windows to remove (or even deny) Execute permission to "All users" (the Windows equivalent of "world") and then mounted the relevant device on Linux, but my guess is that the Linux NTFS driver would ignore the lack/forbidding of execute permission the same way it ignores other NTFS ACLs. In any case, it certainly wouldn't automatically change them; at worst it would ignore them, the same way Windows (by default) ignores the execute (traverse) permission on directories1.
Could you consider this a security risk?
No, not really. Security is a matter of preventing unauthorized behavior, and there isn't any of that here. Obviously the permissions themselves are unenforceable - anybody with Administrator/root access could override them in multiple ways, and are the ultimate arbiter of what is or isn't authorized - so executing a file is always authorized on a machine you control. If an admin doesn't want a non-root user to execute files from removable storage, or outside a specifically allowed list, that's up to the admin to configure for the relevant user[s]/machine[s] (e.g. by changing the automatic mount permissions to noexec). File permissions are only a relevant concept within a closed system like a single machine, which removable storage generally does not remain within anyhow.
The user might sometimes benefit from a "hey, did you mean to run that?" confirmation pop-up when launching an executable from a potentially untrusted location like removable storage. However, this would not provide security, merely prevent some mistakes (at the cost of annoying users). Very serious mistakes are sometimes worth such hassle - see for example the --no-preserve-root option on rm, which exists because people sometimes accidentally nuke the root of their drive (and basically never do so on purpose, so it's now prevented by default) - but that's not a security feature.
1 This is configurable, if you really want to turn it on. It's not generally useful on Windows, though, because Windows file permissions are by default mostly inherited from the containing directory, rather than being determined mostly by the user's umask. In other words, while in Linux it's actually moderately common to have a situation where a directory isn't readable (to non-owners) but its contents are (because the default umask makes files world-readable); in such a situation, only the traverse (execute) permission on the directory prevents arbitrary users from reading the files. On Windows this very rarely happens. Unless somebody deliberately alters the directory's ACL in a weird way (make other users able to read contained objects even though they can't read the directory itself) or the file's permissions (to add non-inherited read access for other users), the traverse permission on the directory isn't really doing anything other than technically allowing people who guess the file's exact path to confirm its existence, so the traverse permission isn't considered important to enforce.
noexecflag was created long before GUI security was ever considered. While it may have some limited security benefits (e.g. breaking some automated bots that try to download and execute a file in/tmp), it is not designed for security. See also this answer as linked above.