Data Processing
Last reviewed September 21, 2026
This notice explains how Nyrus Corp. processes data through CATO, how service providers support that processing, and how operational records and agent trajectories are used. It supplements the Privacy Policy and Terms of Service. If this notice conflicts with either document, the Terms of Service and Privacy Policy control. A separate written agreement between Nyrus and a customer controls over all three where it conflicts, including any restriction it places on using that customer's content to train or improve models.
Standard CATO accounts may not be used for Protected Health Information or other identifiable consumer health, genetic, biometric, or patient-level data.
CATO's Role
Standard accounts
For standard accounts, Nyrus determines why and how account, product, safety, and service data is processed. Nyrus acts as the business or controller for that processing. Individual users are governed by the Terms of Service, Privacy Policy, and this notice rather than a separate data processing agreement.
Institutional and enterprise accounts
When an organization determines the purposes of processing personal data and instructs Nyrus to process it through CATO on the organization's behalf, Nyrus may act as a processor or service provider. Those deployments require an appropriate customer agreement and, where applicable, a CATO data processing addendum. A vendor DPA between Nyrus and a service provider does not replace the agreement between Nyrus and its customer.
When such an agreement ends, Nyrus returns or deletes the customer's data, at the customer's choice, within 30 days of termination or of the customer's written request. Records that the law requires Nyrus to keep are isolated and protected until they can be deleted. Accounts on plans exempt from model-improvement capture produce no full-content trajectories, so there is nothing of theirs in the trajectory stores to delete.
What CATO Processes
- 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, policy classifications, authentication events, and records needed to investigate misuse.
Nyrus limits each service provider to the data needed for its function. The current provider list, data categories, retention posture, and contractual references appear on the Subprocessors and Service Providers page.
Agent Trajectories
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.
Operations, security, and misuse prevention
Nyrus uses trajectories and related service records to operate and restore workflows, diagnose errors, prevent fraud and abuse, enforce the Usage Policy, investigate security events, resolve disputes, and improve the safety and reliability of CATO. Records relevant to abuse, fraud, security, or legal obligations may be retained for longer than ordinary product records when reasonably necessary for those purposes.
Evaluation and improvement
Nyrus also uses trajectories to evaluate scientific performance, curate evaluation and training datasets, and improve or train CATO models, reviewers, routing systems, and agent workflows. We take steps to minimize direct identifiers in curated datasets and limit access to personnel and systems that need it.
Nyrus does not authorize third-party AI inference or retrieval providers to train their models on CATO User Content. This restriction does not prevent Nyrus from using CATO records to improve its own offerings as described here.
Operational and training-approved stores
Operational trajectories and training-approved trajectories are kept in separate storage boundaries. The production trajectory writer is create-only: it cannot list, read, overwrite, or delete operational records, and training systems have no access to that store. A separately authorized cleaning and approval pipeline must read an operational record, apply the applicable review, minimization, and approval controls, and create a distinct copy in the training-approved store before any training system can read it. Accounts on plans that are exempt from model-improvement capture do not produce full-content trajectories.
Deletion and Future Training
Deleting a conversation, project, or file removes its primary application copy. It may not immediately remove related records from backups, security systems, diagnostic records, or trajectory storage. Operational trajectory records are written to a store that cannot be edited or deleted record by record, so a trajectory that has already been recorded is not removed on request; it is retained under the retention rules in this notice and the Privacy Policy. You may email contact@nyrus.ai to request that identifiable records no longer be selected for future model-improvement datasets; a request applies once processed and does not require Nyrus to undo processing completed before it.
Service Providers
Nyrus uses contracted providers for application hosting, model inference, sandbox execution, monitoring, payment processing, and email delivery. 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.
Public Research Services
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.
Do not place personal information, identifiable health information, confidential participant narratives, unpublished invention disclosures, or credentials in a public-service query.
Security Measures
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: each agent turn runs in a hardened, kernel-isolated container that receives no cloud-storage credentials or application secrets, mounts only its own project's filesystem, 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 exercised by our own automated probe suite.
- 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 use separate service identities, and the identity that can mount production project filesystems is used only for that purpose.
- Separation of trajectory stores: the writer that records operational trajectories can only create records; it cannot list, read, overwrite, or delete them. Training systems have no access to that store. A separately authorized pipeline is the only path into the training-approved store. Accounts on exempt plans produce no full-content trajectories.
- 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 monitoring runs with request bodies, session replay, and personal identifiers disabled; service metrics and network flow logs are collected for operations and security investigation; workflow state is durable so an interrupted turn can be resumed or cleanly finalized.
- Backups and recovery: the application and workflow databases are backed up by their hosting provider; the object stores that hold user files, artifacts, and trajectories are versioned, keep a soft-delete window, and are encrypted with keys that Nyrus manages; production project filesystems use versioned object storage; restore procedures for each store are drilled on a schedule and the results recorded.
- 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.
Requests and Incidents
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.