Memory governance

Shared memory your team can actually audit

When three developers are using Claude Code, Cursor, and Codex on the same codebase, Tages gives you one memory graph with provenance, RBAC, and an audit trail across every agent. Memory isn't storage. It's a team practice.

Provenance per writeRBAC + federationAudit log exportAES-256-GCM opt-inSecret detectionRLS on every table

Why this exists

Mainstream agent memory frameworks store facts and retrieve them later. That works for a solo developer. It breaks when teams ship with AI: decisions get re-litigated, conventions drift across agents, and no one can answer "who taught the AI that?"

Tages treats memory as a governed artifact. Every write records who, what, when, and from which agent session. Every memory can be audited, exported, or revoked. Federation propagates team decisions; drift detection surfaces when agents have learned conflicting things.

Provenance model

Every memory write captures the full context of its origin. This is stored alongside the memory value and is queryable via the CLI, MCP tools, and the dashboard.

FieldTypeDescription
user_iduuidSupabase Auth user who initiated the write.
agent_idtextLogical agent identifier (e.g., claude-code, cursor, codex, gemini-cli).
session_iduuidFK to agent_sessions.id. Correlates every tool call within one session.
tool_nametextMCP tool that wrote the memory (remember, observe, import, etc.).
source_contextjsonbFile path, PR number, commit SHA, or ticket ID associated with the write.
created_attimestamptzServer-side UTC timestamp. Immutable.
confidencenumeric0.0–1.0 confidence score (auto-indexer runs, draft-memory captures).

See docs/provenance-model.md for the formal specification and migration history.

Audit log

Every memory write, update, delete, and export is recorded in an append-only audit log. Entries capture the provenance fields above plus the operation type and the RBAC role of the actor at the time of the write.

Retention: audit rows are retained for 365 days by default. Self-hosted deployments configure retention via the TAGES_AUDIT_RETENTION_DAYS environment variable. Cloud customers on the Governance tier can request extended retention (up to 7 years) to meet SOC 2 and HIPAA requirements.

Tamper-evidence: each audit row is written with a row-level hash chained to the previous row within the same project. Any modification or deletion breaks the chain and is detectable via tages audit verify. (Planned for Governance tier; see roadmap.)

Export formats

Audit logs and memory snapshots export on demand in machine-readable formats suitable for compliance review.

  • JSON Lines — one record per line, full field fidelity, stable schema version.
  • CSV — flattened rows for spreadsheet and SIEM ingestion.
  • NDJSON stream — for incremental export to OpenTelemetry-compatible pipelines (planned).

Run tages audit export --format json --since 2026-01-01 to export scoped ranges.

Erasure & right-to-delete

Users can request erasure of their own contributions. Project owners can erase any memory or user's writes within a project they own.

  • Erasure is a hard delete of the memory row plus redaction of any provenance fields containing personal data; the audit event itself is retained as a tombstone row with the user reference removed.
  • Federation-propagated copies of erased memories are also redacted on next sync.
  • Cloud customers on paid tiers can request a deletion certificate via support.

Role-based access control

Three roles at the project scope:

  • Owner — full read/write, can manage members, rotate tokens, export audit logs, revoke invites.
  • Admin — full read/write, can invite members but not remove owners, can export audit logs.
  • Member — read-only by default; write access is grantable per memory type by owners.

Enforced at the Supabase Row Level Security layer (migration 0031 and 0051_team_rbac_hardening). UI and MCP tools receive the same RLS denials; there is no enforcement split between layers.

Federation

Federation lets one team memory propagate to other projects with explicit override rules. Security and platform teams can own specific memory types or AGENTS.md sections (planned via tages agents-md federate) so cross-project conventions stay consistent without manual copy-paste.

Every federated memory retains its original provenance record. You can always trace a propagated memory back to the team and user that authored it.

Drift detection (roadmap)

When multiple developers run agents on the same codebase, memory state drifts. Tages' tages drift command computes an Agent Stability Index across semantic, coordination, and behavioral drift dimensions, surfacing which memory keys are diverging and why.

Inspired by the Agent Drift paper (arxiv:2601.04170). Shipping in the Governance tier.

Encryption & transport

Optional AES-256-GCM field-level encryption for memory values (set TAGES_ENCRYPTION_KEY). All cloud traffic over TLS 1.2+. Supabase Auth with GitHub OAuth for user identity; SHA-256 hashed CLI tokens with expiration and rotation.

Full security posture at /security.

Compliance roadmap

  • SOC 2 Type I gap analysis in progress (Q3 2026)
  • SOC 2 Type I target audit window: Q4 2026 / Q1 2027
  • HIPAA readiness: dependent on customer demand; self-hosted BYOK available today
  • Data residency: self-hosting on your own Supabase region supported today

Compliance status is documented openly. Contact security@tages.ai for current attestation artifacts or to request a specific control review.

MCP gateway compatibility (roadmap)

Tages runs behind any MCP-compliant gateway. Integration and compat guides in progress for Stacklok ToolHive (Apache 2.0, K8s-native) and TrueFoundry vMCP.