Attorney Confidentiality Commitment

Nyrava is designed so that customer case files are not routinely accessible to company personnel. Administrative access is tightly restricted, logged, and governed by the principle of least privilege. We do not browse attorney work product as part of normal operations.

We deliberately do not claim that Nyrava employees are technically incapable of accessing customer data under any circumstance. That claim requires an architecture (for example, customer-managed encryption keys where the platform operator never holds the decryption key) that we have not yet built. We would rather be honest today than overstate protections.

• We do not read your case files, motions, witness statements, or reports as part of normal operations.
• We do not use your case content to train general-purpose AI models.
• We do not share your case content across workspaces or with other customers.
• We do not sell, rent, or market against the contents of your matters.
• Firm administrators in one firm cannot see cases belonging to another firm; individual accounts cannot see any other account's cases.

Honest disclosure of the technical reality of running a managed SaaS platform:

• Database administrators. A small number of authorized engineers hold credentials capable of privileged database operations on the production database. Row-level security protects against application-layer bugs, not against a person authenticated with database-administrator credentials.
• Cloud provider operators. The underlying managed cloud infrastructure (compute, storage, backups) is operated by third-party providers with their own operational access under their published security controls.
• Storage administrators. Files uploaded to case storage are stored in a private bucket that requires per-user-scoped policies to read. Personnel with storage administrator credentials could technically access raw objects if those credentials were used.
• AI provider processors. When your workspace uses Nyrava-managed inference, request content is sent to model providers (currently including Groq, Google, OpenAI-compatible gateways) under their contractual data-handling terms. When you bring your own key, requests go directly to the provider you selected under your contract with them.
• Backups. The managed database maintains continuous backups and point-in-time recovery for disaster recovery. Backups inherit the access controls of the underlying infrastructure.
• Encrypted secrets. Your provider API keys are encrypted with AES-256-GCM before storage using a server-controlled encryption key. Personnel with access to both the ciphertext and the encryption key could technically decrypt them; both are held on the server side.

• Debugging a specific customer-reported issue, only with the affected customer's request or consent, and only for the minimum necessary scope.
• Compliance with a valid legal process (subpoena, court order) that we cannot lawfully resist. Where lawfully permitted, we will notify the affected customer.
• Investigation of suspected abuse of the platform (for example, use in violation of the Acceptable Use Policy).
• Emergencies affecting the security or integrity of the platform (for example, incident response to an active compromise).

Access under any of the above circumstances is limited to the smallest set of personnel required, logged, and reviewed.

• Row-level security enforced at the database layer on every user-data table (cases, documents, canonical analysis, findings, API keys, subscriptions).
• Every application server function is wrapped with authenticated middleware that validates the caller's session token on every request.
• Administrative capabilities require a second server-side role check against a dedicated user_roles table; roles are never trusted from client state.
• Case-file uploads live in a private storage bucket scoped to the uploader's user ID; cross-workspace object reads are blocked at the storage policy layer.
• User-supplied AI provider keys are encrypted at the application layer with AES-256-GCM before storage.
• The Stripe webhook verifies every payload with Stripe's signature scheme; the background pipeline worker requires a constant-time-compared shared secret.
• Internal database trigger functions were revoked from anonymous and signed-in execution — they are only reachable by the database itself.
• Encryption in transit (TLS) and at rest via the managed infrastructure.
• Auditable pipeline ledger: every intelligence engine run writes inputs, model, tokens, and outcome to a per-user log.
• Your own Security Dashboard exposes sign-in status, MFA, API keys, and recent activity for the account you control.

We are actively working toward reducing the surface where Nyrava personnel can technically access customer content. Prioritized:

• Customer-managed encryption keys (CMEK) for case content, so the platform operator cannot decrypt objects at rest under normal operation.
• Field-level encryption for the most sensitive analysis payloads, with keys derived per workspace.
• Independent third-party penetration test before general availability to law firms.
• SOC 2 Type II readiness, with attested controls covering personnel access to production.
• Formal data-residency options for enterprise deployments.
• HIPAA BAA availability for regulated engagements.
• Per-access audit trail visible to firm administrators for the small number of exceptional-circumstance accesses described above.

We will not claim any of the above until it is implemented and verifiable.

• Enable multi-factor authentication on your account.
• Bring your own AI provider keys so inference runs under your contract with the provider.
• Export or delete your workspace data at any time — see Data Control.
• Review your account's own activity in the Security Dashboard.

If you believe an access has occurred outside the boundaries described above, or you want to discuss a specific confidentiality requirement your firm has, please reach us via the Contact page. Security researchers can also use that page for responsible disclosure.