slm-governance

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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:

```bash
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 personal data.

---

## require-login

When login is required, every operation on memories needs a signed-in user,
including the connection your assistant uses. SLM handles this at the daemon
level; agents never put credentials in tool calls. If a tool call returns an
authentication or permission error, you must:

1. Stop the current operation immediately.
2. Report the requirement to the user.
3. Never cache, retry, or work around the block.

In this mode, `include_global=True` and `include_shared=True` on `recall` are
quietly turned off while the recall policy forbids cross-profile reads (the
default), so an opt-in recall can come back with only personal facts. Do not try
to work around it. See `slm-scope`.

---

## Retention and lifecycle

Every memory moves through lifecycle states as it goes unused: active, warm, cold,
archived. Two tools set and inspect that, and a third runs the forgetting cycle.
They need the `power` tool set.

From qualixar/superlocalmemory, AGPL-3.0.

More from qualixar/superlocalmemory