A wiki's permission model determines who can read, edit, delete, and administer. Different models suit different organizations.
This page covers the major models and the patterns for managing access well.
Users have roles: viewer, editor, admin. Roles have permissions.
Viewer: read all
Editor: read all + edit
Admin: read all + edit + admin
Simple. Works for small organizations or where everyone has similar access needs.
Users belong to groups. Groups have permissions on specific resources.
Group "Engineering": read /engineering, edit /engineering
Group "Finance": read /finance, edit /finance
For organizations with departmental boundaries.
Per-resource access control list. Each page (or section) has its own ACL.
Page X: alice can edit; bob can read; engineering group can read
Most flexible; most overhead. For wikis with sensitive content.
Anyone can read; specific users can edit.
For open wikis (Wikipedia-style); some internal "transparency" cultures.
The standard set:
Different wikis combine these differently. Check what your platform supports.
Public wikis: default allow (everyone reads; few restrictions). Corporate wikis: default deny (start restricted; grant explicitly).
Page inherits parent permissions unless overridden. Reduces ACL bloat.
For Confluence-style hierarchical wikis, this is essential.
Roles within groups: "engineering admin" has admin within /engineering only.
For larger organizations.
Grant access for a specific period. Auto-expires.
For contractor access; temporary collaboration.
Allow group X; deny user Y (who's in group X). Removes user Y specifically.
Useful but adds complexity.
Distinct from authorization. Authentication: who is this user. Authorization: what can they do.
Wiki manages its own user accounts. Username/password.
For small wikis. Operationally simple; security depends on wiki's auth.
Users authenticate via central identity provider (Google, Microsoft, Okta, GitHub).
For organizations with central identity. Stronger security; user provisioning automated.
Users come from LDAP. Groups come from LDAP.
Common for enterprise wikis. Permissions managed in LDAP, not in the wiki.
Authenticated via SSO; some local accounts for special cases (admins, automation).
Users have only the permissions they need. Not "admin for everyone for convenience."
For sensitive operations, request access; granted temporarily; auto-revokes.
For most wikis, simpler permanent access works. JIT for high-stakes actions.
Groups owned by specific people who decide membership. Avoids "who's in this group" being a free-for-all.
Quarterly: review access. Who has admin? Should they still? Remove inactive users.
Log permission changes. Who granted what to whom.
For regulated environments, required. For others, valuable.
The Wikantik project uses:
/admin/security UI)/admin/groups[{ALLOW view Admin}]() syntaxRestServletBase.checkPagePermission()The model is hybrid — role-based default with per-page ACL override.
A restricted page never appears in an agent's retrieved context, search
results, or a RAG context bundle for a caller who lacks view permission. View
ACLs are enforced on the read path, not just in the UI: every agent-facing
surface runs its candidate pages through a session view gate
(PageViewGate) before returning them —
/api/*, /wiki/{slug}?format=md|json),/knowledge-mcp retrieval and Knowledge-Graph tools
(retrieve_context, assemble_bundle, search_knowledge, query_nodes, …), and/api/bundle (the RAG context bundle).So restricted content cannot leak into search, retrieval, or a context bundle through the agent interface. (The public RDF/SPARQL surface applies the same guest-view ACL split — only anonymously-viewable pages are materialized.)
Not to be confused with KG Inclusion Policy. View-ACL read-path enforcement is the security boundary and is always on. KG Inclusion Policy is a separate curation control that decides which (already-viewable) pages contribute entities to the Knowledge Graph — it is not access control, and its admin-bypass on KG reads is for curators only and never bypasses a guest's view ACL. KG-including a page does not make a restricted page visible; KG-excluding a page does not hide a viewable page from page search.
Everyone is admin "for convenience." Compromised account = compromised wiki.
Per-page ACLs accumulate; no one knows who has access to what.
For wikis with thousands of pages, sprawl becomes unmanageable. Use group-based access where possible.
Permissions changed frequently for ad-hoc needs. Hard to audit.
Standardize: groups for common needs; ACLs for exceptions.
Permission changes happen; no record. Can't investigate after the fact.
Users left the company; still have access.
Auto-revoke on user deactivation; periodic review.
For public wikis; the right answer. For internal wikis with sensitive content; the wrong answer. Verify what's intended.
For new internal wikis:
For public wikis: anonymous read; authenticated edit; admin role for trusted users.
Depends on culture. Wikipedia: yes, anyone edits. Internal corporate: usually no.
For public wikis: yes (the point). For internal: rarely.
Per page: who edited what. Most wikis show this; some hide for privacy reasons.
Often a separate, more restricted permission. Deletion is rarely needed; risky.