Platform Advisor

A detector framework that turns tenant-wide state into a finite list of findings, each routed to a named person — and why it almost never fixes anything on its own.

Most governance problems are not events. Nothing fires when an owner leaves, when a policy starts pointing at a department that no longer exists, or when a system quietly stops syncing. They are states that become true and stay true, and the only way to find them is to go and look.

The Platform Advisor is what does the looking. It is a framework rather than a fixed feature: a set of independent checks — 41 today — that each scan tenant state on their own schedule and emit findings into one inbox. The framework matters more than the list, because the list will keep growing and the guarantees will not.

What a detector is

A detector is a small, self-contained check with three methods and some class-level metadata. Adding one is a code change, not a configuration exercise — there is no rule builder here and deliberately so, because these checks are cross-cutting queries over the whole tenant, not per-object conditions.

Method	When it runs	What it may do
Scan	On its own interval, or on demand	Read only. Returns zero or more findings; touches nothing.
Defensive action	Once, the first time a specific finding appears	Narrowly limit the damage while the finding waits for a person. Almost every detector declines.
Fix	Only when an administrator asks	Apply the remedy. Must be idempotent. Many detectors have no fix at all.

The separation is the point. A scan that can also write is a scan you cannot safely run often; keeping the read path pure is what lets a check run hourly without anyone worrying about it.

Each detector also declares its severity range, its default scan interval, the parameters a tenant may tune, and two flags that the rest of the product reads: which lifecycle phase its findings belong to (see below), and whether its fix actually changes anything.

That second flag exists because a fix button that cannot work is worse than no button. Some detectors deliberately have no automatic remedy — a separation-of-duties conflict is the clearest case, because which side of a toxic combination to give up is a business decision that nothing in a database can make. Those detectors declare themselves unfixable and the surfaces offer the real per-finding actions instead. The flag defaults to "not fixable", so a detector author who forgets it degrades to a missing button rather than a lying one.

Sixteen of the 41 checks carry a fix that changes something. For the remaining twenty-five, the finding is the product: it tells you what is true, where, and who should decide — and the decision is made on the surface that owns the object, not here.

What the checks actually look for

The list moves, but the shapes are stable. A representative sample:

• Governance that resolves to nobody — an object with no owner anywhere in the ownership cascade; a system whose owner has been terminated; a terminated owner still holding objects, where the fix reassigns them to the manager; a pending decision assigned to someone who is no longer active.
• Access that nobody is using — assignments idle beyond the dormancy threshold, and API credentials that are dormant, expired or scoped wider than they are used. The assignment check is gated on whether the system can actually report usage and has genuinely reported some, so "not tracked" never reads as "never used".
• Access that should not coexist — separation-of-duties conflicts, single-value and seat conflicts, privileged entitlements sitting on a personal rather than an administrative account, and identities holding far more than their peers.
• Configuration that will fail later — read/write parity violations, where the rules that classify and correlate accounts disagree with the mappings that create them; an account type whose auto-create setting contradicts its system; references pointing at records that no longer exist.
• Systems and data going quiet — a connector that has not synced within its threshold, incomplete HR data on identities, file shares exposed more widely than expected.

Why waiting is usually the safer choice

Almost every check does nothing on its own, and exactly one does. That ratio is a decision, not an oversight.

For configuration hygiene, waiting costs nothing. A mapping that will orphan the accounts it creates, an entitlement nobody holds, an account type with a contradictory auto-create setting — none of these get worse while an administrator reads them, and any automatic "correction" would be a guess about intent. Guessing wrongly here is expensive and quiet: the platform would have made a governance decision that nobody reviewed, and it would show up months later in an audit as an unexplained change.

The exception is when the blast radius grows while you wait. A grant policy that scopes access by referring to an organisational unit which no longer exists is not merely misconfigured — it is a live rule evaluating against a broken condition, and the population it grants to can widen with the next reconciliation run. Here, doing nothing is the risky option. So this one check disables the offending policy — or marks the affected role for decommission — on first detection, and then still raises the finding for a person to re-target properly. Its administrator-triggered fix is deliberately empty: the defensive step bought time, it did not decide anything.

Three constraints keep this honest:

• A defensive action runs once, on the first appearance of a specific finding, and never again on the same one.
• It is recorded, not silent. The finding carries when the action ran, a one-line summary, the reasoning, and a structured before-and-after for each object touched — "policy Legacy Finance: enabled → disabled". A change with no record would be indistinguishable from drift.
• It can be switched off per detector, per tenant, without disabling the check itself. An organisation that would rather see the finding and act on it themselves can have exactly that.

If a defensive action fails, the finding is still raised as an ordinary open finding. The platform does not retry it and does not pretend it happened.

⚠ The Advisor does not run your governance for you.

Beyond the single narrowly-scoped defensive case above, nothing here changes access, revokes anything, or reassigns anything without an administrator asking for it. Applying a fix is a deliberate act by a person who has taken the finding on: the fix action is restricted to whoever claimed it, so oversight and execution stay distinguishable in the audit trail.

Findings are keyed to their target, not to the scan

Every finding carries an identifier derived from the check and the specific thing it is about. That one property does most of the work:

• A repeat scan updates rather than duplicates. The same broken policy found on Tuesday and again on Wednesday is one finding with a fresher timestamp, not two. Without this, a check running hourly would bury its own signal within a day.
• A finding that goes away is superseded, not deleted. The condition resolving means the row moves to a superseded state and stays readable. An auditor can still see that it once existed, when it appeared, and when it stopped being true.
• A finding that comes back re-opens the same row, so its history stays in one place rather than fragmenting across identical-looking entries.

Alongside those, an administrator can dismiss a finding permanently, or snooze it until a date — a snooze that expires re-opens on the next scan, which is the difference between "not now" and "never".

Where a finding goes

Every finding resolves to a curated destination when it is first raised: the security team, the object's owner, the connector's owner, an HR data steward, the subject's manager, or the IAM administrators. That resolution happens once, at scan time, and is stored on the finding — so the inbox can show a person work that is genuinely theirs rather than pooling everything to administrators.

Two details are worth knowing because they are where routing usually goes wrong elsewhere:

• A route that falls back says so. If the object owner cannot be resolved, the finding falls back to the administrator pool — and its label is rewritten to read "IAM admin — object owner unresolved" rather than silently keeping the original wording. Otherwise the resolved names read as though they were the owner.
• A route that resolves to nobody is marked, not hidden. After the fallback, a finding with no recipient is flagged as such. Same posture as review coverage, though the two now differ in where they land: a review step always terminates at somebody (worst case the IAM team), so its gap is an object with no clock; a finding can genuinely end with no recipient, and then it says so rather than becoming a quietly empty list.

An administrator can reassign a finding to a different destination, or claim it personally. Findings also fan out as notifications on first appearance, to any combination of platform roles, groups and named people configured per detector.

Per-tenant configuration

Detector defaults live in code; a tenant holds only its deltas. Each check can be configured independently:

• Enabled or disabled, per detector.
• Scan interval. Defaults run from hourly to weekly depending on the check. Setting it to on demand only means the scheduler will never run it again — the check still works when triggered manually, which is a legitimate choice and an easy one to forget.
• Notification routing — which roles, groups and individuals to tell when this check first raises something.
• The defensive-action toggle described above.
• Detector-specific parameters — thresholds, excluded systems, which HR attributes count as required for which kind of identity, and so on. These are validated against the detector's declared schema on save: an unknown key is rejected with a field-level error rather than silently ignored, because a typo that falls back to the default is a check that is not doing what its configuration says.

Each detector also carries its own health alongside its configuration — when it last scanned, its last error, and a consecutive-failure count — and a failing detector is isolated: its error is recorded, and the remaining checks in the same pass still run. Reading those fields is a scheduled habit rather than a one-off; the cadence is set out in operating rhythm.

Setup mode, and the wall of red

A brand-new tenant used to open on roughly a dozen critical findings. Every one of them was accurate. Every one of them said, in substance, governance is not configured yet: no approval rule exists, no review rule covers anything, these objects have no owner, this HR data is incomplete, nothing has ever been requested from the catalogue.

That is a product defect, not a feature. A first impression of eleven red items teaches exactly one lesson — that red does not mean anything here — and it is a lesson people keep. Worse, it hides the findings that would matter on day one, and it makes the honest choice (surfacing gaps rather than defaulting to a comfortable green) look like a failure of the product.

The fix is a lifecycle phase on each detector:

• Setup-phase checks (14 of the 41) are coverage gaps that fire at close to 100% on a fresh tenant precisely because configuration has not happened yet.
• Governance-phase checks are real decisions, drift and risk — a separation-of-duties conflict, an orphaned account, a dangling reference, unused privileged access. These matter on day one and every day after.

A tenant is in setup mode until an administrator says otherwise. While it is, setup-phase findings are held out of the working inbox and its counts. They are counted instead on the Go live phase of the setup journey — which says how many are being held back and links straight into the advisor to work through them. They are not suppressed and not deleted; they are put where they read as work remaining, which is what they are. Governance-phase findings flow to the inbox regardless of mode, because a real conflict is still a real conflict on an unconfigured tenant.

Going live is an explicit, audited act. It is not inferred from a first successful sync, a first policy, or any other proxy, because every one of those proxies is wrong for someone: a partner staging a tenant for a client syncs long before anyone should be answering approvals. Flipping the switch — in either direction — writes an audit event naming who did it.

One practical consequence, worth knowing before you are surprised by it: if an inbox suddenly fills with setup-shaped findings, someone has flipped the tenant back to setup mode. The estate has not collapsed.

What this does not do

• It is not monitoring. These checks read governance state in the platform's own database. They do not watch traffic, sign-ins or behaviour, and nothing here detects an attack in progress.
• It is not complete by construction. Findings exist because someone wrote a check for that state. A problem nobody has written a detector for produces no finding, and a silent detector and an absent one look identical from the outside.
• A finding is evidence, not a verdict. Severity is assigned by the check, not by your risk appetite. Plenty of correct findings are, in a given organisation, acceptable — which is why dismissal and snoozing exist and are recorded.
• The fix, where one exists, is narrow. It applies the specific remedy the check describes to the specific target it found. It does not generalise, and it does not touch anything the finding does not name.

---

Further reading:

• Operating rhythm — how often to read these surfaces, and what healthy looks like
• Platform health — the wider operational picture the Advisor sits inside
• Read/Write Parity — the parity checks the Advisor surfaces
• Failed Jobs Queue — the other half of "something needs a person"
• Reconciliation — expected versus actual, and what drift means
• What we don't claim — the honesty posture these surfaces follow