Documentation / Platform glossary / Allowlist
An allowlist names what is explicitly permitted, and everything absent is refused. It is the inverse of a blocklist, which names what is forbidden and permits the rest. The difference decides what happens when something new appears that nobody anticipated.
The two models fail in opposite directions. A blocklist must enumerate every bad case, so anything unanticipated is permitted by omission — which is why blocklists degrade over time as new cases appear faster than they are added. An allowlist must enumerate every good case, so anything unanticipated is refused, and the omission surfaces as a support request rather than an exposure.
Allowlisting is the stronger control wherever the set of legitimate cases is knowable and reasonably stable: permitted script origins, approved integration endpoints, or the specific exceptions to an access policy.
The essential discipline is treating entries as decisions rather than settings. Each should record who requested it, why, what scope it covers, and when it should be reviewed. An entry added during an incident and never revisited is indistinguishable from a permanent weakening of the control — and in aggregate, undocumented entries are how an allowlist quietly becomes a blocklist.
Scope is the other half of that discipline. An exception granted for one organization, one integration, or one endpoint should apply only there. Broadening an entry because narrowing it is inconvenient converts a specific exception into a general one.
Allowlists are how exceptions stay governed. When an automated control affects legitimate work, the choice is between a documented, scoped, reviewable exception and an informal workaround — and the workaround is what auditors find.
Reviewability is the practical test. An allowlist nobody reviews accumulates entries whose original justification has expired, which is why a review date matters as much as the entry itself.
QueryTek records controlled exceptions with a scope and a reason so they can be reviewed rather than accumulating silently, and keeps each exception inside the tenant boundary it applies to. Specific entries and policy configuration are not published.
