macOS has no permission gate for the pasteboard
Your Mac asks before an app uses the camera. It asks for the microphone, for screen recording, for your Documents folder, for your contacts. The pasteboard is not on that list. Any process in your user session can call the pasteboard API, read the current contents, and you will never know.
The design is old, and that explains a lot. ctrl.blog's write-up dates the clipboard to 1973 and documents how differently each operating system guards it. It was built to move a few characters between two programs on one trusted machine. Passwords, bearer tokens and card numbers arrived later.
Apple states the risk on its own support page. The macOS 26 Spotlight clipboard history documentation says: "Sensitive information may appear on the Clipboard."
The iPhone made the same reads visible
On iOS the reads were constant and nobody could see them. In 2020, security researchers Talal Haj Bakry and Tommy Mysk found 53 popular apps reading the pasteboard with no reason to do it. Apple's answer in iOS 14 was a banner. When an app pastes from another app, you now see a notification saying so.
Sophos covered the fallout, including TikTok among the apps the banner exposed. Behaviour changed quickly once the reads were attributable to a name on the screen.
macOS never got that banner. Same capability, same freedom, no notification.
A clipboard manager changes the shape of the problem rather than the permissions. The read is still unrestricted. What changes is duration: one item held for four seconds becomes a searchable record that stays until something deletes it.
That cost applies to every history app, mine included. The controls that matter are an exclusion list, a retention limit and a clear button, and you should check all three before you trust any of them.
Firefox treats a copied password as a special case
Browsers moved on this before operating systems did. Firefox 94 and ESR 91.3 stopped handing password-field and private-browsing copies to OS clipboard history and cloud sync. Mozilla wrote it up, and it is tracked as CVE-2021-38505.
The scope is narrow, so be precise about it. The copy still reaches your clipboard, and ⌘V still works. What stops is the copy being handed to anything that keeps a record of it. Older Firefox builds passed those copies straight through.
Chrome and Safari do not publish an equivalent behaviour. I would assume a password copied in either one is recordable.