Skip to content

ADR-017: Memory and Tenant Isolation Boundary

  • Decision status: Accepted
  • Implementation status: Not started
  • Applies to: Reference runtime, external targets, enterprise/BYOC
  • Date: 2026-06-16
  • Deciders: Grey Newell
  • Tags: memory, tenant-isolation, context, privacy, agents, security

Context

RAGhelm's architecture includes scoped memory and business context management for agent workflows. Business-advice agents benefit from context such as business stage, industry, metrics, constraints, prior recommendations, and outcomes.

However, durable memory changes the security, privacy, tenancy, retention, deletion, evaluation, and audit profile of the system. ADR-016 establishes that RAGhelm's product direction is agent readiness evaluation, with a limited reference agent as the demo/reference implementation. ADR-013 establishes that RAGhelm should support external targets that may bring their own memory/context systems.

The architecture must allow useful request-scoped business context without introducing premature durable tenant memory.

This decision supports related implementation work without making issue numbers part of the durable architecture contract.

Decision

Use per-run context now, support external memory/context adapters for external targets, and defer durable tenant-scoped memory until security and tenant architecture is ready.

In practical terms:

  • RAGhelm's reference agent may accept business context as per-run input.
  • Per-run context is recorded as release evidence in manifests/traces/scorecards according to privacy rules.
  • RAGhelm may evaluate external targets that use their own memory or context stores.
  • External memory evidence should be represented through target adapter metadata, not copied wholesale into RAGhelm by default.
  • RAGhelm will not add its own durable tenant memory store until access control, tenant isolation, retention, deletion, audit, and privacy policies are defined.

Consequences

Positive

  • Enables useful synthetic reference workflows without taking on durable memory risk immediately.
  • Avoids cross-tenant leakage hazards before tenant/security architecture is mature.
  • Keeps RAGhelm aligned with release-control rather than becoming a customer data/memory platform prematurely.
  • Allows evaluation of external memory-using agents through adapters.
  • Keeps public demo/proof artifacts easier to keep synthetic and privacy-safe.

Negative

  • The reference agent will not initially remember context across runs.
  • Some mature business-agent workflows will require external target systems or future durable memory work.
  • Scorecards for external memory-using systems may have reduced confidence if memory evidence is opaque.

Neutral / Trade-offs

  • Per-run context is sufficient for demos, regression tests, and many release-readiness checks.
  • External target adapters can report memory usage without exposing private memory contents.
  • Durable tenant memory remains a future capability, not a rejected direction.

Alternatives Considered

  1. No durable memory or business context initially

Pros: - Safest and simplest.

Cons: - Weakens synthetic business-agent workflows and context-sensitive evaluation.

  1. Per-run context only

Pros: - Useful initial capability. - Keeps context scoped, auditable, and easier to redact. - Avoids durable cross-tenant state.

Cons: - No cross-run personalization or accumulated business memory.

This is chosen for RAGhelm's reference agent now.

  1. Tenant-scoped durable memory store

Pros: - Stronger product capability for mature business agents.

Cons: - Requires tenant isolation, authz, retention, deletion, audit, encryption, and privacy governance. - Too risky before security/tenant architecture is defined.

This is deferred.

  1. External memory/context adapters only

Pros: - Strong release-control posture for evaluating existing systems. - Avoids RAGhelm storing memory directly.

Cons: - Less useful for the built-in reference agent.

This is supported for external targets.

Per-Run Context Rules

Per-run context should be:

  • explicit input to a run, not silently loaded durable state
  • associated with a run ID, target ID, and privacy classification
  • included in manifests as metadata or hashed/redacted references when sensitive
  • redacted from public proof artifacts unless synthetic/public-safe
  • evaluated for relevance and safety when used in agent decisions
  • excluded from durable memory unless a future ADR permits it

External Memory Adapter Rules

External targets that use memory should report where possible:

  • memory system identity/type
  • tenant/context scope
  • whether memory was used
  • memory retrieval confidence or trace IDs, if available
  • redacted memory references rather than raw sensitive content
  • failure modes or missing-memory conditions

When external memory evidence is unavailable, scorecards should represent reduced evidence confidence rather than assuming memory behavior is correct.

Future Durable Memory Requirements

Before RAGhelm adds a durable tenant-scoped memory store, a future ADR must define:

  • tenant and access-scope model
  • authentication and authorization boundaries
  • encryption and secrets handling
  • retention and deletion policy
  • audit log requirements
  • memory correction and override process
  • eval cases for cross-tenant leakage and stale/wrong memory
  • public-proof redaction rules
  • migration and rollback plan

References

  • ADR-013: External Target Adapters and Vector Backend Boundary
  • ADR-016: Agent Runtime Scope, Tool Contract, and Side-Effect Safety