Employee copilots should not see everything.
Employee copilots stay scoped to internal collections. Public-safe knowledge and internal notes stay split. Each AI Application gets its own policy.
Scope employee copilots to internal collections with permission-aware retrieval. Keep public-safe knowledge and internal notes in separate collections.
Internal copilots fail in two directions.
Give an employee copilot every folder and it will surface compensation notes, unreleased pricing, or a draft legal memo in a Slack thread. Give it nothing useful and people go back to searching Drive.
Internal AI copilot permissions are not the same as Google Drive sharing. A human who can open a doc is not the same as a copilot that can quote it to anyone in the channel.
The other failure is mixing surfaces. A public chatbot and an internal copilot should not share one unscoped index. Public-safe collections and internal collections exist so those applications stay apart.
What to do for an internal copilot
Build the copilot as its own AI Application with a policy, not as a second prompt on the public index.
- Step 1
Split public-safe and internal collections
Help articles customers may see go in public-safe collections. Runbooks, escalation notes, and employee-only policies go in internal collections.
- Step 2
Verify the internal sources too
Internal does not mean unreviewed. A stale runbook in a copilot is still a wrong answer, just an internal one.
- Step 3
Give the copilot its own AI Application policy
Permission-aware retrieval scopes the copilot to the internal collections it is allowed to use. The public chatbot policy stays separate.
- Step 4
Test questions employees will actually ask
Use the Answer Playground on onboarding, incident, and policy questions. Confirm the copilot cannot retrieve public-bot-only or unverified drafts you did not allow.
How Wiki scopes internal AI copilot permissions
Wiki models each copilot as an AI Application with a policy over collections. That is live. There is no claim here of role-directory sync or a native chat app.
Public-safe versus internal collections
Collections carry visibility. Customer-facing apps stay on public-safe knowledge. Employee copilots stay on internal collections.
Permission-aware retrieval
Each AI Application policy decides which collections may be retrieved. The copilot does not inherit the public chatbot's scope.
Verified sources
Internal sources still go through review before they are allowed for AI use.
Answer Playground
Ask the employee questions you care about and inspect which collections and citations the copilot used.
Wiki Connect
If you already have an internal bot, call the HTTP API with that application's key so answers stay policy-constrained.
Questions teams ask first.
- What are internal AI copilot permissions in Wiki?
- An AI Application policy that scopes an employee copilot to internal collections. Public-safe collections stay available to public apps. The copilot does not get a master key to every document.
- Can a public chatbot and an internal copilot share sources?
- They can share a workspace. They should not share an unscoped index. Put customer-facing sources in public-safe collections and employee-only sources in internal collections, then attach a policy to each application.
- Does Wiki read our identity provider to enforce roles?
- Wiki enforces collection and application policies you configure. It does not claim live directory sync or automatic role mapping from your identity provider.
- How do I test that internal notes cannot leak to a public bot?
- Keep those notes in an internal collection, attach only the copilot's policy to that collection, then ask the public chatbot the same question in the Answer Playground. The public app should refuse or answer only from public-safe sources.
Essays, tools, and the product.
From the blog
AI Permissions: What Your Chatbot Should Never Be Allowed to Know
The biggest AI knowledge mistake is giving every chatbot access to every document. Permissions should be explicit, tested, and audience-aware.
What 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.
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.
Tools
Your AI is already talking.
Make sure it knows what it is talking about.