2026-06-28 · 12 min read
AI Permissions: What Your Chatbot Should Never Be Allowed to Know
A master key to company knowledge is a liability, not a feature.
Wiki Editorial Team
Writing about the knowledge, permissions, and systems behind trustworthy AI applications.
The master key problem
The fastest way to ship a chatbot is to point it at everything your company has ever written. Confluence, Drive, Slack exports, ticket history, draft PRDs, half-finished policy docs. Retrieval works on day one. Then a customer asks about roadmap timing and gets an answer stitched from an internal planning doc. Or a prospect learns about unpublished pricing from a spreadsheet labeled Q3 draft.
That failure mode is not mysterious model behavior. It is access control treated as an afterthought. AI permissions define which collections and documents each application may use for each audience, what happens when no approved source exists, and whether citations are required. Without explicit rules, retrieval becomes a master key to company knowledge.
This article is practical guidance for teams building customer-facing and internal AI, not legal advice and not a security audit checklist. Permissions reduce risk when implemented carefully and tested before launch. They do not guarantee zero leakage on their own. Pair access policy with verification, answer testing, and human review on sensitive topics as your organization requires.
If you are comparing broad-index chatbots to governed knowledge, read chatbot vs knowledge base. For why retrieval alone does not decide trust, see RAG is not a source of truth.
What public AI should not access
Public chatbots and docs assistants should use allowlisted, reviewed, public-safe collections. Treat everything else as out of scope until a human explicitly approves narrower exceptions. The list below is representative, not exhaustive for your company.
Internal operations and strategy
Runbooks with infrastructure details, incident postmortems, unreleased product plans, competitive analysis marked internal, hiring pipelines, and executive strategy notes belong outside public AI scope. Customers do not need them to reset a password. They should not see them because an embedding index was overfed.
Draft and unverified content
Draft policies, documents in needs review status, and working notes without verified approval should not feed customer-facing applications. Retrieval does not distinguish draft from final. Your permission layer must.
Customer-specific and employee data
Ticket transcripts with PII, account records, compensation bands, and employee handbooks meant for staff only are common leakage sources when one index serves every use case. Public AI should answer from generalized approved docs, not from data stores that require authentication your chatbot does not perform.
Legal, security, and sensitive communications
Legal strategy memos, active dispute details, vulnerability notes before disclosure, and privileged communications are high-impact if surfaced. Even paraphrased summaries can harm trust or create obligations your team did not intend. Default deny is appropriate until counsel and security stakeholders define narrow, reviewed exceptions.
Think in audiences and applications
One chatbot with one index rarely matches how your company actually talks to people. Customers, authenticated users, partners, employees, and admins need different boundaries. So do separate products: public support, docs assistant, sales copilot, and internal ops agent.
AI applications as separate actors
In Wiki, an AI application models each assistant independently: public support chatbot, docs assistant on your help center, internal copilot for support staff. Each application gets its own policy instead of inheriting a workspace-wide dump of all collections. That separation is how you keep a helpful internal tool from becoming a template for public leakage.
Audiences map context to policy
Audiences describe who is asking: anonymous visitor, logged-in customer, employee, partner admin. The same question may warrant different sources. A logged-in customer might see account-management docs that anonymous visitors should not. Policies attach to application plus audience pairs so you are not guessing at runtime.
Internal AI still needs boundaries
Internal copilots often need broader access than public bots, but broader does not mean unlimited. HR, finance, and security content may still require deny rules even for employees. Separate sales and support copilots if their allowed claims differ. Overlap creates inconsistent answers and harder audits.
| Application | Usually allowed | Usually denied |
|---|---|---|
| Public support chatbot | Verified help articles, public policies, approved FAQs | Internal runbooks, drafts, roadmap, employee docs |
| Docs assistant on help center | Published docs site content from verified sources | Unpublished drafts, internal-only collections |
| Support agent copilot | Internal troubleshooting, verified public docs | Unreleased product plans, raw legal strategy |
| Sales enablement copilot | Approved positioning, pricing sheets with review dates | Discount authority memos, customer-specific contracts |
Build a practical access policy
An AI access policy states which collections an application may retrieve for a given audience, whether citations are required, and what happens when no approved document supports an answer. Policies should be readable by operators and testable before launch.
Start from allowlists, not blocklists alone
Blocklists catch known bad paths. Allowlists define the approved surface public AI can use. For customer-facing bots, begin with collections that already have owners, review cadence, and verified publishing rules. Expand only when new content passes the same gates. AI permissions in Wiki express those rules in an access matrix so you can see application and collection interactions at a glance.
Policy dimensions beyond on/off
Useful policies specify more than allowed or denied. Citation-required rules force source-backed answers where auditability matters. Unavailable rules define behavior when retrieval finds nothing approved: refuse, escalate, or offer a human handoff. Restricted rules can permit retrieval but block direct quotation of sensitive sections. Match policy language to what your answer tests actually assert.
Align with citation-backed support
Permissions and citations work together. Allowing a collection means nothing if the model cites the wrong doc or fabricates a link. Read the complete guide to citation-backed AI support for test cases that catch internal source leakage and fake citations. Access policy defines eligibility. Answer testing confirms behavior.
Explicit deny rules
Collection-level allowlists miss edge cases inside otherwise safe folders. A verified product collection might still contain one document with unreleased SKU notes pasted into a draft appendix. Document-level deny rules block specific items without dismantling the whole collection policy.
When to use document-level deny
Use deny when a single file is sensitive but the surrounding collection is public-safe. Use deny when legal asks to withhold a subsection while the rest publishes. Use deny when you are mid-migration and an old doc must stay searchable for humans but not for AI until archived properly.
Deny beats hope in prompts
Prompt instructions like do not mention roadmap are weak gates. Models follow retrieved text. If a roadmap doc is in the index, it may surface regardless of prompt wording. Deny at the permission layer so retrieval never sees the document.
Review denies on a schedule
Permanent denies need owners. Temporary denies need expiry or review dates like any other governance artifact. Otherwise you accumulate mystery blocks that confuse the next team and starve legitimate answers.
Test access before launch
Policies you never test are assumptions. Before customer-facing AI ships or after a material permission change, run structured access checks and answer tests together.
Use the Access Simulator
Wiki's Access Simulator shows what each AI application can retrieve for each audience before changes reach production. Query representative questions and confirm only expected collections appear. Probe questions designed to elicit internal content: roadmap, employee benefits, unreleased features, internal incident names. Failures belong in the simulator, not in a customer transcript.
Pair with Answer Playground
Access tests prove eligibility. Answer tests prove behavior: citations point to public docs, refusals trigger on account-specific data, conflicting sources do not produce overconfident blends. Re-run high-risk test cases after permission edits the same way you re-run them after doc updates.
Regression when collections grow
Every new import or collection merge is a permission event. A well-meaning import of support macros can drag internal tags into a public index. Schedule regression checks when integrations add documents, not only when models change.
Permissions are how you tell customer-facing AI what it may know. Deny rules, audiences, and tested policies turn a master key into a set of keys that match each job. That work is ongoing. Review access when org structure changes, when you acquire new doc systems, and when a single wrong answer reveals a gap you did not simulate.
Frequently asked questions
Related reading
RAG Is Not a Source of Truth
Retrieval can find context. It does not decide whether that context is current, approved, allowed for the audience, or safe to cite.
AI SupportThe Complete Guide to Citation-Backed AI Support
Customer-facing AI should show where the answer came from, know when it lacks an approved source, and escalate when documentation cannot support a reliable answer.
AI Knowledge ManagementWhat Is Wiki Management for AI Applications?
Wiki Management for AI Applications governs what AI can use, who can see it, whether it is current, and whether an answer can be trusted.