Legal

• Account, identity, contact, subscription, and billing records.
• Prompts, responses, uploaded files, datasets, project artifacts, memories, and feedback.
• Generated code, execution results, citations, literature records, and reviewer findings.
• Tool calls and results, model and workflow metadata, token usage, timing, and reliability data.
• Security signals, authentication events, and records needed to investigate misuse.
• Page views, the referring campaign, and completion of sign-up on the account-creation page, for visitors who are not signed in.

Nyrus limits each service provider to the data needed for its function. The current list of subprocessors, with the purpose, location, plans, and data processing agreement of each, appears on the Subprocessors page. Section 5 describes what each provider receives.

CATO records agent trajectories. A trajectory may include prompts, responses, tool calls and results, generated code, citations, reviewer findings, execution metadata, model selections, safety signals, provider-returned reasoning content where available, and User Content surfaced during the workflow. Uploading a file does not, by itself, copy the full raw file into a trajectory. File excerpts, selected rows, summaries, tool results, generated outputs, or other content surfaced to the agent may be recorded.

Deleting a conversation, project, or file removes its primary application copy. It does not immediately remove related records from backups, security systems, diagnostic records, workflow history, or trajectory storage. Workflow history, which holds the text of recent messages, is kept for 30 days. The worker that runs a turn keeps a working record of it on local disk for up to seven days after the conversation was last used. When you delete a conversation, a project, or your account, its operational trajectory records are erased within 30 days; operational trajectory records that are not erased this way are deleted automatically 365 days after they are written. In either case Nyrus can recover a deleted record for seven days after its deletion, within those periods. A copy of a turn that was de-identified and separated from your account before the deletion is not erased, because it can no longer be associated with you.

You can turn on "Don't train on my data" in Settings. While it is on, your turns are not written to either trajectory store, are not used in evaluation sets, and are not included in the stored dataset used for memory maintenance. The setting applies from the time you turn it on. To ask that records collected before then no longer be selected for future model-improvement datasets, email contact@nyrus.ai; a request applies once processed and does not require Nyrus to undo processing completed before it.

Data already included in a training run that is underway, or statistical changes already incorporated into trained model weights, cannot generally be traced back and selectively reversed. De-identified or aggregated records that are no longer reasonably linkable to an individual may also be retained for evaluation, research, security, and service-improvement purposes where permitted by law.

Nyrus uses the following contracted providers:

• Google Cloud stores uploaded files, project artifacts, project filesystems, and trajectory records, and runs the workers that process agent turns and the sandboxes that run code.
• Railway hosts the application, its databases, including workflow history, and its caches.
• Fireworks AI runs model inference for conversations, literature screening, memory maintenance, embeddings, and reranking.
• Exa receives literature and web search queries on plans other than Enterprise.
• Stripe processes payments and subscriptions.
• Resend delivers email.
• Sentry receives error reports as described in Section 7.
• PostHog records page views and completion of sign-up on the account-creation page, for visitors who are not signed in, and runs on no other page.

When a provider processes personal data on Nyrus's behalf, its applicable agreement includes data-processing terms addressing the provider's permitted purpose, confidentiality, security, subprocessors, incidents, deletion, and assistance with applicable privacy requests.

Those agreements are between Nyrus and the provider. They do not make an individual user a party to the vendor agreement, mean that providers receive no data, establish zero retention for every service, or authorize the processing of PHI. Users exercise their rights through Nyrus.

Literature, patent, trial, protein, pathway, chemical, and other public scientific services are not ordinary CATO subprocessors. CATO sends only the search terms, public identifiers, sequences, structures, filters, or other query elements needed for the requested operation. Their own terms and logging practices apply.

On plans other than Enterprise, CATO also sends literature and web search queries to Exa, a subprocessor, and retrieves open-access full text from publisher websites. On Enterprise plans, CATO does not use Exa and limits literature searches to PubMed, PubMed Central, Europe PMC, OpenAlex, arXiv, bioRxiv, medRxiv, ClinicalTrials.gov, patent search, and Crossref; it does not contact Semantic Scholar, Unpaywall, or publisher websites.

Do not place personal information, identifiable health information, confidential participant narratives, unpublished invention disclosures, or credentials in a public-service query.

These are the technical and organizational measures in place today. They describe what is built, not what is planned. No security measure eliminates all risk.

• Encryption: connections between your browser, CATO, and its providers use TLS. Data at rest in the application database, object storage, project filesystems, and backups is encrypted by the hosting providers. Traffic between the workers that run agent turns and the sandbox controller uses mutual TLS with signed requests.
• Sandbox isolation: code the agent runs executes in a hardened container with its own kernel (gVisor), which serves one conversation and is removed after five minutes without activity. The container receives no cloud-storage credentials or application secrets, mounts only its own project's filesystem and read-only shared reference data, and sits behind a default-deny network policy with an allowlist of public destinations. Internal cloud networks and metadata services are blocked. Cluster admission rules refuse pods that do not meet these constraints, and the isolation boundary is tested with a probe suite that Nyrus runs against the cluster.
• Identity and access: every request to the API carries a short-lived signed identity token minted by the application after checking your session, and administrative functions are limited to named administrator accounts. Two-factor authentication is available on every account and is required for members of an organization with an enterprise agreement, who are challenged at every sign-in and cannot turn it off. Production and staging workers use separate service identities.
• Separation of trajectory stores: the writer that records operational trajectories can only create records; it cannot list, read, overwrite, or delete them. The erasure process can list and delete operational records but cannot read them. Training systems have no access to that store. The de-identification step is the only process that writes to the training-approved store. Turns by Enterprise accounts, and by users who have turned on "Don't train on my data", are not written to either trajectory store.
• Secrets and configuration: provider credentials and signing keys live in the hosting providers' secret stores and are injected into the services that need them; they are never written into project filesystems or exposed to sandboxes.
• Monitoring and logging: error reports contain stack traces, the route, timings, the plan, and an internal account identifier; request bodies, free text such as exception messages and user-supplied text, contact details, and session replay are removed or disabled before a report is sent. Service metrics and network policy logs are collected for operations and security investigation, and workflow state is durable so an interrupted turn can be resumed or cleanly finalized.
• Backups and recovery: restoration of the application and workflow databases is drilled quarterly and the results recorded. The object stores that hold user files and project filesystems are versioned, and those stores and the trajectory stores keep deleted objects recoverable for seven days. The user-file and trajectory stores are encrypted with keys that Nyrus manages.
• Personnel: Nyrus personnel who can access customer data are bound by confidentiality obligations, access it only for the purposes in this notice and the Privacy Policy, and lose access when they leave.
• Providers: each provider on the Subprocessors page is under a written data processing agreement or equivalent terms, and physical security of the data centers is the responsibility of those providers.
• What we do not yet have: Nyrus does not hold a SOC 2 report or an ISO 27001 certification, and has not yet commissioned an independent penetration test. We will update this section when that changes.

CATO is operated from the United States and its providers process data there unless a provider listed on the Subprocessors page states otherwise. If we become aware of a security incident affecting your personal data, we will notify you without undue delay and within the time required by applicable law, or within the time set out in a separate written agreement where one applies.

To request access, correction, export, or deletion of personal data, or to ask about future model-improvement use, contact contact@nyrus.ai. We may need to verify your identity before completing a request.