Security & Privacy

How Nairi handles your data, secrets, and access.

This page summarises how Nairi protects your data day to day. The binding legal commitments live in the Data Processing Addendum and the Privacy Policy; this page links out to them where it matters.

Where your data lives

ComponentProviderRegion
Primary databaseSupabase (managed Postgres)US (AWS us-east-1)
Backend APIRenderUS
Frontend & docsVercelGlobal edge
Agent computeHetzner CloudGermany (nbg1, Nuremberg)
AuthenticationClerkUS

Customer prompts and tool-call content are also sent to the LLM provider you select per-org (Anthropic, OpenAI, or Anomaly Innovations / OpenCode Zen) at inference time. See What goes to the model provider below. For the full and legally-binding list of sub-processors, see Schedule 1 of the Data Processing Addendum.

Encryption

In transit. All traffic between your browser, the Nairi API, and agent containers is over TLS. The dashboard, API, and agent runtime all reject plain HTTP.

At rest. Database storage uses AES-256 encryption at the managed-database layer (see Schedule 2 of the DPA).

Application-level encryption. Vault secrets, OAuth tokens, and other sensitive credentials get an additional layer on top of the database's storage encryption: every value is encrypted with AES-256-GCM (random per-record nonce) using a platform-managed encryption key before it hits the database. The plaintext is never persisted. See Vaults & secret security model for the full design.

Authentication

Dashboard. Sign-in is via Clerk. Today we support Google and GitHub OAuth.

API. Two key types, prefixed and scoped:

  • Public API keys (nr_...) — issued from Settings → API Key, scoped to your org, revokable instantly. See Using the API.
  • Agent API keys (ccagent_...) — issued from the Self-host page, used only by a self-hosted nairid daemon to connect back to Nairi. See Self-hosting.

Keys are stored hashed; the dashboard only ever shows you the last four characters after creation.

Secret handling

Nairi handles third-party credentials through two separate paths, depending on whether the agent itself needs to use the credential or whether an MCP server does.

Vault secrets (used by the agent)

Vaults deliver credentials the agent uses directly (e.g. a curl command in a shell script, an env var consumed by a skill) without ever putting the plaintext in a prompt, log, or env var visible to the model.

Inside a managed agent container, three things cooperate:

  1. The agent process sees placeholder env vars like CCASECRET_STRIPE_API_KEY.
  2. The local secret proxy intercepts the outbound HTTPS request (via a per-container MITM CA generated on first start and persisted in a per-container volume).
  3. It substitutes the placeholder for the real value only if the request's destination is in that secret's allowed-domain list. Anything else gets blocked and logged.

Full details: Vaults & secret security model.

MCP config credentials (used by MCP servers)

Credentials that belong to an MCP server (database connection strings, API keys for SaaS tools, internal service tokens) live a different life. The MCP server doesn't run inside the agent's container — it runs inside the mcp-proxy sidecar that sits alongside the agent.

The agent talks to the mcp-proxy over a local HTTP endpoint and only ever sees the tools the MCP exposes. The MCP's command, args, env, and headers — including any credentials — stay on the proxy side and are never readable by the agent or visible in its memory, logs, or filesystem.

Practical consequences:

  • Inlining credentials in an MCP config's JSON is safe on managed runtimes. Mark the config as sensitive in the dashboard to hide its content from casual viewing in the UI.
  • A compromised agent prompt cannot exfiltrate an MCP's credentials. It can only call the tools the MCP exposes.
  • A compromised MCP server can still call out to allowed third-party services (just like any tool), but the credentials it holds aren't reachable through the agent's process.

See Credentials in MCP configs for the full breakdown and when to use a vault reference instead of inlining.

Data retention

While your subscription is active, Nairi retains:

  • Org configuration (agents, rules, MCPs, skills, vaults, scheduled jobs).
  • Conversation transcripts (the prompts and replies for every job).
  • Temporary attachments (files uploaded into a conversation) for 24 hours, then they're automatically deleted by an hourly cleanup job.
  • Agent artifact attachments (intentionally generated by an agent, e.g. exported PDFs) for the lifetime of the parent agent.

Old conversations are not automatically deleted. They stay available until you delete the parent agent or your org.

On cancellation. Per Section 10 of the DPA, Nairi will delete or return all Customer Personal Data within 30 days of termination, except where applicable law requires continued storage.

Earlier deletion. You can request deletion of specific data at any time. See Data subject requests below.

What goes to the model provider

When an agent processes a job, the following are sent to the configured LLM provider as part of the model context:

  • The user prompt and conversation history for that thread.
  • The agent's system prompt and any rules attached to the agent.
  • Outputs from tool calls (file reads, MCP responses, command output) when they're fed back to the model.

Each provider has its own data-handling policies. Today Nairi supports:

Pick the provider that fits your data classification. The choice is per-org in Settings → Integrations.

The Nairi platform itself does not train models on your data. Any model-provider training behaviour is governed by that provider's policy.

Data subject requests

Under GDPR, UK GDPR, and CCPA you have the right to access, correct, and delete personal data we hold about you. To exercise these rights:

  • Email support@nairi.ai from the address on your account.
  • We acknowledge requests within 5 business days and respond within 30 days (sooner where the request is straightforward).

If you're acting on behalf of a Data Subject other than yourself, see the controller/processor flow in Section 7 of the DPA.

Sub-processors

Nairi uses a small set of third-party services to deliver the product. The canonical, legally-binding list is in Schedule 1 of the DPA. At the time of writing it includes:

VendorPurposeRegion
Hetzner Online GmbHAgent computeGermany (and US capacity)
Supabase, Inc.Managed Postgres databaseUS (AWS us-east-1)
Render Services, Inc.Backend API hostingUS
Vercel, Inc.Frontend & CDNGlobal edge
Clerk, Inc.User authenticationUS
Anthropic, PBCClaude inferenceUS
OpenAI, Inc.Codex inferenceUS
Anomaly Innovations, Inc.OpenCode Zen inferenceUS

If a new sub-processor is added, Nairi notifies the billing contact in advance per Section 6.2 of the DPA.

Personal data breach notification

Per Section 8 of the DPA, Nairi notifies the customer without undue delay, and within 72 hours, of becoming aware of a Personal Data Breach affecting Customer Personal Data. The notification includes the nature of the breach, likely consequences, and measures taken to address it.

Reporting a security issue

If you think you've found a vulnerability in Nairi:

  • Email support@nairi.ai with [SECURITY] in the subject line.
  • Include reproduction steps, affected URLs or accounts, and any proof-of-concept material.
  • We'll acknowledge within 1 business day and follow up with a triage update within 5 business days. Resolution timelines depend on severity.

We don't pursue legal action against good-faith security research that:

  • Doesn't degrade the service for other customers.
  • Doesn't access, modify, or exfiltrate data that isn't your own.
  • Gives us reasonable time to remediate before public disclosure.

We don't run a formal bug bounty today, but we appreciate disclosures and are happy to credit you publicly with your permission.


Have a question this page doesn't answer? Email support@nairi.ai.

On this page