Skip to content

ADR-003: Security and Compliance Boundary

  • Decision status: Accepted
  • Implementation status: Not started
  • Applies to: Reference runtime, external targets, enterprise/BYOC
  • Date: 2026-06-16
  • Deciders: Grey Newell
  • Tags: security, compliance, privacy, byoc, public-proof, enterprise

Context

RAGhelm's architecture now centers on private RAG and agent release control. It evaluates systems that may process private documents, retrieved context, business recommendations, traces, tool calls, and release evidence. The roadmap also includes BYOC/private-cloud deployment, public proof artifacts, external target adapters, human review, and future durable memory.

Before durable memory, enterprise audit workflows, public proof publishing, or BYOC deployment move forward, RAGhelm needs a clear security and compliance boundary.

Decision

RAGhelm defaults to a private-by-default release-control boundary:

  • private source content, retrieved context, raw traces, credentials, and customer data must not leave the deployment boundary unless explicitly configured
  • public proof artifacts must contain only redacted, synthetic, hashed, or explicitly public-safe data
  • production release evidence must fail closed when privacy classification, manifest validity, artifact hashes, or required security checks are missing
  • BYOC/private-cloud deployments are the enterprise target for sensitive customer data
  • durable tenant memory remains deferred until tenant isolation, retention, deletion, encryption, and audit controls are defined

Security and compliance evidence is part of release readiness. It should be represented in ReadinessScorecards, RAGRunManifests, release policies, and deployment docs.

Security Boundary

RAGhelm distinguishes these data classes:

  • public_safe: safe to publish in README, docs, demos, and public proof bundles
  • synthetic_demo: generated/demo data; may be public if marked safe
  • internal_operational: internal run metadata, costs, timings, IDs, and non-sensitive traces
  • private_customer_data: customer documents, retrieved context, prompts containing private content, tool outputs, business metrics, or sensitive traces
  • secret: API keys, credentials, tokens, signing keys, database passwords

Default rules:

  • secrets are never stored in scorecards, manifests, traces, or public artifacts
  • private_customer_data is not included in public proof bundles by default
  • manifests may reference private artifacts by hash/path/URI without embedding content
  • public badges and claims require public-safe scorecard/manifest evidence per ADR-010
  • external target adapters must report privacy classification and redact sensitive evidence where necessary

Compliance Boundary

RAGhelm's open-source reference implementation may provide security-ready structure, but it does not by itself imply SOC 2, HIPAA, PCI, or other formal compliance.

Enterprise/compliance readiness requires:

  • deployment boundary documentation
  • secret management guidance
  • access-control model
  • audit log policy
  • data retention/deletion policy
  • backup/restore guidance
  • incident response expectations
  • public-proof redaction rules
  • review/approval records for waivers

These may become enterprise/commercial features per ADR-021.

Consequences

Positive

  • Aligns security posture with private-compute positioning.
  • Prevents public proof artifacts from leaking private data.
  • Gives scorecards security/compliance gates before enterprise workflows expand.
  • Creates a prerequisite boundary for durable memory, BYOC, and audit workflows.

Negative

  • Adds classification and redaction requirements to artifact generation.
  • Some demos/proof artifacts must use synthetic or redacted data.
  • Enterprise readiness requires additional implementation beyond this ADR.

Neutral / Trade-offs

  • The open-source engine can be security-conscious without claiming formal compliance.
  • BYOC/private-cloud remains the target for sensitive customer workloads.
  • Hosted SaaS, if ever added, will require a separate security/compliance review.

Implementation Guidance

Initial implementation should:

  • add privacy classification fields to scorecards, manifests, target adapters, and trace bundles
  • fail closed when a public proof artifact includes private or unclassified evidence
  • redact retrieved context and tool outputs from public artifacts by default
  • document which fields may contain sensitive data
  • validate that .env, credentials, tokens, and secrets are never committed or emitted
  • add release policy checks for privacy/publication safety

Before durable memory or enterprise audit workflows:

  • define tenant/access-scope model
  • define retention and deletion policy
  • define audit log schema
  • define encryption/secrets handling
  • add eval cases for cross-tenant leakage and stale/wrong memory

Non-goals:

  • claiming formal compliance certification
  • implementing full RBAC in this ADR
  • implementing hosted SaaS security posture before commercial roadmap demands it
  • storing private source content in public proof artifacts

References

  • ADR-009: RAGRunManifest Schema and Artifact Lifecycle
  • ADR-010: Production Claims, Badges, and Public Proof Source of Truth
  • ADR-017: Memory and Tenant Isolation Boundary
  • ADR-020: Deployment and Private-Cloud/BYOC Architecture
  • ADR-021: Open-Core and Commercial Boundary