Similar to bug 479184, not sure if it should be marked as a duplicate. I'm going to copy/paste some comments from that report that are relevant.

(In reply to Nate Graham from comment #3)
> In the past we had Spectacle going through the screenshot portal but the UX
> was awful:
> 1. Launch Spectacle
> 2. Click one of the "Take a screenshot" buttons
> 3. Get prompted by the portal to allow this, and also to select what kind of
> screenshot you want all over again
> 
> It was terrible, especially for the case of launching spectacle to via a
> global shortcut to take a screenshot quickly. The UX was simply unacceptable
> for an app whose only purpose is to take screenshots. It's for that reason
> that Spectacle currently uses a private protocol to talk to KWin.
> 
> Now, I would like it to eventually be ported back to use the portalized
> screenshot system, but only once we can ensure an adequate UX that doesn't
> prompt the user to confirm doing what they just explicitly said they want to
> do. As a result no actual security wold be gained by this as Spectacle would
> either be whitelisted by the system, or allowed once by the user with that
> permission being remembered over time.
> 
> Now, I do get your point that the existence of the command-line interface
> for spectacle means that any app with access to run shell commands can
> secretly take screenshots without the user's permission. That's true, and
> it's a theoretical security risk.
> 
> However the interface is also useful for users automating their own
> workflows. We can't prevent the users from doing something useful simply
> because it *could* be abused. This would be like nailing someone's windows
> shut to protect against the threat of someone nefarious climing into an open
> window. That's not real security.
> 
> As such I'm quite dubious about this suggestion. If your threat model
> involves untrustworthy local software having shell access, you have already
> lost the battle.
> 
> But I'll let Noah the maintainer decide what to do from here.

(In reply to Noah Davis from comment #4)
> [snip]
> 
> The fundamental issue in the situation you described is that you can start a
> program capable of doing nearly anything in the background using other
> programs without getting consent from the user. You could also start a
> program that copies documents to some place on the internet or deletes
> nearly everything in the Home folder without your permission. [snip]

(In reply to Nate Graham from comment #7)
> I appreciate your understanding.
> 
> FWIW the sandboxing and portals systems seem designed to support a use case
> where we can't necessarily trust our own apps, more akin to the Google Play
> store on Android. However from my perspective this is ceding most of the
> field before battle has even been joined. If we can't prevent the user from
> installing actively malicious software on their system, I think we've
> already lost. Android shows us what this world looks like: 99% of the free
> apps on the Google Play store are garbage that's at best only mildly
> user-hostile and at worse is using every dark pattern in the book to try to
> harm you. Even the strongest sandbox is no protection at all for local
> software that can trick the user into giving it permission to do whatever it
> wants.
> 
> This approach passes the buck by saying, "well, I told you there was a risk,
> you you clicked on the Accept button anyway!" But it should be obvious that
> this is not an effective system for truly protecting the user. We have
> decades of experience to show us that regular people will click on anything,
> won't read dialogs, don't understand digital risks, etc. Putting the
> responsibility on them is wrong.
> 
> Personally I think what we should be striving for us to keep actively bad
> software out of our apps stores and software repos in the first place, and
> therefore off the devices of casual users who are least able to manage the
> risks of malicious apps.
> 
> But this is a much larger topic. :)

(In reply to Marco Rebhan from comment #0)
> EXPECTED RESULT
> Spectacle should respect the access limits of the screen capture API and
> should check the permissions of the application trying to make a screenshot,
> or try to take a screenshot with the permission context of the calling app
> in some way (potentially via the systemd scope it gets run in or something
> like that, I think that knows which desktop file it belongs to which sets
> the permissions).

I don't think what you are asking for is possible.
Spectacle uses KWin's screenshot API for reasons mentioned in Nate's first comment.
KWin's screenshot API doesn't have permissions, it just checks if the requesting executable is in the same install prefix as KWin.
Spectacle can't know anything about apps that are trying to start a new Spectacle process, so it cannot check their permissions.
I don't think Spectacle can choose which systemd scope it is used in.

(In reply to Noah Davis from comment #1)
> (In reply to Nate Graham from comment #3)
> > Now, I would like it to eventually be ported back to use the portalized
> > screenshot system, but only once we can ensure an adequate UX that doesn't
> > prompt the user to confirm doing what they just explicitly said they want to
> > do. As a result no actual security wold be gained by this as Spectacle would
> > either be whitelisted by the system, or allowed once by the user with that
> > permission being remembered over time.

I agree, when taking a screenshot through Spectacle it should not ask for permission (or at least, at most once). Anything else would be annoying.

> > However the interface is also useful for users automating their own
> > workflows. We can't prevent the users from doing something useful simply
> > because it *could* be abused. This would be like nailing someone's windows
> > shut to protect against the threat of someone nefarious climing into an open
> > window. That's not real security.

Yeah, I would also not want the option to be removed from the Spectacle CLI for that reason. It's good to be able to automate this.

> > As such I'm quite dubious about this suggestion. If your threat model
> > involves untrustworthy local software having shell access, you have already
> > lost the battle.

*Any* software you run including untrusted programs can do this since everything has access to exec/posix_spawn.

Of course there is sandboxing tools to restrict this, but I feel like it's better to be secure by default rather than require explicit setup.

> (In reply to Nate Graham from comment #7)
> > I appreciate your understanding.
> […]
> > Personally I think what we should be striving for us to keep actively bad
> > software out of our apps stores and software repos in the first place, and
> > therefore off the devices of casual users who are least able to manage the
> > risks of malicious apps.
> > 
> > But this is a much larger topic. :)

I actually do agree with this whole part. However, there is a security system now whether we think it is a good idea or not, and it is also an unfortunate reality that untrusted programs do run on at least a huge part of people's computers (for example, proprietary games, even game mods, which can be malicious; see the recent malware shipped inside of a Cities Skylines 2 mod for example), so this is something that cannot be always 100% controlled. And I think that if implemented at all, security shouldn't be trivially bypassable like this.

(In reply to Noah Davis from comment #2)
> I don't think what you are asking for is possible.
> Spectacle uses KWin's screenshot API for reasons mentioned in Nate's first
> comment.
> KWin's screenshot API doesn't have permissions, it just checks if the
> requesting executable is in the same install prefix as KWin.
> Spectacle can't know anything about apps that are trying to start a new
> Spectacle process, so it cannot check their permissions.
> I don't think Spectacle can choose which systemd scope it is used in.

Ahh, I thought the X-KDE-DBUS-Restricted-Interfaces key in Spectacle's desktop file controlled this access. But no, what I'm thinking of is the following flow:

1. User starts application from the plasmashell launcher
2. plasmashell (or whatever) sets up new scope for this app, attaches information about the desktop file that launched it (something like this already happens, for example for System Monitor)
3. app ends up spawning a spectacle process or is spectacle itself, this spectacle process of course ends up in the same app's scope
4. spectacle tries to take a screenshot
5. (new!) kwin checks the process's scope instead of the process path and determines access based on that, shows confirm dialog if the user didn't confirm access to screenshots for this desktop file yet. the system can ship pre-existing rules to allow screenshots for spectacle when launched via its desktop file so it won't ask there

This is roughly based on how it seems like macOS's permissions checks work. IMO this is something they got right.

Implementing it like this is obviously something that would have to be done on Kwin's side, though.

(In reply to Marco Rebhan from comment #3)
> Ahh, I thought the X-KDE-DBUS-Restricted-Interfaces key in Spectacle's
> desktop file controlled this access. But no, what I'm thinking of is the
> following flow:
> 
> 1. User starts application from the plasmashell launcher
> 2. plasmashell (or whatever) sets up new scope for this app, attaches
> information about the desktop file that launched it (something like this
> already happens, for example for System Monitor)
> 3. app ends up spawning a spectacle process or is spectacle itself, this
> spectacle process of course ends up in the same app's scope
> 4. spectacle tries to take a screenshot
> 5. (new!) kwin checks the process's scope instead of the process path and
> determines access based on that, shows confirm dialog if the user didn't
> confirm access to screenshots for this desktop file yet. the system can ship
> pre-existing rules to allow screenshots for spectacle when launched via its
> desktop file so it won't ask there
> 
> This is roughly based on how it seems like macOS's permissions checks work.
> IMO this is something they got right.
> 
> Implementing it like this is obviously something that would have to be done
> on Kwin's side, though.

That does sound like it could be better, depending on the implementation. The install location restriction is really annoying for developer setups because it forces you to also build kwin from source and install it with spectacle somewhere.