.png)
An approver can't see what they can't see. Every access request looks at one role on one app, while an SoD conflict is a relationship between that role and something the person already holds somewhere else. Zluri's violation insights close that gap: predicted conflicts now appear inside the request, in front of the approver, before the decision is made.
Picture a routine request: an engineer needs Write access on GitHub. It fits the role, the justification reads fine, and the manager approves it in two minutes.
What the manager couldn't see is that the same engineer already belongs to an Okta group granting deployment access to production. The approval just created a segregation of duties breach: one person can now author a code change and push it live, with no one in between. The violation surfaces weeks later in a compliance report, and someone has to unpick access that was granted through a perfectly legitimate, fully approved request.
Zluri's SoD violation insights move that discovery to where it belongs. Inside access request management, conflicts that an approval would create are surfaced to the approver before they decide, not weeks after.
In this piece, we cover why the approval moment matters so much, exactly what the approver sees, and how to put this to work.
Why the Approval Is Where Conflicts Are Born
Think about where an SoD violation actually comes from. Policies don't create conflicts, and neither do detection scans. Approvals do. Every toxic combination in your environment was, at some point, two legitimate grants that someone signed off on.
That makes the approval the single most leveraged moment in the whole control, and until now it was the one moment with zero visibility. Four things make this gap expensive:
- Every other SoD control is detective. The policy engine finds the violation only once the access is live. The approver is the only person positioned to prevent it, and they were the only person without the information.
- The approver can't see the rest of the person's access. They're looking at one request for one role on one app. The conflicting entitlement lives in a different system entirely.
- Prevention is far cheaper than remediation. Catching a conflict at approval costs one decision. Catching it post-provisioning means a violation record, a remediation ticket, a conversation with a user about access they were legitimately granted, and an audit finding that has to be explained.
- Approvers are mostly managers, not security people. They aren't expected to know which role combinations are toxic. Without the system telling them, the only realistic behavior is approving anything that looks plausible for the person's job, which is exactly how conflicts accumulate.
The whole value sits in one distinction: every other SoD control in the stack finds violations after access exists. This is the only point in the process where a conflict can be prevented instead of remediated.
What the Approver Sees
When a request would create a conflict, the Zluri Insights panel on that request leads with a new summary state: Compliance risk detected. It sits above the behavioral signals (Peer, User, and Access Insights), because a predicted policy breach outranks a usage pattern.
Directly beneath it, a SoD violation section lists every conflict the approval would create, with a count. The framing throughout is predictive: "2 predicted SoD violations. If the request is approved, these violations will occur." These violations haven't happened yet, which is the entire point.
Each violation card carries what the approver needs to understand the conflict without being a security specialist:
- The policy name and description, so the rule being broken is named in plain language
- Severity, taken straight from the policy definition: the security team's own rating, not a system-generated score
- Set A and Set B, the two sides of the conflict, each listing its matching entitlements (where several entitlements together create the conflict, they're joined with AND, so it's not always one role against another)
- View all conflicts, opening the complete set of combinations that trigger the policy
- The policy owner and detection time, so an approver who wants to challenge the finding knows exactly who to ask
The predictions are evaluated against the access the person held when the request was raised, and the panel's footer says so. These policies come from the same two-set model that powers detection everywhere else; our walkthrough of Zluri's SoD engine covers how they're built.
Informed, Not Blocked
Zluri does not block the approval, and the approver isn't required to acknowledge a violation before proceeding. The insight exists to make the decision informed, not to gate it, because sometimes conflicting access is the right call for a defined stretch, and the person closest to the context should make that call.
What changes is the record. When the approver clicks Approve Request, the Confirm Approval step asks them to select the insights that informed the decision, and every predicted SoD violation appears in that checklist by policy name, with a free-text reason field alongside.
This is the part auditors care about. The record doesn't just show that the approver was shown the conflict. It captures which conflicts they acknowledged and why they proceeded anyway. For organizations carrying SOX or ISO obligations, that documented, deliberate decision is often more valuable than the prevention itself.
Three Situations Where This Changes the Outcome
The conflict gets stopped before it exists
An engineer requests Write access on GitHub. Their manager opens the request, sees Compliance risk detected, and reads the card: the policy separating code authorship from production deployment, Set A holding the requested GitHub Write role, Set B holding the engineer's existing Okta deployment group, severity set by the security team. The manager now understands the request would let one person write a change and ship it. They reject it and point the engineer to read access instead. No violation record, no remediation ticket, no audit finding, because the conflict was never created.
The approval goes through, with the reasoning on record
Same request, but there's a real business need: the engineer is covering releases for two weeks while the release manager is on leave. The approver approves, ticks the SoD violation in the Confirm Approval checklist, and writes the reason. The violation still appears when the policy engine next runs, but it arrives with a documented, deliberate decision attached instead of landing as an unexplained breach. From there it moves through the full violation lifecycle like any other, and if the need justifies formal suppression, the team can grant one of Zluri's time-bound SoD exemptions against it. The compliance review takes thirty seconds instead of a week.
The approver who's never heard of SoD
Most access approvals are handled by reporting managers who couldn't define a segregation of duties policy if asked, and shouldn't have to. Previously their only signal was whether the request looked reasonable for the person's job, which by definition can't catch a toxic combination. Now the request itself names the policy, shows the two colliding sides, carries the security team's severity rating, and identifies the policy owner. The manager doesn't need to understand SoD to avoid creating a violation.
Turning It On
Violation insights live under Settings → Access Request, next to the existing Approver Insights control, as two independent toggles. The existing "Show insights for Approvers" toggle governs the behavioral Peer, User, and Access Insights; the new "Show policy violation insights" toggle governs predicted SoD conflicts. Because they're independent, an org can run either one alone or both together, and an admin's single change applies org-wide.
One prerequisite worth checking before you flip the switch: the role field on the access request form must use Zluri data as its source. If roles are collected another way, Zluri has no entitlement to evaluate against the policy, and no violation gets predicted.
What to Know Before Implementing
A few behaviors matter for setting expectations with your approvers:
- Predictions reflect the request's raise time. If the person's access changed between raising and approval, the prediction may not reflect the current state, and the panel's footer notes this.
- Predicted violations carry no exemption status. There's nothing to exempt until the access exists. An approver who proceeds does so by approving with a recorded reason; the formal exemption, if one is warranted, happens on the real violation once it's detected.
- Acknowledgement is optional. An approver can approve without ticking any violation in the checklist, in which case the audit record shows the approval but no explicit acknowledgement. If explicit acknowledgement matters for your audit posture, it belongs in your approver training.
- The policy owner is named, not notified. The owner appears on the card so approvers know who to ask, but they aren't added to the approval chain. Whoever was already approving is the one who acts.
None of these are gaps in the control you already run. Detection, the violation lifecycle, and exemptions all operate exactly as before. This sits in front of them, cutting down how much work ever reaches them.
Frequently Asked Questions
Does Zluri block an approval that would create an SoD violation?
No. Predicted violations are shown as context, and the approver can proceed. The design intent is an informed decision rather than a hard gate, since some conflicts are legitimately needed for a defined period. What the system does enforce is the record: approvals made through a predicted violation can carry the approver's acknowledgement and written reason.
What's the difference between a predicted violation and a real one?
A predicted violation describes what would occur if the request were approved; it exists only in the request's insights panel and carries no status of its own. A real violation is created when detection runs against live access, and it moves through the full set of statuses, from Open through remediation or exemption.
Do I need Approver Insights turned on to use violation insights?
No. The two settings are independent. With Approver Insights off and violation insights on, the panel shows the compliance section without the peer, user, and access sections.
Why would a request that creates a conflict show no violation?
The most common cause is the role field on the request form not using Zluri data as its source. Without that, there's no entitlement to evaluate against the policy. Timing is the other factor: predictions are evaluated when the request is raised, so access granted through another channel afterward won't be reflected.
Where does the approver's reasoning end up?
In the approval record. The Confirm Approval step captures which predicted violations the approver selected and the reason they entered, so when the violation later appears in a detection run, the compliance team sees a deliberate, documented decision rather than an unexplained breach.
