← nedulla.com

Security

How Nedulla protects your operations data, and what we do when something goes wrong. Last reviewed: May 2026.

Data residency & tenancy

  • Hosted in Australian regions. Production database, file storage, and edge functions run in ap-southeast-2. No customer payload routinely traverses outside Australian data centres.
  • Logical multi-tenant. Every customer record carries an org_idand is enforced by Postgres Row-Level Security policies. Cross-tenant reads are architecturally impossible — even a privileged service-role query has to scope byorg_id to get back rows.
  • Australian Privacy Principles. Data handling is aligned with APP 1–13; see our Privacy policy for the per-principle mapping.

Encryption

  • In transit: TLS 1.2+ for all customer-facing endpoints; HSTS with max-age=63072000 and includeSubDomains; preload.
  • At rest: Postgres database encrypted with AES-256 (Supabase-managed keys). Object storage encrypted at rest. OAuth refresh tokens are stored in Supabase Vault with envelope-encrypted secrets — never in plain database columns.
  • Operations transport: when Nedulla calls third-party APIs on your behalf (Gmail, Outlook, Anthropic, etc.), the channel is TLS and credentials are fetched per-request from Vault, never logged.

Your operations are not training data

  • We use third-party model providers (Anthropic, OpenAI) under contracts that prohibit training on submitted prompts or outputs.
  • Before any prompt leaves your tenant, our FROST pipeline scrubs PII (emails, phone numbers, AU TFNs / ABNs / address fragments) and replaces them with opaque tokens. The vault holding the token mappings stays inside your tenant.
  • Our SHIELD classifier inspects every model-bound payload for prompt injection patterns. Suspicious payloads are quarantined and surfaced to the user instead of executed.

Audit logging

  • Every privileged action (module toggles, member invitations, mailbox bindings, LLM policy changes) is recorded to a WORM (write-once read-many) audit log via Postgres RPC — append-only at the database level.
  • Audit events include actor, target org, action type, structured metadata, and monotonic timestamps. Retained for the lifetime of the workspace.

Authentication & authorization

  • Passwords are hashed via Supabase Auth (bcrypt). We never see your password.
  • Role hierarchy enforced top-to-bottom: middleware blocks unauthenticated access to app routes; a per-route guard checks role (keeper / partner / shaper / watcher); the database RLS layer is the last line.
  • Session cookies are HttpOnly, Secure, SameSite=Lax.

Subprocessors

Nedulla relies on a small set of vetted vendors. Material changes are announced before they affect production data:

  • Supabase — managed Postgres, Auth, Storage, Vault. AU region.
  • Vercel — application hosting and edge network.
  • Anthropic — large language model inference (Claude family).
  • OpenAI — large language model inference (GPT family) for selected tools.
  • Google & Microsoft — only when you connect a Workspace / 365 mailbox; OAuth scopes are scoped to the modules you enable.
  • Nango — managed OAuth gateway for third-party app connections.

Incident response

  • Detection: automated alerting on platform health, auth anomalies, and rate-limit breaches.
  • Notification: material security incidents are communicated to affected workspace owners within 72 hours of confirmation, with a follow-up post-mortem within 14 days.
  • Containment: we maintain a documented runbook for credential rotation, token revocation, and customer-data lockout.

Reporting a vulnerability

We treat security researchers as friends. If you find something:

  • Email security@nedulla.com. PGP-encrypted messages welcome — request the public key.
  • Please give us a reasonable window (typically 90 days) to remediate before public disclosure.
  • We commit to acknowledging within 2 business days, validating within 7, and communicating progress every 14 days until resolution.

Pilot status

Nedulla is currently in closed pilot. We haven't yet completed a SOC 2 Type II audit; we're building toward it with the controls above as the foundation. Open attestation requests are tracked publicly so customers can see what's in flight — ask your contact for the current status sheet.