Security
Security should read like an operating posture, not a placeholder.
This page explains the current trust baseline behind Witara: how accounts are protected, how deployments are handled, how integrations are framed, and where users should go when something feels wrong.
Current posture date: April 5, 2026
Account security first
Authentication, session handling, email verification, and cookie boundaries are treated as product-critical controls rather than ornamental security language.
Private data stays inside the product boundary
Workspace content is processed to run the product, not to fuel hidden advertising or unrelated profiling.
Integrations are explicit
Connections to Google, Microsoft, or iCal feeds are opt-in and visible. If a provider changes access rules, we surface that reality rather than hiding it.
Authentication and sessions
- Email verification is required for new account creation.
- Passwords are handled through the application authentication layer rather than exposed in client-side state beyond registration and login flows.
- Refresh tokens are rotated and stored through cookie/session mechanisms designed for authenticated use across our production subdomains.
- We actively harden auth flows when reliability or abuse risks appear in real usage.
Infrastructure and environment
- The public site and private API run on separate services with explicit environment configuration and deployment boundaries.
- Operational secrets are managed through hosted environment variables rather than being embedded in the public client.
- Build, lint, typecheck, unit, and e2e validation are part of our normal release process before changes go live.
- We monitor deployment health and treat broken onboarding or broken trust flows as release blockers.
Product data handling
- We collect and retain product data for service operation, support, security, and improvement as described in the Privacy Policy.
- We do not currently route private workspace content through external AI services as a hidden default for day-to-day usage.
- Imported calendar data is used to support scheduling, timing awareness, and product recommendations inside the app.
- Read-only fallback paths, such as Outlook via iCal, are offered when direct provider approval is not yet practical.
Access and internal handling
- Administrative access should be limited to what is needed to operate, support, or secure the service.
- We expect service providers and operators to handle data under confidentiality, operational need, and least-access principles.
- We continue tightening our internal posture as the product moves from early access into broader production use.
Incident reporting and trust contact
If we become aware of a security issue that materially affects user data or account safety, we intend to investigate, contain, remediate, and communicate in a way that matches the severity of the event.
If you discover a vulnerability or trust issue, contact help@witara.site. For founder-level escalation or high-context review, you can also write to councillor@witara.site.
This page reflects the controls and posture we can describe clearly today. It is a live trust surface, and we expect it to become more concrete over time, not less.