Audit knowledge-base access with allowed and denied tests

Turn “permissions look right” into test cases

An admin screen shows intended configuration. It does not prove the experience of a contractor, new hire, client guest, or search integration. Build the audit around representative identities and actions. NIST defines least privilege as restricting a user or process to the minimum resources and authorizations needed for its task. In a small team, that means testing a narrow role before granting a broad workspace role for convenience.

Start with a content map: public material, team-wide internal material, project-restricted material, and owner-only administration. Add the system that grants access—direct share, group, parent folder, inherited space role, or connector. Do not place passwords, private document titles, or sensitive excerpts in the audit log; use stable test labels.

Pair every allowed test with a denied test

For each role, create a small matrix. Test from a real non-admin account or an approved test identity, not an impersonation view alone.

Use direct URLs for denied tests. Search-only testing can miss a leak because indexing is delayed; navigation-only testing can miss a file that is accessible by link. Check search, direct open, preview, download, comments, edit, share, and delete only where relevant. Record expected and observed behavior, account used, timestamp, and the permission path that explains the result.

Inspect inheritance and exceptions

Google’s folder-sharing documentation illustrates why inheritance needs attention: files in a shared folder receive the folder’s access, a file can retain higher access granted directly, and a more restricted item may need a limited-access folder. Other systems use different labels, but the audit question is the same: is access coming from the item, its parent, a group, or a general-link setting?

For every unexpected success, trace all paths before removing access. A person may be present directly and through a team group. For every unexpected denial, check whether the parent permits discovery but the child blocks content, whether the wrong account is active, and whether a connector uses a different service identity. If the system has search or assistant features, rerun a narrowly phrased search from each role after permissions settle. The archive’s workplace-search permission note is relevant because a search layer can faithfully reproduce an underlying access mistake.

Separate the finding from the fix

The auditor should document the smallest proposed change and its likely blast radius. Do not immediately remove a group from a parent folder just to fix one file; that may break dozens of legitimate paths. Prefer moving the sensitive item, narrowing a direct grant, or creating a purpose-built role when supported. Retest both sides after the change: the leak must close and the required work must still function.

A hypothetical example: an external reviewer should comment on a draft but not browse source interviews. The audit uses a guest account to open the draft, add a comment, attempt the source-folder URL, search a distinctive test phrase, and try the Share control. The expected outcome is documented before the clicks. This is a process example, not a report of a real system test.

1. Define representative roles and minimum required actions.
2. Write allowed and denied cases before changing permissions.
3. Test search, direct links, and relevant write actions as non-admin users.
4. Trace inherited, group, direct, and general-link access.
5. Retest required access after closing any unexpected path.

Repeat the audit when a teammate leaves, a connector is added, or a folder moves. A one-time clean result does not guarantee the next inheritance change will remain clean.