I think allowing any program to read the clipboard at all is a huge mistake. The way it should work is that it's entirely safeguarded by the OS, and the only time an app can see the contents is when it receives them in a Ctrl+V event initiated by the user. This is the way most users, even non-technical, expect it to work, I'm pretty sure.

There are significant drawbacks with that: Many applications offer different paste actions via menu entries and/or different shortcuts, and sometimes via macros. (I use such non-default pasting all the time.) So there would have to be a mechanism to manage the ways an application is allowed to perform pasting, and to have the user selectively permit or forbid the various ways.

Additionally, the clipboard is often used to copy items within the same application, a mechanism which again can be involved in a multitude of application commands; or else the user must be burdened with having to distinguish between an application-level and the system-level clipboard. This can be partially solved by always allowing pasting of content copied from the same OS process, but multi-process applications would still face hurdles.

Another variation of that is scripting. I have various scripts and CLI aliases that take the current clipboard contents and do something with it.

While the clipboard can be made more secure than it traditionally is, these security measures come with the usual trade-off of making things more annoying for the user.