/slm-governance

name: slm-governance
description: Enterprise compliance and governed workspace behavior for SuperLocalMemory. Covers role-based access (admin/member/viewer), retention policies, audit trail, GDPR data export/erase, and how agents must behave when operating under workspace governance. Requires power MCP profile for audit/retention tools. Agents must never bypass governance controls.
when_to_use: |
  - "What can I do in this workspace?" (role check)
  - "Set a 90-day retention policy on this memory"
  - "Show the audit trail for recent memory operations"
  - "Export my data for GDPR compliance"
  - "Delete all memories for user X (right to erasure)"
  - "Configure require-login for this workspace"
  - 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, recall, search, remember, Bash

slm-governance — Enterprise Compliance and Governed Workspace Behavior

SuperLocalMemory supports enterprise deployments with role-based access control, retention policies, audit logging, and GDPR compliance tooling. This skill documents how agents must behave when operating in a governed workspace and how to use the governance MCP tools (available in the `power` profile).

---

Role model

Governed workspaces have three roles:

| Role | Read | Write personal | Write shared/global | Admin operations | |------|------|---------------|---------------------|-----------------| | `viewer` | Yes | No | No | No | | `member` | Yes | Yes | Yes (within access list) | No | | `admin` | Yes | Yes | Yes (unrestricted) | Yes |

**Agent behavior by role:**

• **Viewer**: Only call `recall`, `search`, `fetch`, `list_recent`. Never call

`remember`, `update_memory`, `forget`, or any write tool. If a write is attempted, fail gracefully: "This workspace is read-only in viewer mode."

• **Member**: May write personal facts and shared facts with permitted profiles.

May NOT write `scope="global"` facts without explicit admin authorization. May NOT call `set_retention_policy`, `audit_trail`, or `compact_memories`.

• **Admin**: Full access including governance tools in the `power` profile.

An agent operating in a governed workspace must check its role before any write operation. Role information is visible in workspace configuration or via `slm status --json` (the `role` field, if present).

---

Retention policies

Retention policies control how long facts are stored before they become eligible for decay. Available in the `power` MCP profile.

Set a retention policy

set_retention_policy(
  profile_id: str = "",   # "" = active profile
  days: int = 90,         # facts older than this become decay-eligible
  zone: str = "default",  # retention zone name
)

Retention zones let you apply different policies to different fact categories:

# Standard facts: 90-day retention
set_retention_policy(profile_id="", days=90, zone="default")

# Security findings: 365-day retention (compliance requirement)
set_retention_policy(profile_id="", days=365, zone="security")

Tag your facts with the zone name to route them to the right policy:

remember(content="Critical auth bypass in v2.1", tags="security,cve,finding", ...)

Check retention statistics

get_retention_stats()

Returns zone distribution, average fact age, and decay-eligible counts. Use this to verify policies are working as expected.

Check lifecycle status

get_lifecycle_status()

Reports the state of the retention and decay subsystem — whether decay cycles are running, when the next cycle runs, and any backlog.

---

Audit trail

`audit_trail` is available in the `power` profile. It returns a structured log of recent memory operations (writes, reads, profile switches, policy changes).

audit_trail(
  limit: int = 50,          # number of entries to return
  operation: str = "",      # filter by operation type (e.g. "remember", "forget")
  profile_id: str = "",     # filter by profile; "" = active profile
)

Use this for:

• Compliance reviews ("what data was written in the last 30 days?")
• Investigating unexpected memory changes
• Generating audit reports for data controllers

The audit trail covers MCP and CLI operations. It does not record the content of facts by default — only operation type, timestamp, agent ID, and fact ID.

---

GDPR compliance

Data export

SLM does not have a dedicated MCP export tool. For GDPR data subject access requests, use the CLI:

# Export all memories in a profile to JSON
slm status --json     # confirm active profile
slm list --limit 9999 --json > export.json

For a complete export including entity graph data, run:

slm status --json

Contact your workspace admin to arrange a full database-level export if the CLI output is insufficient for compliance purposes.

Right to erasure

To erase all memories for a subject or project:

# Step 1: preview what will be deleted (ALWAYS do this first)
slm forget "<subject or project name>" --dry-run --json

# Step 2: review the preview, then execute
slm forget "<subject or project name>" --yes --json

For targeted deletion by fact ID:

slm delete <fact_id> --yes --json

For data reconstruction prevention: after erasure, confirm the fact is gone by running `slm recall "<content>"`. A successful erasure returns no results. Never attempt to re-derive erased content from other stored facts.

---

require-login

When `require_login` is enabled in workspace configuration, agents must authenticate before any memory operation. SLM handles authentication at the daemon level — agents do not need to pass credentials in tool calls. If an agent receives an authentication error from any MCP tool, it must:

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