RFC 0010: ACL-based memory partitioning and cross-user access - #30
RFC 0010: ACL-based memory partitioning and cross-user access#30galiniliev wants to merge 2 commits into
Conversation
Adds RFC 0010 with its supporting broker design and implementation plan:
session-scoped, ACL-enforced memory partitioning so multiple users can
share an agent in group channels without exposing each other's — or the
owner's — private memory.
Core design:
- Memory stays markdown files; the directory tree is the partition
primitive (users/{id}, channels/{id}, shared/, projections/{id}) and
SQLite is an index + policy catalog (pointer + hash, scope, ACL,
lineage, exposure audit), built on the existing node:sqlite +
sqlite-vec stack
- Session-scoped attribution: principals stamped at routing time (user
for verified DMs, channel for groups, agent for autonomous runs);
steering never switches principals; shared-DM sessions refuse user
mounts
- Mount model: personal stores are never readable from group sessions;
sharing is deliberate — tenant shared/, opt-in projections, and a
write-only postbox with trust tiering (labeled | review-required |
off; enterprise default conservative)
- Deny-by-default evaluation with a normative permission lattice
(admin => derive => read => retrieve); allow satisfied by placement or
ACL rows; two-phase enforcement where the prefilter never excludes
evaluator-allowed items and the postfilter is the security boundary
- Enterprise identity: Entra/Okta/Google principals via verified
bindings; adapters fetch raw token material, core validates and
constructs principals behind an operator allowlist; group snapshots
fail closed with a bounded staleness window
- Transcripts carry session scope; compaction summaries are broker
derive operations with lineage — no unscoped artifacts
- Cross-user grants sketched but deferred (non-normative Appendix A);
cross-instance federation out of scope for a future RFC
- Security posture & risk assessment section with ranked residual
risks; Phase 0 is retrieval/tool-layer isolation, with the
out-of-process broker tier required for adversarial isolation
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Codex review: needs real behavior proof before merge. Reviewed July 6, 2026, 9:58 PM ET / 01:58 UTC. Summary Reproducibility: not applicable. This PR proposes an RFC and sidecar design documents rather than reporting a runtime bug to reproduce. Review metrics: 1 noteworthy metric.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review findings
Review detailsBest possible solution: Keep the RFC open as a draft, fill the metadata/linkage, add the maintainer-discussion context, and merge only after maintainers explicitly accept or narrow the normative security core. Do we have a high-confidence way to reproduce the issue? Not applicable: this PR proposes an RFC and sidecar design documents rather than reporting a runtime bug to reproduce. Is this the best way to solve the issue? Unclear: an RFC is the right surface for this broad design, but the PR still needs lifecycle metadata and explicit maintainer security/product acceptance before merge. Full review comments:
Overall correctness: patch is correct AGENTS.md: not found in the target repository. Codex review notes: model internal, reasoning high; reviewed against a8e0ba2701d6. Label changesLabel changes:
Label justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (1 earlier review cycle)
|
clawsweeper
Bot
added
rating: 🦐 gold shrimp
The Gateway caller-identity pattern established in openclaw/openclaw#96883 is the seam this RFC's session-scoped attribution builds on. Co-Authored-By: Claude Opus 4 <noreply@anthropic.com>
clawsweeper
Bot
added
the
feature: ✨ showcase
|
ClawSweeper status: review started. I am starting a fresh review of this pull request: RFC 0010: ACL-based memory partitioning and cross-user access This is item 1/1 in the current shard. Shard 0/1. This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking. Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted. |
giodl73-repo
left a comment
giodl73-repo
left a comment
There was a problem hiding this comment.
This is a thoughtful security model: session-scoped attribution, structural mounts, deny-by-default evaluation, transcript lineage, and the explicit exec ceiling are the right concerns. Before accepting the normative core, I think the storage identity and shared-workspace authority need to be made implementable across OpenClaw's supported platforms and deployment topologies.
Findings
-
[P1] Separate canonical principals from filesystem path keys. The RFC defines principals such as
entra:{tenant_id}:{object_id}and then places{canonical_user_id}directly undermemory/users/. Colons are invalid in Windows path components, and arbitrary IdP/channel identifiers can contain other unsafe or normalization-sensitive characters. Define a stable, versioned filesystem-key encoding (or opaque hash plus catalog mapping), with collision and migration behavior. ACL principal strings should never be interpolated directly into paths. -
[P1] Define the physical storage and write authority for shared scopes. The proposed
{workspace}/memory/{users,channels,shared,projections}tree assumes one workspace can safely contain every user's personal store plus tenant/channel state. Lobster today has per-user OneDrive-backed git workspaces; other deployments may have a shared agent root. The RFC needs an explicit topology contract separating user-owned personal storage, channel/workspace-owned storage, and tenant-admin-governed storage, then describing how the broker mounts views across those roots. In particular, who may write/promote/delete content inshared/? “Hand-editable Markdown” must not turn a user's repo write into an unaudited tenant-wide injection path. -
[P2] Make projections explicit audience grants, not “all channels I am in.” The current rule dynamically exposes a projected item in every channel where the user is a live member. Joining a new channel can therefore widen an old sharing decision. Prefer a named channel/workspace audience, purpose, expiry, audience preview, and revocation. Live membership should constrain an explicit grant, not create one.
-
[P3] Complete the RFC lifecycle metadata. Keep the document draft until the normative security core is explicitly accepted, populate
rfc_prwith this PR URL, and link the maintainer security/product discussion required by the repository process.
For the Lobster/shared-workspace direction, the key architectural question is whether permissions slice broker-mounted stores owned by different authorities, rather than relocating all private and shared bytes beneath one editable workspace root. Resolving that here will make the RFC usable by both local OpenClaw and enterprise hosts without weakening inspectability.
2 participants
Summary
Proposes session-scoped, ACL-enforced memory partitioning for OpenClaw: multiple users can share an agent in group channels without exposing each other's — or the owner's — private memory. When an enterprise IdP (Entra ID, Okta, Google Workspace) is connected, its tenant/user IDs become the canonical ACL principals.
Three documents:
rfcs/0010-acl-based-memory-partitioning.md— the RFC proper, including a normative-core vs. follow-ups table, a security posture & risk assessment with ranked residual risks, and a non-normative Appendix A (deferred cross-user grants)rfcs/0010/openclaw-memory-broker-design.md— broker design: schema, evaluation semantics, retrieval pipeline, failure modes, runtime notes on the existingnode:sqlite+sqlite-vecstackrfcs/0010/implementation-plan.md— component breakdown (coresrc/memory-acl/+ optional enterprise plugin), phases, and integration points with existing codeKey design decisions
memory/users/{id},channels/{id},shared/,projections/{id}); SQLite is an index + policy catalog (pointer + hash + scope + ACL + lineage + exposure audit), never the content store.shared/, opt-in projections, and a write-only postbox with trust tiering (labeled|review-required|off; enterprise default conservative).admin ⇒ derive ⇒ read ⇒ retrieve); allow satisfied by placement or ACL rows; two-phase enforcement — the prefilter never excludes evaluator-allowed items, the postfilter is the security boundary.deriveoperations with lineage — no unscoped artifacts.Honest limits (stated in-document)
Phase 0 provides retrieval/tool-layer isolation. Deployments with untrusted channel members and
execenabled require the out-of-process broker tier before claiming adversarial isolation (§2.1, risk 1). Semantic laundering through the context window remains detect-not-prevent (Non-Goals §1).Review guide
Start with "What Accepting This RFC Means" (top of the Proposal) — accepting this RFC accepts the normative core only; follow-ups are individually revisitable. The Security Posture & Risk Assessment section at the end lists what's enforced, ranked residual risks, and which are accepted vs. addressed vs. open.