Quorra — Authorization model
Last updated: 2026-06-15 (consolidated from the retired household-agent/ vault files — see decisions.md)
This is the authoritative specification for what each principal may read and write across Quorra’s knowledge surfaces. It is enforced at the agent layer, keyed on the authenticated Authentik UUID — not at the filesystem level. Files on disk are not OS-permission-restricted; access boundaries are applied by Quorra at retrieval and action time.
This document was consolidated from the former
household-agent/access-policies.md,guest-policies.md, andrelationships.mdwhen those pre-DB vault files were retired. It preserves the design intent; much of it depends on subsystems not yet built. Each policy is tagged with its status.
Status legend
- Implemented — enforced in
quorra-apitoday. - Partial — partially enforced; the rest depends on an unbuilt subsystem.
- Design intent — specified here, not yet built; depends on a later milestone (mostly M2 RAG retrieval scoping and the guest/ward roles).
Identity is canonical in Authentik (UUID) plus the user_map_json resolution layer in
quorra-api. There is no separate member-registry file; the retired members.md is superseded.
Principals
| Principal | Description |
|---|---|
| Member | Authenticated household member with an active Authentik UUID |
| Admin | Member with admin role — member access plus the ability to change household config |
| Agent | Quorra acting in a member’s context — inherits that member’s access scope |
| Guest | Authenticated or session-based user with guest role (design intent — no guest role yet) |
Roles today are expressed through Authentik / user_map_json, not a vault file. The ward role
(restricted member with guardian oversight) is reserved design intent — do not repurpose the name.
Policies
Policy 1 — Member access to own vault — Design intent (M2)
A member’s agent context may read and write all content under members/<their-slug>/
(knowledge/, shared/). No other member’s vault is ever readable; the agent never infers,
guesses, or retrieves across member boundaries. (Vault retrieval is M2 RAG; not built yet. The
agent-memory/ subtree referenced by the original policy has been retired — agent cognition now
lives in the DB memories table.)
Policy 2 — Member access to household tree — Design intent (M2)
All members may read and write under household/, except household/finances/ which is
member-only (equal read access among members). Significant writes are logged.
Policy 3 — Cross-member sharing — Design intent
A member shares content with a specific other member by placing it under
members/<their-slug>/shared/with-<recipient-slug>/. When operating in the recipient’s context,
retrieval includes inbound shares addressed to them. The agent never creates or modifies a share
without the sharing member’s explicit instruction, and never confirms or denies content in another
member’s vault.
Policy 4 — Guest access — Design intent (guest role)
Guests have read-only access to a subset of household/ (see Guest scope below), never to any
member vault, household/finances/, or household config. Guests accumulate no persistent memory.
household/emergency/ is always readable by design, for safety.
Policy 5 — Agent-memory partitioning — Superseded
The original policy scoped each member’s vault agent-memory/ to that member’s context. Agent
cognition now lives in the DB memories table, scoped by user_uuid (NULL = household). The
partitioning guarantee is preserved structurally by that column, and household-scope retrieval
never returns another member’s user-scoped memories.
Policy 6 — Group mode (multi-member conversation) — Partial
In a group context (e.g. a Matrix room with multiple authenticated members), retrieval is limited to household content and content shared with all present participants — never individual member vaults. Implemented today: the finance budget privacy boundary enforces exactly this shape — a per-request participants-intersection over budget-access rows makes a personal budget mechanically unreachable in any session where a participant lacks access. The general vault-retrieval form of this policy is design intent pending M2.
Policy 7 — Existence confidentiality — Partial
The agent never confirms or denies the existence of content in another member’s vault. If asked “does Bob have notes about X?”, the correct response is to decline — not to say “no”, which is itself a disclosure. Currently a prompt/behavioral guarantee; will be structurally enforced once M2 vault retrieval exists.
Policy 8 — Audit logging — Implemented
Significant agent actions (Tier 1+) are written to an append-only audit log at /data/audit.log
(config audit_log_path) and dual-written to the SQLite audit_log table. (This supersedes the
original policy’s household-agent/logs/ and per-member agent-memory/logs/ destinations.)
Guest scope (design intent)
When the guest role exists, a guest session:
- Always readable:
household/emergency/ - Readable by default:
household/home/,household/calendar/,household/pets/ - Never readable:
household/finances/,household/subscriptions/, anymembers/content, household config - Conditionally readable: content a member explicitly shares with the guest for the session
Guest behavior: identifies as guest mode and narrows retrieval accordingly; retains no memory across sessions; writes nothing persistent; never discloses member names, slugs, or identities; takes only actions a member explicitly authorizes for the session.
Household topology (design intent)
Structural relationships between members (partner, sibling, parent-child, housemate, and the
future guardian-ward) inform coordination, addressing, and the future ward/guardian model. This is
structure only — who is related to whom — not relationship history or personal notes, which live
in member vaults. No topology is defined yet (single-member household).
Ward role (reserved — do not build yet)
A ward is a restricted member with guardian oversight. When added: the ward’s vault is structured
like a member’s with a guardian overlay; the guardian may read it (opt-in, agent-enforced); the ward
has no household/finances/ access and guest-like restrictions on some household content; graduation
ward → member is a manual admin role change. Do not implement until the role is explicitly added.