Meaningful entitlement descriptions are critical in making accurate and informed decisions in access requests and approvals, in certifications, and in role modeling. But who has the time to write them for thousands of entitlements? That’s where GenAI Descriptions for Entitlements come in!
Join us for a webinar to learn how using GenAI Descriptions for Entitlements in Identity Security Cloud dramatically reduces time spent in producing high-quality entitlement descriptions versus writing them from scratch.
You’ll be able to answer the following:
What is GenAI Descriptions for Entitlements?
How do you use GenAI Descriptions for Entitlements?
How does GenAI Descriptions for Entitlements improve your Access Model?
2025-04-16T15:00:00Z→2025-04-16T16:00:00Z
@MVKR7T will be coming to you live on April 16 at 10 a.m. CDT.
Will you cover the below topic/thoughts in your webinar?
Target applications provides entitlement data and ISC aggregates this entitlement data from the target applications.
Why should ISC even be responsible for providing descriptions to entitlements? This data should be fetched during entitlement aggregation from target applications, which is the authoritative source for entitlements. The organisation or team behind that application should therefore be responsible to define the description of those entitlements.
If ISC provides entitlement descriptions for target applications, ISC suddenly become an authoritative source for the entitlement data itself, or at least part of it. I think this will lead to several negative results.
The target application does not see the descriptions we create on the actual origin of the entitlements.
If entitlements from the target application change meaning over time, they can’t update the description since it was only defined in ISC.
If another system that integrates with a target application needs to know the entitlement descriptions, they can’t fetch it from the target application themselves, but they suddenly either need to generate descriptions themselves as well, or they would need to build a second integration to ISC, to fetch the right data from ISC.
If the suggested entitlement description is wrong, the owner of the target application can’t change it on their application side. Instead they would now need to have additional user levels in order to change it within ISC.
An additional benefit for having the entitlement descriptions defined within the target applications itself, would be that if the entitlement was created from an organization that provides services to multiple customers, that they would only need to define the description of this entitlement once, (and they would be the best fit to describe the entitlement), and it will be aggregated by all ISC tenants that use this connector. In this way, each separate ISC customer would not have to generate the descriptions themselves, regardless of whether they would use an AI or do it manually.
If anything, I think SailPoint should allow ISC source admins to go to the entitlement schema in the UI, and just like they can tell ISC which entitlement attribute should be considered the “entilement ID” and which attribute should be considered the “entitlement name”, they should also be able to tell ISC which entitlement attribute should be considered the “entitlement description”.
