We have updated API enforcement to ensure Help Desk users do not have access to the Search API. This matches our published User Level Access guidance: Help Desk is intended for operational tasks (for example, finding identities to support account resets), not for broad Search API use.
Why We Made This Change
This update closes a rare gap between documented access and actual API behavior and strengthens least-privilege access in line with our security and compliance practices.
When This Applies
The change was deployed in stages: staging on March 26 and production on March 30, 2026. Integrations or scripts that call Search using Help Desk credentials may stop working or return authorization errors from that date forward in production.
Who May Be Affected
You may be impacted if your integration uses a Help Desk user token to call the Search API (for example, to look up identities or attributes). Configurations that already follow the documented paths below are unaffected in intent; those that relied on Search under Help Desk may need a small change.
What You Should Do — Supported Options
Use one of these approaches, depending on your needs:
Identities API (recommended for listing/searching identities within documented Help Desk access) - Use the List Identities API as documented: list-identities | SailPoint Developer Community
Admin UI - Help Desk users can locate identities via Admin → Identities → Human Identities (including the search capability in that experience), consistent with prior guidance.
Personal Access Token (PAT) with Search read scope - If your automation must use the Search API, use a token that is explicitly authorized for that scope—for example, a PAT that includes sp:search:read—and update your integration to use that token instead of Help Desk credentials for Search.
API client with Search read scope - Alternatively, configure an API client with sp:search:read (and any other scopes your integration requires). Obtain access tokens using that client (for example client credentials or refresh token, depending on your setup; authorization code is also supported where applicable).
We are updating developer documentation to reflect that Help Desk users no longer have access to the Search API; the live developer site will be updated when that publish completes.
Thank you for the announcement! Although I am not understanding why you would announce this only on April 8th that the change was deployed in production in March 30 and will fail starting then. Shouldn’t customers be informed prior to changes, especially breaking changes such as this one, allowing them to prepare for the release (test, design new way going forward etc.). Or does SailPoint consider this a security vulnerability that needed to be fixed before it could have been announced? That would make sense, but then shouldn’t this be announced as such? With a label that this was a security vulnerability and a breaking change, allowing customers to prioritize this announcement more, and perhaps check if any malicious activity has occurred on their tenant in the past when the vulnerability was still there?
It makes sense to me that helpdesk users can’t use the search API as that is not in the philosophy of what helpdesk users should be able to do.
But the alternative approaches unfortunately fall short for identities that need to be able to use the search API, without getting other authorizations:
Options 1 and 2 don’t allow to search with the same amount of functionality as the search API. So here, loss of functionality arise. We can’t search for all inactive identities with admin access for example.
Option 3 would only work if the identity has the right user level to begin with. Otherwise this scope is not visible in this list. Since helpdesk users lose this access, we would now need to increase the authorization of the identity, for example from helpdesk admin to org admin or report admin. But this violates the principle of least privilege as they would then inherit other authorizations that they should not be allowed to inherit.
Option 4 would not work because this is not associated with an identity, meaning we lose other controls that only works for identities such as using segments for limitations, JML that will delete the PAT when the identity becomes inactive long term. In addition many APIs are not callable by an API client, so if the person/agent/system that needs to call the search API also needs to call other APIs, it would need to have two different credentials to meet this criteria.
My suggestion would be simple:
Allow us to create custom user levels, pointing them to the rights set “sp:search:read”. This way we can give identities exactly the right access they would need. The ability to search, without getting any other authorizations by needing to choose an OOTB user level that would be too broad. (Bonus points if this can be split per index, allowing some identities to search only on identities, others only on roles and access profiles, and others only on workflow executions.). Right now custom user levels allow us to manage a limited list of authorizations.
Only by providing this would SailPoint truly support least-privilege access. Until then we are at the mercy of SailPoint making changes to the user levels in the way they see fit, which bundles authorizations, and is not providing least-privilege.
Thank you for the announcement. But I do agree with all the points mentioned by @angelo_mekenkamp and would like to raise the concern specially on announcement time and the time changes went live especially to production tenants.
We have lot of users who have been given this helpdesk access and we are not sure whether they are already making use of Search functionality. Now, we will have to evaluate this with them to ensure that nothing is broken.
