Why it matters
Permissions express risk appetite per app. Docs assistants and customer chatbots should not share identical rights. Permissions make differences explicit and auditable.
Permission changes are production changes deserving release notes and regression probes.
Enterprise security questionnaires now ask which knowledge principals may read at answer time. Permissions diagrams belong in RFP responses.
Permission expansions during incidents often never contract. Track temporary widenings with expirations or they become production defaults.
How it works
Model app roles: allowed collections, citation requirements, prohibited domains, escalation triggers.
Version policies and attach diffs to releases. Support should know scope changes.
Diagram permissions per app for legal and support stakeholders.
Simulate downgrades in staging to find hidden collection dependencies.
Attach permission diffs to internal release notes. Support should know when bots gain or lose collection access.
Simulate permission downgrades in staging before production cuts. Hidden dependencies on soon-to-be-removed collections surface early.
Example
Nintendo grants the Help Center bot read on public-safe collections only. The internal enablement copilot adds internal playbooks with stricter logging and no customer channel export.
Common mistakes
- 1Copying human folder permissions without AI use case review
- 2Permissions that cannot express collection-level scope
- 3Emergency widenings that never get reverted
Your AI does not need more access. It needs the right access.
Set policies that control what each AI application can read, cite, and answer from.
See AI access policies