Cross-Workspace Memory Sharing

Cross-workspace memory sharing lets one workspace expose specific memory segments to another workspace. This enables teams to share a knowledge graph, daily memory, or document library across projects without duplicating data or merging workspaces.

Sharing model

Shares are directional: a granting workspace exposes segments to a receiving workspace. Each share specifies which segments are shared and what permission level the receiver has.

Memory segments

Permission levels

Creating a share

// Share graph + daily memory from workspace A to workspace B (read-only)
const share = await createMemoryShare(
  'uid_alice',          // owner
  'ws_A',              // granting workspace
  'ws_B',              // receiving workspace
  ['graph', 'daily_memory'],
  'read',
  { expiresInMs: 30 * 24 * 60 * 60 * 1000 }  // 30 days
)

Expiry

Shares can be permanent (no expiresInMs) or time-limited. Expired shares are treated as inactive — the receiving workspace loses access automatically without needing an explicit revocation.

Revoking a share

await revokeMemoryShare(shareId, 'uid_alice')

Security implications

Cross-workspace sharing is the only mechanism in Open Astra that can move data across workspace boundaries. Before enabling it, understand the trust model:

• The granting workspace controls exposure. Only the workspace owner (or a user with admin grant) can create or revoke shares. The receiving workspace cannot request access unilaterally.
• write permission is high-risk. A receiving workspace with write permission can append entries to the granting workspace's memory. This can pollute the knowledge graph or daily notes with unvetted data. Use read unless you have a specific reason for write access.
• Shared segments are included in RRF retrieval. When an agent in the receiving workspace runs, shared memory is searched alongside local memory. If the shared graph contains sensitive data from the granting workspace, it will be injected into agent context and potentially exposed in responses.
• User-level profile data (profile segment) should almost never be shared. It contains personal preferences and background that belong to specific users in the granting workspace.

Access control interaction

Cross-workspace memory sharing operates independently from Agent Grants. Grants control which users can invoke which agents inside a workspace. Memory shares control which workspaces can read or write each other's memory. Both layers must be correctly configured:

When to enable

Cross-workspace sharing is appropriate in a small set of scenarios:

• Shared company knowledge base — A central knowledge workspace holds curated graph entities and documents. All team workspaces receive read-only access to graph and documents.
• Research → product pipeline — A research workspace produces findings that a product workspace should have access to, with a time-limited read share on graph.
• Shared procedure library — A central workspace maintains standard operating procedures. Team workspaces get read access to procedures.

In all other cases, prefer keeping workspaces fully isolated. Sharing is hard to audit retroactively once data has flowed across boundaries.

Configuration

workspace:
  memory:
    crossWorkspace:
      enabled: true
      defaultPermission: read          # never grant write by default
      allowedSegments:                 # restrict which segments can be shared
        - graph
        - documents
        # procedures and profile sharing is disabled by default
      maxActiveShares: 10              # limit number of outbound shares

Auditing active shares

// List all active shares for a workspace
const shares = await listMemoryShares('ws_A')
// Returns: [{ shareId, receivingWorkspace, segments, permission, expiresAt, createdAt }]

// Check if a specific share is still active
const share = await getMemoryShare(shareId)
console.log(share.status) // 'active' | 'expired' | 'revoked'

All share creation and revocation events are emitted on the event bus as memory.share.created and memory.share.revoked. Wire these to a webhook to build an audit log for compliance. See Event System.

Common use cases