Security and control
eva is designed so business context stays within verified account and project boundaries, privileged operations remain server-side, and meaningful changes stay reviewable.
Draft updated 1 October 2026 — subject to legal review before release
Verified access and project boundaries
Account access uses verified authentication. Business records are scoped to the active project and verified project membership, with database row-level security used to enforce access boundaries. Locked and closed accounts are rejected even if a previously issued access token has not expired. Retrieval and agent tools receive verified scope from the application rather than accepting identity or project scope from model input.
Protected records and files
Privileged database credentials stay in server-only code and are not exposed to the browser or model-visible tool inputs. Business files use private storage and controlled access paths. Project documents, memories, customer notes, and extracted asset text are treated as untrusted business data, not hidden instructions.
Limiting unwanted disclosure
Connecting an agent to business information creates a risk of unwanted disclosure, including through malicious instructions hidden in documents, messages, or fetched pages. eva treats this material as untrusted context. The service verifies the active project before tools retrieve records, and connected-service credentials remain outside model-visible inputs.
The current agent uses a limited set of business tools. It has no general browser control, shell, arbitrary code execution, or unrestricted network tool. Public web research is supported, so queries and requested URLs can leave eva. Supported external actions also share the content needed with the selected service under their applicable approval rules. These controls reduce the avenues for data exfiltration; they do not establish a guarantee that disclosure is impossible.
Cloud hosting is not a promise of a dedicated computer per customer, end-to-end encryption, exclusive user access, or zero provider retention. Relevant content is processed by AI and infrastructure providers as described in the .
Reviewable action
Meaningful, destructive, or high-impact operations retain explicit review and approval boundaries. Durable work is saved to visible project records so it can be inspected instead of relying on hidden agent memory.
Project owners can inspect an audit history of access and changes. Platform administrators have read-only access to project content and can open a clearly labelled preview using actual content; preview access is audited. Their account controls are limited to lock, unlock, and removal. Closed projects are inaccessible during the 30-day disposal period.
Operational diagnostics
Eva correlates sanitized request, release, feature, device-category, and failure signals across the Eva app, agent, integrations, workers, and voice services. Request correlation uses a generated or trusted Railway request identifier. Production network correlation uses a monthly rotating HMAC; raw IP addresses and complete user-agent strings are not stored in Eva telemetry. Diagnostic writes fail open so an observability outage cannot block a user action.
Telemetry tables are service-only, have row-level security enabled, and explicitly deny browser roles. Detailed records are retained for 30 days, while named daily usage and anonymous reliability rollups are retained for 13 months. Access to profile diagnostics and individual diagnostic details is itself recorded in the admin audit trail.
Planned private default and agent choice
We plan to offer a private default AI so confidential business data and intellectual property can remain within a business-controlled environment. We also plan to let users choose another agent with clear disclosure of its processing and data-sharing boundaries. The current build uses external AI APIs and does not yet offer these capabilities. Delivering the private default requires validating isolation, access, retention, and all AI data paths, including voice, search, and connected services.
Service providers and ongoing work
eva relies on specialist infrastructure providers for hosting, database, authentication, storage, and email delivery. Provider certifications and compliance programs do not automatically become certifications of eva. Security controls are reviewed as the product evolves, and no system can promise absolute security.
Report an incident or request deletion
The public security contact address is awaiting operator confirmation. Email .