Trust, security, and responsibility at Nyrava
Attorneys upload their most sensitive material to Nyrava — witness statements, client communications, discovery, and work product. This page is the single hub for how we handle that trust.
Core principles
Nyrava exists to help legal professionals analyze complex matters faster without giving up the judgment, verification, and confidentiality that legal work demands. Every product decision is measured against six principles.
Security architecture
Nyrava is a multi-tenant SaaS application designed around workspace isolation. Every request in the app is scoped to the authenticated user's workspace, and the underlying database enforces that scoping with row-level security policies. Application code cannot bypass those policies — a bug in a query layer cannot cause one workspace to read another's rows.
The pipeline, end-to-end
Every case flows through a fixed sequence of engines. Each engine writes into a canonical analysis object rather than free-form prose, so the final report is a projection of grounded data rather than a re-summarization.
Every stage is evidence-grounded. Ungrounded output is suppressed before reaching the report.
Trust pillars
Each pillar has its own dedicated document.
Attorney control
Nyrava is a tool, not a decision-maker. Every generated output — evidence findings, timelines, motion drafts, reports — is designed to be reviewed before use. Citations are the primary UI affordance so verification is one click, not an audit.
Attorneys remain the drafter of record on any filing produced with Nyrava's assistance. We do not provide legal advice, do not enter into attorney-client relationships with your clients, and do not review the contents of your matters.
Evidence verification & hallucination prevention
Every finding surfaced by Nyrava is grounded to a specific passage in a source document and cited back to it. The pipeline includes an evidence gate that suppresses findings that cannot be traced to the corpus. When the model produces a plausible but unsupported statement, it is rejected before reaching a report.
The verification layer runs on every engine — evidence intelligence, witness intelligence, contradiction detection, motion drafting, and report synthesis. Rejections are recorded in the pipeline ledger so reviewers can see what the model tried to assert and why it was suppressed.
Data ownership & isolation
You own the content you upload. Nyrava's license to that content is strictly limited to providing the service to you. Your case content is not used to train general-purpose models, and it is not shared with other workspaces.
When you configure your own AI provider keys (OpenAI, Anthropic, Gemini, Groq, OpenRouter), requests originating from your workspace are sent directly to the provider you selected under the contract you have with them.
Encryption
- Data is encrypted in transit (TLS) between your browser and the platform.
- Data at rest is protected by the underlying managed infrastructure.
- Provider API keys and workspace secrets are encrypted before storage using AES-256-GCM.
- Access to production data is restricted to a small number of authorized engineers.
System availability
Nyrava runs on managed, geographically redundant cloud infrastructure. The application is designed for high availability, with a stateless application tier and a managed database tier that provides continuous backups and point-in-time recovery. Incident status and any planned maintenance windows are communicated to workspace administrators.
Enterprise deployments requiring formal service-level commitments should contact us before signing.
AI limitations & human verification
- AI models can make mistakes, miss context, or produce plausible-sounding but incorrect statements.
- Automated analysis is a starting point, never a final product.
- Attorneys must independently verify every output against source documents and applicable law before filing.
- Model behavior can shift when providers update their models; our router falls back across providers, but variance is real.
Compliance roadmap & audit posture
We do not claim certifications we have not earned. What is verified today:
- Row-level security (RLS) enforced at the database layer on every user-data table (cases, documents, reports, canonical analysis, findings, subscriptions, provider keys).
- Every application server function is wrapped with authenticated middleware that validates the caller's session token against the auth service on every request.
- Administrative server functions perform a second server-side role check against a dedicated
user_rolestable (roles are never trusted from client state). - User-supplied AI provider keys are encrypted at the application layer with AES-256-GCM before storage; a workspace admin cannot read another workspace's keys.
- The Stripe webhook endpoint verifies every payload with Stripe's signature scheme; the background pipeline worker requires a constant-time-compared shared secret.
- Case-file uploads live in a private storage bucket scoped to the uploader's user ID; cross-tenant object reads are blocked at the storage policy layer.
- 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 managed infrastructure.
On the roadmap (see Roadmap):
- Independent third-party penetration test before general availability to law firms.
- SOC 2 Type II readiness.
- Formal data-residency options for enterprise deployments.
- HIPAA BAA availability for regulated engagements.
If your firm requires a specific certification today, contact us before onboarding and we will tell you honestly what stage that certification is at.
Security FAQ
Contact & responsible disclosure
Security researchers and customers can report suspected vulnerabilities through the Contact page. We appreciate responsible disclosure and will respond promptly. Do not attempt to access data that is not yours; we will treat good-faith research as such and coordinate on remediation.