Introducing Ragwalla Compliance: Retention, Legal Holds, and Tamper‑Evident Audit Trails for AI Agents

Ragwalla Compliance gives AI agents configurable retention for conversations, audit logs, and files; legal holds that override retention cleanup; and a cryptographic audit‑log hash chain. Evidence workflows are supported via JSON APIs for audit logs and retention deletions.

Share:

AI agents don’t behave like traditional software.

A typical web app might write a couple of logs per request. An AI agent can generate dozens of actions inside
a single conversation: thread creation, message writes, run execution, file uploads, vector store operations,
policy updates, and more. That’s powerful — but it creates a new compliance reality:

  • What data did the agent touch?

  • How long are conversations and files retained?

  • Can you prove logs weren’t altered?

  • What happens when you must preserve records for an investigation?

Today we’re introducing Ragwalla Compliance — built for agentic workloads, grounded in how the platform
actually stores and governs data today.

———

What Ragwalla Compliance does today

1) Configurable retention policies (conversations, audit logs, files)

Ragwalla supports retention policies across three distinct categories:

  • Conversations: threads and messages

  • Audit logs: platform audit events

  • Files: uploaded file records and stored objects

Retention settings live in org_project_settings, and can be configured at the organization default level with
project‑specific overrides.

Important behavioral details:

  • Enforcement is opt‑in. Cleanup runs only for orgs/projects that have retention days explicitly set in
    org_project_settings.

  • Conversations are soft‑deleted. Retention cleanup sets deleted_at on threads and messages (it does not
    hard‑delete them).

  • Files are soft‑deleted and removed from object storage. Retention cleanup updates the file record and
    deletes the primary object path from R2.

  • Audit logs are archived before deletion. Entries are copied to audit_logs_archive before removal from
    audit_logs.

Every retention cleanup run is recorded in retention_job_runs, and deletions are recorded in
retention_deletions.

———

2) Legal holds (retention override for preservation)

Legal holds are designed to override retention cleanup when preservation is required (litigation, regulatory
inquiries, FOIA, internal investigations).

Holds can be scoped by organization or project, and can cover:

  • Audit logs

  • Conversation threads

  • Files

Holds also support targeted thread and file IDs when scope is known.

Important behavioral details:

  • Holds prevent retention cleanup from deleting protected resources.

  • Holds do not currently block manual delete APIs (thread/message/file delete handlers do not check holds).

  • Message‑level hold flags exist in the schema, but retention cleanup currently evaluates holds at the thread
    level only.

Legal hold creation and release are logged in the audit trail.

———

3) Tamper‑evident audit trail (cryptographic hash chain)

Every audit log entry is linked to the previous one using a cryptographic hash chain:

  • prev_hash + entry_hash + sequence_num

  • Chain state is stored per org in audit_chain_state

This design makes tampering detectable when the chain is verified.

Integrity checks are implemented in backend helpers and results are recorded in audit_integrity_checks. A
public verification endpoint is not currently exposed.

Audit logs are archived before retention deletion so you keep historical records even after cleanup.

———

4) Evidence and reporting (JSON‑based APIs)

Today, evidence collection is supported via JSON APIs:

  • Audit log querying (filter by action, resource type, actor, timeframe)

  • Retention deletions list (dashboard endpoint)

  • Retention job history (system endpoint)

CSV exports and evidence packages are not implemented yet, but JSON results are easy to export and convert.

———

Framework alignment (SOC 2 and NIST 800‑53)

Ragwalla’s retention and audit controls map to common audit requirements, including:

  • SOC 2: C1.2 (confidential data disposal) and P5.1 (data retention)

  • NIST 800‑53: AU‑11 (audit record retention) and SI‑12 (information retention)

These features provide technical controls and evidence artifacts, but do not replace your organization’s
formal compliance program.

———

Getting started

  1. Set organization retention defaults (conversations, audit logs, files)

  2. Apply project overrides where requirements differ

  3. Review audit logging and filtering workflows

  4. Define your legal hold process (who can create and release)

  5. Plan evidence exports from audit logs and retention deletion records

———

API examples

Replace YOUR_INSTANCE, ORG_ID, and PROJECT_ID with your values.

Set org‑level retention defaults

curl -X POST "https://YOUR_INSTANCE/v1/organizations/ORG_ID/policies"
-H "Authorization: Bearer $RAGWALLA_API_KEY"
-H "Content-Type: application/json"
-d '{
"chat_retention_days": 365,
"log_retention_days": 365,
"file_retention_days": 180
}'

Override retention for a project

curl -X POST "https://YOUR_INSTANCE/v1/organizations/projects/PROJECT_ID/policies"
-H "Authorization: Bearer $RAGWALLA_API_KEY"
-H "Content-Type: application/json"
-d '{
"chat_retention_days": 30,
"log_retention_days": 365,
"file_retention_days": 30
}'

Query audit logs (filter by action + time window)

curl "https://YOUR_INSTANCE/v1/organizations/ORG_ID/audit_logs?
action=thread.delete&from=1700000000&to=1702592000&limit=100"
-H "Authorization: Bearer $RAGWALLA_API_KEY"

Build your AI knowledge base today

Start creating intelligent AI assistants that understand your business, your documentation, and your customers.

Get started for free