Operator role required for Get-PSUCache in 2026.2.1?
It seems like we need the operator role in order for users to execute Get-PSUCache in an app in 2026.2.1. Line 15 in the function is a Get-PSUCache call ( $CPM = Get-PSUCache -Key CPM )[9/21/2026 10:08:11 AM] [Error] [App-CRM Banking Dashboard] at Get-CPMTable, E:\psuSites\JHBDashboard_data\UniversalAutomation\Repository\dashboards\CRMBankingDashboard\modules\CPMBackEnd\1.0.0\Public\Get-CPMTable.ps1: line 15at dynamicCPMTable: line 4at dynamicCPMTable: line 3at dynamicCPMTable: line 1at CPM.ps1 [9/21/2026 10:08:11 AM] [Error] [App-CRM Banking Dashboard] Permission denied. The role specified does not have access to this resource.[File]: CPM.ps1[Endpoint]: dynamicCPMTable[Page]: b1c7879d-5fea-4f55-8d58-66bc9a85dc0d
The description for Operator says it can add or remove psu resources like scripts or endpoints. That seems like way too much power for someone who needs to access cache programmatically.
All Comments (5)
Hello @mshepard70
Thank you for reporting this. I understand the concern. Assigning the Operator role solely to allow an application user to read a cache value would provide substantially broader permissions than the operation itself requires.
I would like to validate this behavior before determining whether it is expected authorization behavior or something specific to 2026.2.1.
Could you please confirm the following?
• What role or roles are currently assigned to the affected users?
• Is API security configured as Strict or Permissive?
• Did this work without the Operator role in a previous PSU version? If so, which version?
• Does the behavior change if the cache call is executed using:
Get-PSUCache -Key CPM -Integrated
Support for Integrated mode with Strict API security was added in PSU 2026.1.4, so this comparison will help us determine whether the request is being authorized differently when executed from the App.
We will also attempt to reproduce the scenario internally using 2026.2.1 and compare the behavior across user roles before reaching a conclusion.
Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.
References:
https://devolutions.net/powershell-universal/release-notes/
Best regards,
Ruben Tapia
Before assigning Operator, the affected users had the User role. We also tried adding the Execute role with no luck.
The Api Security Model is set to "Integrated"
I think this surfaced when we tightened the Operator role. It has been working in earlier versions (and this version), but the Operator role was set to $true for all users.
I haven't tried using -Integrated, but will try that this morning.
My mistake...the Api security model was set to Permissive.
Adding -Integrated everywhere seems to have allowed the app to run with User only.
Hello @mshepard70
Thank you for testing this and for clarifying that the API security model is set to Permissive.
Your latest result is very helpful. Since adding -Integrated allows the App to run successfully with only the User role, the Operator role does not appear to be required for this scenario.
This also explains why the issue became visible after Operator was removed from the affected users. The previous configuration was effectively masking the authorization requirement of the non-Integrated calls.
Based on your validation, using -Integrated for the applicable PSU cmdlet calls provides the lower-privilege approach you were looking for while keeping the users on the User role.
Thank you again for confirming the behavior.
Best regards,
Ruben Tapia