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 August 1, 2026, 4:36 PM ET / 20:36 UTC. ClawSweeper reviewWhat this changesThis PR adds a draft RFC, broker design, and implementation plan for session-scoped ACL memory isolation and enterprise identity-based access in shared-agent deployments. Merge readinessThis draft RFC is not implemented on current main and should remain open for explicit maintainer product and security-architecture review. Its only discrete patch issue is that the required Priority: P2 Review scores
Verification
How this fits togetherThe proposed memory-access subsystem would receive a verified session scope, combine it with memory placement and ACL policy, and return only permitted memories to an agent. Enterprise identity adapters and exposure auditing would supply identity context and accountability around that retrieval path. flowchart LR
Session[Verified session identity] --> Scope[Session scope]
Memory[Memory files and index] --> Broker[Memory access broker]
Scope --> Broker
Policy[Placement and ACL policy] --> Broker
Broker --> Context[Permitted memory context]
Context --> Agent[Agent response]
Broker --> Audit[Exposure audit]
Decision needed
Why: The documents propose new core enforcement, identity, storage, and audit contracts; repository evidence cannot choose that long-lived product and security boundary without maintainer intent. Before merge
Findings
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Keep the RFC as a draft, repair its pull-request metadata, and have architecture owners decide whether its normative core should become an accepted, separately tracked implementation direction aligned with the enterprise RFC. Do we have a high-confidence way to reproduce the issue? Not applicable: this is a design RFC, not a report of broken existing behavior. The relevant review path is RFC lifecycle, architecture, and security evaluation rather than a runtime reproduction. Is this the best way to solve the issue? Unclear: the proposal is detailed, but maintainers must first decide whether its new ACL, identity, and memory-storage contracts are the right core direction and how they coexist with the accepted enterprise architecture. Full review comments:
Overall correctness: patch is correct AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against af708f0ddb6f. LabelsLabel justifications:
EvidenceAcceptance criteria:
What I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (6 earlier review cycles)
|
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
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.
clawsweeper
Bot
added
merge-risk: 🚨 security-boundary
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.