Access reviews
One access-review engine with three trigger types — continuous, event, and campaign — plus reviewer chains and account-first review scope.
Access reviews (historically called "certification" or "attestation") are the periodic and event-driven confirmation that access is still correct. A reviewer confirms or revokes an assignment; compliance gets a signed record that the review happened. There is a single configuration source (CertRule), so the same engine drives every kind of review.
One engine, three trigger types
There is a single access-review engine. What used to be two parallel producers is now one rule type with a trigger_type that determines how reviews are spawned. Every resulting task lands in the same unified review inbox as a DecisionTask.
trigger_type |
Trigger | Question it answers |
|---|---|---|
continuous |
Periodic (a rolling clock per subject) | "Is this still correct N days after the last approval?" |
event |
A bus event (mover, new assignment, content change, drift, …) | "Something structurally changed — review now" |
campaign |
An explicit campaign with a fixed window | "Review this whole population before the audit deadline" |
The reviewer works continuous and event reviews from one inbox; campaigns are tracked on their own tab. The mental model is that rule-based recertification is the spine and campaigns are the fallback — for audits that must happen on a fixed calendar, or for object sets you deliberately do not want on an automatic clock.
CertRule — the single configuration source
All reusable review configuration lives in CertRule. Its key fields:
| Field | Meaning |
|---|---|
target_kind |
What is being reviewed: grant (an assignment), role, policy, identity_validity, ownership, or account |
trigger_type |
continuous, event, or campaign |
reviewer_chain (inline) or reviewer_chain_id (named) |
Who reviews, in which order, and with what quorum — see Approver chains |
review_scope |
For assignment reviews only — how the items are grouped (see below) |
conditions |
A filter that selects the slice of objects this rule covers (its "bucket") |
auto_action_on_deadline |
What happens to an undecided item at the deadline — differs per target_kind |
Because a rule's conditions scope a slice of the object space, the platform can expose the gap: every reviewable object should fall under some rule. The ones that fall under none are never reviewed and surface as coverage gaps in the Advisor.
Target kinds group into three pillars
The target_kind values organize into three business questions:
| Pillar | Question | Target kinds |
|---|---|---|
| Assignment | Does this right still belong to this person? | grant |
| Validity | Should this object still exist? | identity_validity (external and non-human identities) |
| Composition | Should this object still contain these items? | role, policy |
Owner attestation (ownership) sits alongside these: each explicit owner periodically confirms they still own their objects. Administrators toggle which kinds are reviewable in the review configuration; a rule can only target a kind that is enabled.
💡 Tip
Human identities sourced from human resources (HR) are excluded from
identity_validityreviews — HR is authoritative for whether the person still exists. Their access is still reviewed, through the assignment (grant) path.identity_validityreviews apply to non-human and external identities only.
Continuous sweep — dispatched per target kind
The continuous sweep dispatches per target_kind:
| Target kind | What it iterates |
|---|---|
grant |
Each assignment |
role |
Each role |
policy |
Each access grant policy |
identity_validity |
Each identity, filtered by identity type or source system |
ownership |
Each owned object (owner attestation) |
account |
Each account, reviewed as an object |
Each sweep spawns the first step's tasks — one per approver, sharing a fan-out group and carrying quorum metadata. A later step is created lazily once the previous step's quorum is reached.
Event-triggered reviews
Event reviews bind to the assignment-side event catalogue — for example an identity transfer (a mover), a new assignment being granted, drift detected at reconciliation, an emergency-access use, or a role or policy content change. Two default rules are seeded and on by default:
- A mover rule — after a transfer, the person's current assignments are reviewed.
- A new-assignment rule — a fresh assignment on a high-risk entitlement is reviewed just in time.
An event is a just-in-time review that resets the periodic clock: a second identical event does not spawn a duplicate while a review is already open for that item, and completing the review updates the "last reviewed" timestamp the continuous sweep reads. This is the only producer of mover and new-assignment reviews — there is no separate parallel mechanism.
Review scope — account-first for assignment reviews
Assignments are rooted on an account (an entitlement is held through an account, not directly by an identity). So an assignment review is presented account-first by default. review_scope controls the presentation:
review_scope |
Presentation |
|---|---|
account (default) |
Assignments grouped per account — the honest shape, since account-level risk (shared, privileged, orphan) lives at the account layer |
account_with_access |
Adds an "account invalid → revoke all" lead control that revokes the whole account group through the normal per-assignment decisions |
grant_flat |
A deliberate opt-out that hides the account grouping and lists assignments flat |
review_scope is only consulted for target_kind=grant; role, policy, and validity reviews have no account layer. It is purely presentation — the decision mechanics are unchanged.
Self-review guard
For grant and identity_validity reviews, the reviewer may not be the subject. The decide action is refused server-side, and the item must be reassigned first. Ownership attestation is exempt — an owner confirming their own ownership is the entire point.
Non-human identity ownership review
On startup, a default rule is seeded that enforces a yearly ownership review for non-human identities (NHIs) — service accounts, artificial-intelligence agents, applications, system accounts, and internet-of-things devices. It targets identity_validity, routes to the identity's manager as a proxy for the owner, and flags rather than auto-revokes on the deadline.