SailPoint Access recommendations

SailPoint AI recommends whether to approve or revoke access based on peer group analysis, giving reviewers a confidence signal for each decision.

The problem they exist to solve is worth stating first, because it explains why this is an AI feature at all rather than a report. A certification campaign puts a reviewer in front of a list of entitlements and asks them to approve or revoke each one. A manager with forty staff and a hundred entitlements each is being asked to make four thousand decisions, about access they mostly did not grant and do not understand.

What happens next is well documented and entirely predictable: they approve everything. The campaign completes, the audit evidence exists, and no access was actually reviewed. This is called rubber stamping and it is the single biggest weakness in identity governance as it is usually practised.

Recommendations attack that directly. Instead of a flat list, the reviewer sees each item marked as approve, revoke, or no opinion, with a reason. The reviewer's job changes from making four thousand decisions to checking a few hundred that the system flagged and accepting the rest quickly. That is a job a person can actually do.

Where this sits in the product is worth knowing so you can find it. Recommendations are a service the platform calls when it renders a certification item or an access request, not something you run as a job. The identity data it reasons over is what has already been aggregated from your sources, so nothing extra is collected and nothing leaves on a separate schedule. That also means it inherits every gap in that data without announcing it.

Recommendations compare an identity to similar peers: access that peers commonly hold is likely appropriate, unusual access is flagged for scrutiny.

The mechanism underneath is simpler than the word AI suggests, and understanding it is what lets you explain a recommendation to an auditor.

The system builds a peer group for each identity from attributes it already has: department, job title, manager, location, cost centre. Then for a given entitlement it asks what proportion of that person's peers hold it. Very high, and holding it looks normal. Very low, and holding it looks unusual.

Two more signals refine that. Similar identity access compares against people whose overall access profile resembles this person's, which catches cases where the formal attributes are a poor description of the job. And previous decisions feed back in: if reviewers have repeatedly revoked a particular entitlement for people in this role, that becomes evidence.

So a recommendation is a statement about the population, not about the individual. It says this access is unusual for someone like you, which is a very different claim from saying this access is wrong.

Confidence is reported alongside each recommendation and it is worth reading rather than skipping. A high confidence revoke means the entitlement is held by almost nobody comparable. A low confidence one means the signal is weak, usually because the peer group is small or the person's attributes place them somewhere unusual. Treating the two the same is how a feature designed to focus attention ends up spreading it evenly again.

Recommendations surface in access requests and certifications, speeding decisions and improving consistency across reviewers.

The two places they appear ask different things of you.

In certifications, the recommendation is advice to a human who still decides. Low risk, because a wrong recommendation is a wrong hint.

In access request approvals, the same signal informs somebody granting new access, which is the moment when a wrong approval creates the problem rather than failing to remove it.

The configuration question that follows is whether to allow auto approval of high confidence recommendations. It removes an enormous amount of reviewer effort and it also removes the human from those decisions entirely. The defensible position is to start with recommendations as advice only, measure how often reviewers disagree with them, and consider automation for the categories where agreement is consistently high. Turning it on first and measuring later is the wrong order and it is the common one.

One practical consequence for campaign design: recommendations make large campaigns feasible, which tempts teams into running larger ones. Resist it for the first few cycles. A campaign small enough that you can spot check the outcomes teaches you whether the recommendations are any good on your data, and a campaign covering everything teaches you nothing except that it completed.

Before turning this on for a real campaign, do this once. It takes an hour and it is what you will be asked about later.

1. Pick one identity whose job you actually understand.
2. Look at the peer group the system built for them. Read the attributes it used. Ask whether those people really do the same job.
3. Find an entitlement marked for revocation. Read the reason given.
4. Go and ask the manager whether that access is needed. Note the answer.
5. Now find an entitlement marked approve that you suspect is wrong, and check that too.
6. Repeat for two more identities in different departments.

What you are testing is step two. If the peer groups are built from attributes that are stale, blank, or mean something different in each region, then every recommendation resting on them is confident and wrong. Identity data quality is the prerequisite, and this exercise is how you find out whether you have it.

Each recommendation includes the reasoning (peer coverage), so reviewers understand why, and governance stays accountable.

Two things an auditor will ask, so have the answers ready. Why did the system say that, which the reason text answers, and which is why you should never present a recommendation without it. And who decided, which must be a person unless you have deliberately configured otherwise and documented why.

The failure mode to watch for is the recommendation becoming the decision by habit. Reviewers who accept every suggestion are rubber stamping again, just faster and with better evidence that they were not. Worth measuring: the proportion of items where the reviewer disagreed with the recommendation. If it is essentially zero across thousands of items, nobody is reviewing.

Version note: this capability lives in the cloud offering, not in the on-premise product, and the feature names have changed as the portfolio has been renamed. Check what your tenant actually has before promising it, because material written about one product line frequently reads as though it applies to both. See access modeling, outlier detection, certification recommendations and access insights.

One more governance point that comes up in every review. A recommendation is generated from data about other employees, so somebody will eventually ask whether that is an appropriate use of personal data. The answer is usually yes and it is a question worth having a documented answer to rather than improvising, particularly where works councils or data protection officers have a say.

• Turning it on before checking identity data quality. Bad attributes make confident, wrong peer groups.
• Auto approving before measuring agreement. The wrong order.
• Hiding the reason text. A recommendation without its reason cannot be defended.
• Not measuring disagreement. Zero disagreement means nobody is reviewing.

Reading a recommendation takes a minute, and knowing whether your identity data is good enough for anyone to trust one is the judgement the course builds.