Security

This overview describes security boundaries visible in the product and the objectives used to operate them. Product-enforced controls, provider-dependent safeguards, and operational procedures are not the same thing; each applies only to the systems, routes, and environments for which it is configured and maintained.

This page is not a certification, audit, penetration-test report, service-level agreement, business-associate agreement, or guarantee that an incident cannot occur. References to common security practices do not claim external certification. No online service, device, network, model, provider, or encryption method is absolutely secure.

Sensitive input is validated at route, action, command, and external I/O boundaries. Account authorization, plan admission, quotas, billing admission, and sensitive provider routing are server-owned, so a client display cannot grant itself access or increase an allowance.

High-risk routes are designed to require explicit evidence and to fail closed where a weaker fallback would create material privacy or security risk. These controls reduce exposure but do not establish that every request, provider, integration, or deployment follows one universal path.

Supported private health-profile fields and conversation state remain in the browser by default. They enter managed infrastructure only when a selected feature requires encrypted server processing, synchronization, storage, sharing, or export. Browser-local information is not a server backup and can be lost when storage is cleared, a private session ends, a profile changes, or a device is lost.

Runtime and billing telemetry is designed around allowlisted account, plan, payment, request, route, quota, cost, fault, and security metadata rather than raw conversations, prompts, files, media, or model responses. Support messages, attachments, feedback, and abuse reports are separate content-bearing channels and are handled for their stated purpose.

Web traffic is designed to use encrypted transport. Synchronized files are encrypted and decrypted by trusted browsers, so managed storage receives ciphertext rather than the file key or plaintext. Separately, attachments promoted to managed processing may be transiently decrypted for extraction, preview, analysis, recovery, or export. Authentication material is protected according to whether it must be recovered or only verified.

Encryption reduces exposure but does not eliminate endpoint, authorization, software, key-management, provider, or device risk. Metadata needed to locate, authorize, bill, expire, or delete an encrypted object can remain outside the encrypted payload. Secrets are separated by purpose and environment and are not intended for public clients, analytics, support text, or ordinary logs.

Where available, accounts support passkeys, time-based one-time-password authentication, recovery codes, session controls, and step-up verification for sensitive changes. Service and operator access is designed around least privilege, purpose limitation, environmental separation, and revocation when compromise is suspected.

Users should enable a phishing-resistant or multi-factor method, keep recovery codes offline, review unexpected sign-in or billing activity, and never send passwords, one-time codes, recovery codes, payment credentials, or API secrets to support.

Model traffic is limited to the content needed for the selected feature, and routes request no storage where the provider supports that request. Bootstrap providers otherwise operate under their ordinary published retention and training terms; this is not a zero-data-retention or contractual no-training claim. A future restricted mode will fail closed when its required signed provider evidence is missing, expired, or invalid.

Model, search, speech, extraction, storage, email, payment, and observability providers can have different transient-processing, retention, human-review, deletion, residency, and recovery behavior. A control verified for one capability is not a blanket promise for another and does not by itself establish HIPAA status, a business-associate relationship, residency, or certification.

Changes are reviewed in proportion to risk, with particular attention to authentication, payments, attachments, provider routing, privacy requests, tool execution, and shared boundaries. Dependency, deployment, vendor, access, and configuration controls are maintained according to their environment, sensitivity, and operational evidence.

Review, automation, monitoring, and provider diligence reduce risk but cannot prove that software is free of vulnerabilities or that a vendor, deployment, or dependency will never fail. A separately signed agreement is required for a specific audit right, certification, data-processing commitment, residency promise, or service level.

Monitoring targets availability, authentication, payment, abuse, provider, quota, cost, and security conditions while excluding raw health content from ordinary runtime telemetry. Security evidence can include timestamps, request references, route decisions, error classes, provider state, usage totals, and remediation status; that metadata remains access-controlled.

Retention follows the purpose and control class of each artifact. Browser-local data, managed attachments, provider requests, support submissions, billing records, security evidence, backups, and legal holds can follow different deletion paths. Deletion and recovery are subject to the criteria described in the Privacy Policy and cannot guarantee restoration or immediate removal from every protected backup or provider cycle.

A suspected incident is assessed, contained, investigated, remediated, and documented according to its scope and available evidence. We evaluate contractual, privacy, consumer-health, payment, consumer-protection, and regulatory notification duties and notify affected people, providers, or authorities when applicable law requires it.

Recovery can use re-authentication, replay, reprocessing, provider failover, protected records, or temporary feature isolation. Backups and redundancy can reduce loss but do not guarantee recovery of every local, transient, encrypted, deleted, corrupted, or third-party artifact. Details may be staged when immediate disclosure would increase risk or obstruct a lawful investigation, but a legally required notice is not optional.

Send security reports to hello@anistratenco.com with the affected surface, potential impact, safe reproduction steps, and relevant timestamps. Do not include unnecessary personal or health information. Unless separately agreed in writing, reporting does not create a bounty, employment relationship, response-time commitment, or authorization to access systems or information beyond your lawful permission.

Good-faith testing must remain within accounts, systems, and data you own or are explicitly authorized to test. Stop after demonstrating the issue. Do not access another person’s data, retain or exfiltrate information, use social engineering, disrupt service, run destructive tests, evade payment, or publish an unresolved issue in a way that creates material risk.

We protect service-controlled boundaries. Users remain responsible for their devices, browsers, email accounts, authentication methods, submitted content, exports, integrations, recipients, permissions, and decisions based on outputs. Business users also control staff access, endpoint security, notices, lawful authority, and downstream handling.

Report suspected account compromise promptly to hello@anistratenco.com and take available steps to secure the account. Do not use support for a medical or personal-safety emergency; contact the appropriate local emergency service or qualified professional instead.