Glossary
The vocabulary in these pages is mostly ordinary, and that is the risk: identity, account, entitlement, grant, context and drift all mean something narrower here than in conversation, and reading one of them loosely makes a whole page mean something else.
Two conventions are worth knowing before the list. First, access is held in a chain — an identity holds an account on a system, and that account holds an entitlement; nothing is ever held by an identity directly. Second, the comparison the product turns on is labelled Expected and Actual, where much of the industry says SOL and IST; both of those appear below so a reader arriving from another product can translate.
Entries are alphabetical. Where a term has a page behind it, the link goes to the page rather than a longer definition here.
A–C
Access review — The periodic or event-driven confirmation that access is still correct: a reviewer confirms or revokes it, and the decision is recorded. One engine drives all three trigger types (a rolling clock, a bus event, a fixed-window campaign). Widely called certification or attestation elsewhere. → Access reviews
Account — A login or object on one connected system: an Entra user, an Active Directory object, a Salesforce user. One identity may hold several on the same system — an ordinary one and an administrative one — and an account belonging to no identity is an orphan. Entitlements are held through an account.
Account type — A category of accounts on one system, carrying its governance scope, the filter that finds it, and which attributes may be written back. A type is a purpose — personal, administrative, service, break-glass, shared, guest — and never a lifecycle state: a disabled personal account is still a personal account. → Account types
Actual — What the connected systems currently report: the accounts, entitlements and grants seen by the last import, with the attribute values that came with them. It is read from the imported model rather than queried live, so any verdict is only as fresh as the sync behind it. Called IST in much of the industry. → Reconciliation
Advisor — The single inbox of findings raised across the tenant by detectors: dormant access, ownership gaps, read/write parity mismatches, toxic combinations, over-scoped credentials. One inbox rather than a signal per feature. → Platform Advisor
Agent — Two unrelated things share this word, and the collision matters. A tier-3 agent is the lightweight process running inside the customer's own network that reaches systems the SaaS control plane cannot, and resolves credentials locally so no secret crosses the wire (→ Tier-3 hybrid architecture). An AI agent is a kind of identity. Where either could be meant, these pages say "tier-3 agent" in full.
AI agent — An identity representing software that acts without a person at the keyboard, governed as a non-human identity plus a profile recording its purpose, its autonomy tier and whom it acts for. What is governed is the identity the software authenticates as, not its behaviour. → Governing AI agents
Application — A business application onboarded as a unit of governance, fronting the systems and directory groups that actually implement it. It is the level at which the business asks and an owner approves, rather than a label over a group.
Application fronting — Putting a directory group behind an onboarded application: an application role is minted containing the group, and the raw group stops being individually requestable. The membership that lands in the directory is identical; the governance around it is not. → Access requests
Approver chain — The ordered steps that decide a request or a review. Each step names its approvers and its quorum, and the next step opens only once the previous one is satisfied. One shape, shared by approval rules, review rules and role formalisation. → Approver chains
Assignment — The reader-facing name for a grant, and the name of the surface that lists them as edges — identity to account to entitlement, with provenance and status. The same object: "grant" is used where the edge itself is the subject, "assignment" where the access is.
Break-glass — Pre-authorised emergency access. Activation is instant and has no approval step; what makes it governed is that eligibility was decided in advance, the window is finite and closed by the platform, the activation is recorded at critical severity with a mandatory reason, and its use triggers a review by someone who did not activate it. → Privileged access
Certification — See Access review. The word survives in configuration and exports; the interface says access review.
Connector — The configured integration with one system: its engine, credentials, schedule, mappings and rules. In the interface a connector and the system it reaches are one thing, found under Systems; "connector" is used when the integration itself is the subject.
Context — An organisational grouping an identity belongs to through its attributes: department, cost centre, location, legal entity, job function, project, programme, customer. Contexts carry owners and can scope roles and rules, which is what makes "the owner of the department this machine belongs to" a resolvable answer. Presented in the interface as business objects.
Correlation — Linking an account to the identity that owns it, by rule — typically an identifier match such as email to user principal name. Governance runs through the correlated identity, so an account that correlates to nobody is an orphan and stays one until a human resolves it. → Account rules
D–I
Detector — One pluggable check inside the Advisor, scanning tenant state on its own cadence and raising findings. Each can be tuned or switched off per tenant. → Platform Advisor
Dormancy — Access not used within a threshold: 90 days by default for a person, 180 for a non-human identity, which legitimately runs quarterly. Only computed where the system can actually observe activity and has been observed at least once — anywhere else an empty last-used value means "not tracked", never "never used". → Non-human identities and ownership
Drift — Any difference between Expected and Actual. A reconciliation run sorts each pairing into exactly one of eight kinds in a fixed precedence — orphan account, disabled account, cardinality conflict, blocked provisioning, shadow, unapproved, missing, attribute drift. Drift describes; what happens to it is the system's own policy, and the default is not to delete. → Reconciliation
Entitlement — A right that exists on a system: a group, a directory role, a licence, a permission set. It is the thing that can be held; somebody holding it is a grant.
Evidence pack — A signed bundle produced against a framework template and a time window. The signature covers a canonically serialised manifest, not the archive bytes, and that manifest carries a digest of every file plus the claims made about them — so relabelling a control or under-reporting a row count breaks verification exactly as hard as editing the data. → Evidence and signed exports
Expected — The access that should exist for an identity, recomputed from live governance state on every reconciliation run: policy matches, role expansion, context-role bindings, single sign-on derivation, lifecycle windows, and the explicit one-time decisions that persist until something removes them. Called SOL in much of the industry. → Reconciliation
Grant — One account holding one entitlement — the edge a reconciliation run issues a verdict on. A grant carries every source that justifies it, so "held because a policy matches and because someone requested it" is representable and stays correct when one of the two lapses. See also Assignment.
Identity — The person, machine or agent being governed: the durable subject that accounts and access hang off. An identity is not a login — that is an account — and an identity that has been terminated keeps its record while its access is taken away.
Import — A read from a connected system, producing the Actual state. Imports are read-only by definition; writing back is provisioning, tracked separately. → Imports and schedules
IST — The industry's term for what this product calls Actual. Not used in the interface, though it survives in some API field names.
J–R
JIT elevation (just-in-time) — Privileged access granted for a bounded window and taken away by the platform when the window closes, rather than standing access somebody has to remember to remove. The clock is the control, and a revoke that fails surfaces as an exception rather than lapsing quietly into standing privilege. → Privileged access
JML (joiner, mover, leaver) — The three lifecycle events an identity passes through, detected from changes in the human-resources import. JML deliberately owns no access: it holds the tenant-wide settings — validity windows, leaver grace, mover treatment — and the monitoring, while the access itself comes from policies and reconciliation. → Joiner / mover / leaver flows
NHI (non-human identity) — A service account, system account, application, AI agent or internet-of-things device. The distinction earns its keep by changing behaviour: dormancy thresholds, the ownership cascade, peer comparison and attestation cadence all differ from a person's. → Non-human identities and ownership
Orphan — An account that correlates to no identity, so nobody is accountable for it. Reconciliation reports it and waits: deciding who an orphan belongs to is one of the four drift kinds that only ever resolve to a human decision.
Policy (access grant policy) — An attribute-matched rule that adds access to Expected for as long as it matches, and stops asserting it when it does not. Birthright access is a policy match rather than a separate mechanism, and a policy can grant a bare account without granting any entitlement on it.
Provenance — Why a grant exists. Sources recomputed from live state — a policy match, a role, a coupling, a retention window — are dropped as soon as they stop applying, and the access with them; explicit one-time decisions such as an approved request or an administrative grant persist until something explicit revokes them. Both can sit on the same grant. → Reconciliation
Provisioning — Writing to a connected system: creating an account, granting or revoking a membership, pushing an attribute. The opposite direction from an import, always through one engine and its gates, and a write that fails becomes a tracked job rather than a silent loss. → Failed jobs queue
Quorum — How many of a step's approvers must agree before the step passes: all, any, or n-of-m. → Approver chains
Reconciliation — The comparison of Expected with Actual, per identity, and the engine that acts on the difference. Not an overnight report: every convergence-shaped write is routed through it, which is why every safety limit on writing to a customer's systems sits on that one path. → Reconciliation
Requestability — Whether a right may be asked for in the catalogue, decided by four stacked layers — system, application, entitlement type, individual entitlement — where the most restrictive wins and a lower layer can never re-open what a higher one closed. Not the same as authorisation: whether a request is granted is the approver's decision. → Access requests
Risk score — A number from 0 to 100 built as a weighted sum: each component is a count times a per-unit weight, capped, with the total clamped. Every score stores its own breakdown, so an administrator can reproduce it by hand. Deliberately not a learned or behavioural model. Identities and entitlements are scored separately, answering who is risky and what is risky. → Separation of duties and risk
Role — A named bundle of entitlements held as one thing, with an owner and a reviewer chain. Holding a role expands to the leaves it contains, so the access it confers is visible rather than implied. → Roles and role mining
Role mining — Deriving candidate roles from the access people already hold, each proposal carrying its own per-entitlement evidence — how much of the cohort holds it, how many outside it do — so it can be judged on its own merits. Mining proposes; a named owner and a reviewer chain are what make a role real, and mining revokes nothing. → Roles and role mining
S–Z
SAPA (short-term access for privileged access) — The mode in which an approved request becomes a scheduled elevation window rather than a grant, so the approval and the elevation are one decision. The interface calls it scheduled elevation; the abbreviation appears in configuration and exports. → Privileged access
Separation of duties (SoD) — Rules declaring combinations of access that must never land on one person, each side expressed as a filter over entitlement attributes rather than a table of forbidden pairs — so a rule describes a shape and keeps describing it as the estate grows. Three enforcement actions exist; which side to remove when a conflict is found is never chosen automatically. → Separation of duties and risk
SOL — The industry's term for what this product calls Expected. Not used in the interface, though it survives in some API field names, such as the sources recorded on a grant.
Sync — One scheduled run of a connector's import. Used loosely for importing in general; where the distinction matters, an import is the read and a sync is the run that performs it. Sync intervals have a 15-minute floor. → Imports and schedules
System — A connected external system under governance: a directory, a human-resources source, a software-as-a-service application, a file share. Systems is also where a connector and everything configured on it are found in the interface.
Tenant — One customer's isolated space — its own identities, systems, configuration and audit trail. Isolation is logical rather than physical: tenants share a database, and the boundary is enforced twice, by application scoping and by database row-level security beneath it. → Tenant isolation
Further reading:
- Reconciliation — where Expected and Actual come from
- How the product is organized — where each of these lives in the interface
- What we don't claim — the words we deliberately do not use