Security & data boundaries

A plain-English version of "where does my code go" and "what does ARDS keep". If you're using ARDS for real-repo work, this is the page to read carefully.

Your code

  • Origin repo (yours): ARDS never pushes to it without your explicit approval click. There is no "auto-merge" mode in v1.
  • Review mirror (ours): when you connect a repo, ARDS clones it onto an internal Git server. Coders work against this mirror. Approved changes are pushed back to your origin on your behalf.
  • Coder containers: each coder works on its own clone of the mirror, inside a container from your tenant's pool. Containers are reused across tasks and scaled away after idle minutes — and nothing a coder doesn't commit and push to the mirror survives the task.

If you delete your tenant, all mirrors and conversation history go with it. (Backups are kept on rotation for short-window restore. Ask support if you need exact retention numbers.)

Your API keys

  • Stored in our secret store (HashiCorp Vault on the platform side).
  • Injected into coder containers only as environment variables at container start.
  • Never written to disk inside the container.
  • Never logged in plaintext.
  • Never sent to providers other than the one the key is for.

You can revoke them at any time. Either remove from the LLM Config page (we stop using it immediately) or revoke at the provider — ARDS will surface the rejection as an error.

Your conversations and missions

  • Stored in our database (Postgres).
  • Visible only to your tenant.
  • Used internally for:
    • Mission orchestration (the planning model reads the conversation it's planning).
    • Searchable history in the Intelligence dashboard (your own search; tenant-scoped).
    • Cost accounting (token counts per task).

We do not train models on your data. We don't have a model to train.

The in-app Ask Genesis help assistant answers product questions only — it can't see or change your project data.

Tenant isolation

  • Each tester gets their own subdomain: <slug>.ards.etiakorp.com.
  • Each tenant has its own Postgres database (separate database per tenant inside a shared Postgres cluster).
  • Each tenant has its own Vault namespace for secrets.
  • Coder containers are pooled per tenant; one tenant's coder can't see another's data.

The shared edge components (Postgres cluster, Vault server, K8s control plane) are tenant-aware: every query is filtered by tenant ID at the row level and the database boundary.

What about secrets in code?

If your repository contains hard-coded secrets and you push them through the review mirror, the coders will see them. They won't do anything with them deliberately, but they're still visible. Recommendation: don't trust the mirror for unredacted secrets; rotate any key that's lived in the mirror's history if you decide to move off ARDS.

The Review Engine's secret-scan domain catches obvious leaks (AWS keys, JWT tokens, etc.) and surfaces them as findings — see Review Engine.

What we log

  • Mission state transitions.
  • Task starts, ends, failures, with anonymised durations and token counts.
  • HTTP errors hitting the dashboard.
  • Operator-side platform metrics (CPU, memory, etc.).

Logs do not contain prompts or model outputs. They contain enough to debug "why did this mission fail" without snapshotting the content of your conversation.