/slm-governance

name: slm-governance
description: Governed-workspace behavior for SuperLocalMemory. Covers roles (admin/member/viewer) and company mode, who administers a company-mode workspace (a signed-in admin, or `slm team` on the SLM computer), `slm token show` in strict mode, what remote web apps can never see or change, retention and lifecycle settings, the audit trail, GDPR export and erasure, and how agents must behave when operating under workspace governance. The audit and retention tools need the power MCP profile. Agents must never bypass governance controls.
when_to_use: |
  - "What can I do in this workspace?" (role check)
  - "Move cold memories to archive after 60 days"
  - "Show the audit trail for recent memory operations"
  - "Export my data for GDPR compliance"
  - "Delete all memories about user X (right to erasure)"
  - "Turn on require-login for this workspace", "I'm locked out of company mode", slm team status
  - "The dashboard asks for a key" (slm token show)
  - Enterprise deployment with multi-team shared SLM
  - Compliance, audit, or data governance task
allowed-tools: audit_trail, set_retention_policy, get_retention_stats, get_lifecycle_status, compact_memories, consistency_check, recall, search, remember, Bash(slm:*)

slm-governance — Governed Workspace Behavior

SuperLocalMemory can run with named users and roles per workspace (company mode), keeps a compliance audit trail, applies a retention lifecycle, and ships GDPR export and erasure commands. This skill documents how an agent must behave in a governed workspace and what the governance tools really do. The MCP audit and retention tools are in the `power` tool set, not the default: if they are missing, tell the user to run `slm tools set power` and restart this app (see `slm-profile`). The `slm gdpr` and `slm team` commands work either way.

---

Role model

By default SLM is single-user: whoever runs it is the owner and nothing asks for a login. Company mode adds named users, each with one role per workspace (profile). A role in one workspace grants nothing in another.

| Role | Read | Write | Share (`shared`/`global` writes) | Delete | Manage users and settings | |------|------|-------|-------|--------|-----------------| | `viewer` | Yes | No | No | No | No | | `member` | Yes | Yes | Yes | No | No | | `admin` | Yes | Yes | Yes | Yes | Yes |

**Agent behavior by role:**

• **Viewer**: Only call `recall`, `search`, `fetch`, `list_recent` and other

reads. Never call `remember`, `update_memory`, `delete_memory` or any write tool. If a write is refused, say so: "This workspace is read-only for my role."

• **Member**: May write memories, including `scope="shared"` and `scope="global"`

when the user explicitly asks for them. May not delete memories or change users, roles or settings.

• **Admin**: Everything above plus deletion and user administration.

No MCP tool or `slm` command reports your role (only a signed-in dashboard session can ask the daemon, at `GET /api/rbac/whoami`). Do not guess it: attempt what the user asked and treat a permission refusal as final. Setting up users, roles and "Require login" is done in the dashboard under **Settings → Access**; there is no `slm user` or `slm role` command. The only company-mode commands are `slm team status` and `slm team policy` (next section).

Roles apply to every route that touches data, not only to `remember` and `recall`. That includes pictures, documents, connected folders and turning features on: reading a file by path, connecting a folder (`slm sources add`), turning on pictures and documents and cleaning up with `slm media gc --apply` or `slm media repair` need the owner or an admin. SLM's own data folder can never be named as a path or a source. With login required, every page of data (export, compliance records, profiles, learning and trust details) needs a signed-in user; a test walks every route so a new one cannot slip through.

---

Who administers a company-mode workspace

While users are enrolled and login is required, the install token or an API key alone no longer administers the workspace: any local program can fetch the install token, so it would let anyone switch company mode off. Administration needs one of these:

• **A signed-in admin** (a user with the `admin` role on that workspace),

through the dashboard.

• **`slm team` on the SLM computer**, which uses a private capability file that

only the user running SLM can read, so the owner can never be locked out even if every admin is:

slm team status                          # "Require login: on. Users: N."  (read-only, safe)
slm team policy --require-login on       # every user signs in
slm team policy --require-login off      # the machine owner is the user again

Run them as the same user that runs SLM, with the daemon running. Otherwise the daemon refuses them. Users, roles and sessions are kept when login is turned off. Switching the requirement off lowers protection for everyone, so do it only when the user asks for it in this conversation; `slm team status` first. With no users enrolled yet, the machine owner can still create the first administrator.

Strict mode: `slm token show`

With `SLM_REQUIRE_CREDENTIALS=1`, the dashboard is not handed the SLM key; the person pastes it into a one-time box. `slm token show` prints that key. It is a secret that opens write access: do not run it on your own, never paste it into chat, a memory or a log, and tell the user to run it in their own terminal. `slm rotate-token` replaces it (then `slm restart`).

What remote web apps can never do

A connected web app (see `slm-web-access`) cannot correct, delete, share or switch profile, cannot read another profile, and cannot change, delete, pin or replace a memory it is not allowed to see: it is answered as if that memory did not exist. It never sees memories that came from a connected folder, and sees a picture or page only when its text held no secret or perso