Permission boundaries

  • Application target: one-factor Authelia for every route, API and asset that exposes private data.
  • Identity: only the Remote-User value overwritten by nginx from the successful authentication subrequest may identify the operator; browser-supplied identity is not trusted.
  • Browser credentials: provider tokens and seat control tokens never enter page payloads, screenshots, receipts or public documentation.
  • Public wiki: publishable architecture only. Private operator data must live under a separately built and gated /private/ companion; public indexes, feeds and sitemaps may not contain it.
  • Retrieval: admit sources before content access, with project and identity authorization. Exclude protected and fenced sources; an authenticated operator is not automatically entitled to every project corpus.
  • Fences: WRDP, quiz, triv, wp-cli and Atlas are excluded. Source-code integration references in other projects remain read-only.
  • Chat: answers/search only, retrieval-only tools, no more than one child process at a time, existing omp authentication, no model or provider substitution.
  • Mutation flags: seat control, editor chat, memory writes, knowledge edits, skill installation and ledger edits remain OFF at the server. A disabled button alone is not a permission boundary.
  • Future activation requires a separately reviewed authorization and effect boundary; this delivery does not activate it.
flowchart LR
  Request --> Auth[Authenticate at edge]
  Auth --> Admission[Authorize source before retrieval]
  Admission --> Read[Read-only response]
  Mutation[Mutation request] --> Deny[Server-side denial]