Skip to content

feat(control-plane): add tenant retention and immutable audit policy #871

Description

@seonghobae

Buyer-visible gap

Enterprise buyers need evidence that AppGuardrail keeps tenant data only for an explicit period, deletes eligible records predictably, preserves required security evidence, and can prove who changed retention-sensitive controls without exposing customer secrets.

Standards basis

The design must be grounded in current primary sources and documented with APA 7th references:

  • NIST SP 800-53 Rev. 5 (Release 5.2.0), especially AU-2, AU-3, AU-8, AU-9, AU-11, AU-12, and SI-12.
  • NIST SP 800-92 (final) for enterprise log-management lifecycle practices. SP 800-92 Rev. 1 remains a draft and may be used only as informative planning context.
  • ISO/IEC 27001:2022 and its current amendment for risk-based information-security management.
  • Regulation (EU) 2016/679, especially Article 5(1)(e) storage limitation, Article 5(2) accountability, and Article 17 erasure obligations and exceptions.

Acceptance criteria

  • Add a tenant-scoped retention policy with documented safe defaults, bounded values, optimistic concurrency, and owner-only mutation.
  • Distinguish at minimum scan findings/history, audit events, API-key metadata, webhook metadata, and suppression/baseline evidence; never place secret key material or webhook credentials into audit records.
  • Add append-only, tamper-evident audit events for retention-policy, API-key, webhook, suppression, purge-preview, and purge-execution actions. Preserve actor identity, tenant identity, request correlation, UTC event time, canonical event type, non-secret before/after summaries, previous-event hash, and event hash.
  • Add deterministic purge preview and execution paths. Preview and execution must use the same cutoff snapshot, support legal-hold exclusions, be idempotent, fail closed on stale previews, and never cross tenant boundaries.
  • Return a non-secret purge receipt with policy revision, cutoff, affected record counts, excluded legal-hold counts, execution timestamp, and audit-event identity.
  • Expose retention and audit posture through buyer-diligence and organization evidence outputs without leaking customer data.
  • Preserve standalone operation and modular MSA use: keep policy decisions and canonical audit hashing in dependency-free appguardrail_core modules, with SQLite/control-plane adapters behind narrow interfaces suitable for CWL central services and naruon.
  • Use only descriptive database object names containing at least two words; prefer snake_case. Replace any new or touched nonconforming object name before merge.
  • Document migration, rollback, operational recovery, legal-hold semantics, purge scheduling, backup implications, and limitations. Include an APA 7th reference section in the operator documentation.
  • Update CHANGELOG.d and promote to CHANGELOG.md only when the release candidate is validated.

Real-world test contract

  • Two tenants with overlapping repository names and timestamps cannot observe, preview, hash-chain, or delete one another's records.
  • Boundary timestamps immediately before, at, and after the cutoff produce deterministic results under an injected UTC clock.
  • Repeating the same purge execution is idempotent and returns the same completed receipt rather than deleting new data.
  • A policy revision or newly applied legal hold invalidates a stale preview before any deletion occurs.
  • Concurrent owner mutations use revision checks and cannot silently overwrite each other.
  • Audit-chain verification detects deletion, reordering, payload mutation, and cross-tenant link substitution.
  • API keys, authorization headers, findings snippets, webhook URLs containing credentials, and raw suppression evidence never appear in audit payloads or buyer reports.
  • Crash/retry simulation either commits both purge and audit receipt atomically or commits neither.
  • Changed production code, public APIs, modules, functions, classes, methods, and non-obvious behavior retain complete docstrings and exact 100% statement coverage.

Autonomous implementation contract

  • Write the failing regression tests first and preserve RED→GREEN evidence in commit ordering.
  • Review current control-plane schema and behavior before designing migrations; do not infer table contracts from names alone.
  • Use current primary standards or peer-reviewed literature for uncertain decisions. Record every material source in operator documentation using APA 7th style.
  • Do not add an LLM dependency where deterministic policy code is sufficient. If an LLM-backed test becomes necessary, use the repository NVIDIA_NIM_API_KEY secret and fail closed when it is unavailable.
  • Do not bypass required reviews, exact-head Checks, security scans, or branch protection.
  • Target develop, include Closes #<this issue number> in the PR body, and keep the slice independently usable as well as composable with organization infrastructure and naruon.
  • Remove completed backlog entries only through the reviewed registry/state-machine contract and append the next evidence-backed buyer-visible gap when supported.

References (APA 7th)

European Parliament & Council of the European Union. (2016). Regulation (EU) 2016/679 of 27 April 2016 (General Data Protection Regulation). Official Journal of the European Union. https://eur-lex.europa.eu/eli/reg/2016/679/oj

International Organization for Standardization. (2022). ISO/IEC 27001:2022—Information security, cybersecurity and privacy protection—Information security management systems—Requirements. https://www.iso.org/standard/27001

Joint Task Force. (2020). Security and privacy controls for information systems and organizations (NIST Special Publication 800-53, Rev. 5). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-53r5

Kent, K., & Souppaya, M. (2006). Guide to computer security log management (NIST Special Publication 800-92). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-92

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: authAuthentication, authorization, identity, or tenant isolationarea: ci-cdCI, GitHub Actions, checks, release, or supply chainarea: dependenciesDependency or lockfile maintenancearea: securitySecurity boundary, hardening, or vulnerability preventioncommercial-readinesspriority: mediumNormal-priority or P2 workscope: product-gapCustomer-visible product gapstatus: triagedOpen issue has an organization taxonomy assignmenttype: featureNew or expanded product capability

    Type

    No type

    Projects

    • Status
      In progress

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions