Security

Zinley lets your assistant work with information, connected accounts, and computers you authorize. It can also communicate through its own channels or your connected accounts. This page explains the security controls, what they cover, and the limits you should understand before granting access. Our Privacy Policy explains how we use personal information and how to exercise your rights.

Security is ongoing work. If you operate in a regulated or sensitive environment, evaluate Zinley, and any AI tool, against your own requirements before using it.

To report a vulnerability or ask a security question, contact [email protected].

Infrastructure and Compliance

Subprocessors

Different features use different service providers. A provider receives the information needed for its role, which can include private content when that content is part of your task. The following describes the main services; see the Privacy Policy provider list for the wider data-processing context. Our hosting, AI processing, logs, and backups are contractually restricted to the United States.

Some open-weight models in our lineup were originally developed by external labs. When we offer them, task data is sent to the infrastructure provider shown or selected by Zinley, not automatically to the model's original developer. Routing can change within our contracted US processing requirements. Independent websites, connected applications, and recipients you choose can have different processing locations.

Internal Access

Application administration uses authenticated requests and administrator authorization controls. We limit authorized human access to customer content to operational needs such as a support request, reliability work, safety or abuse review, a security investigation, or a legal obligation. The stricter restrictions for Google data and Health information in our Privacy Policy still apply; this paragraph does not expand those permitted uses.

Assurance Status

We do not claim a security certification or independent assessment unless it is explicitly identified as completed. Contact [email protected] for the current status and any reports that are available for your account or agreement.

How We Protect Your Assistant

Your assistant can take actions using the access you provide. A file, message, or webpage can contain malicious instructions intended to misuse that access. The following controls reduce that risk, but do not establish that every instruction or action is safe.

Prompt Injection Defense

Prompt injection occurs when malicious instructions are embedded in seemingly normal content, attempting to manipulate the AI into performing unauthorized actions. We defend against this at multiple layers:

• Detection and wrapping: Selected external-message paths use pattern checks for suspicious instructions and label the content as untrusted data. These checks do not cover every file, page, channel, or possible attack
• Misleading characters: Selected lookalike characters are normalized when checking the labels that separate external content from instructions. This does not detect every disguised or hidden instruction
• Input sanitization: Supported input paths strip selected control characters and apply length limits before processing
• Instructions to the model: Security instructions tell the assistant to treat external material as information, not authority to change its rules. Labels added by the server help distinguish external content from instructions; the model can still interpret them incorrectly

These checks label some suspicious content rather than blocking every request that contains it. Their effectiveness depends partly on the model following its instructions. Tool permissions and approval controls provide additional safeguards where they apply.

Call Fraud Detection

Phone calls carry real-world risk and receive dedicated protection:

• When enabled, AI screening checks supported outbound call requests for fraud, impersonation, harassment, privacy violations, and other abuse; it cannot identify every harmful request
• The task description, contact name, and context fields sent to screening have selected control characters removed and length limits applied
• Screening evaluates the request's purpose and context. It is an AI assessment and can make mistakes or miss attempts to manipulate it
• Recorded fraud flags can restrict phone access according to configured categories and thresholds
• If screening fails or is unavailable, the active configuration determines whether the call is held or allowed. Calls are not guaranteed to be blocked on a screening failure
• Fraud-flag records use a shortened hash of the phone number, alongside the account, task excerpt, reason, and category. This does not make the record anonymous. Operational call records still contain phone numbers

Repeated Actions and Task Checks

• Supported agent loops compare recent tool calls and results to detect repeated attempts that make no progress
• Repeated matches can produce guidance or stop the current loop. This check does not detect every harmful or unnecessary action
• Run budgets and iteration limits bound supported agent loops; external tasks and services have their own behavior and limits

Supported tasks can run tests or reviews, and completion checks can compare reported outcomes with tool results. These checks depend on the task and execution path. Every file edit does not automatically receive independent review or testing, and a completed check does not guarantee correct or secure output.

How Actions Stay Within Your Rules

Zinley is not a read-only service. Your instructions, connected-account permissions, device permissions, and feature settings determine the actions your assistant can take. A direct request in chat can authorize the requested action without another confirmation. Scheduled work, Proactive, Health, and individual tools have their own controls; there is no single approval switch that governs every action.

Permission Model

• Supported tools expose permission controls appropriate to that tool, which may include enable or disable settings and per-action approval
• Some supported operations can run automatically under your settings or standing instructions. Review the settings for the feature you are using
• Permissions differ by integration and device. A broad connected-account grant, browser login, or shell capability can permit more than one kind of action
• Where an approval is requested, review its recipient, content, files, and consequences before approving
• Supported destructive actions can require confirmation, depending on the tool and settings. Do not assume every write, deletion, or external action will show a second prompt

Read-only access describes the source connection. For example, reading Health or linked-bank data can still involve cloud processing and storing summaries in Zinley. Disconnecting a source stops the supported connection; it does not recall completed actions or erase content already saved elsewhere. See the Privacy Policy for the differences between permissions, processing, and deletion.

Directory Guardrails

Directory guardrails currently use a blocklist. They are an additional control, not an operating-system sandbox.

• When the guardrail is enabled, folders on the blocklist and their descendants are blocked or require approval
• Paths not on the blocklist remain available to the app's existing access. Disabling the guardrail or leaving the list empty adds no directory restriction
• Zinley's own internal data directories remain available so the app can operate
• Path checks normalize paths and try to resolve existing symbolic links before comparison. When resolution fails or a path does not yet exist, the check falls back to the normalized path
• The settings interface does not allow an entire root drive or the Unix root directory to be added to the blocklist

The main desktop interface has Electron's renderer sandbox disabled. Directory guardrails do not replace operating-system access restrictions or isolate every command a shell can execute. Use operating-system permissions and a separate user account when stronger isolation is required.

Skill Security

Skills are reusable instructions or routines that guide your assistant. Supported skills and guardrail rules are stored in your account's cloud library and can synchronize across supported clients. Their availability still depends on the feature, device, and channel. Supported creation and update paths apply the following checks:

• Pattern-based analysis checks skill content for selected shell, code-evaluation, credential-harvesting, mining, and data-transfer patterns
• Matching source text may be removed or commented out. This changes the skill text; it does not block a live network connection, sandbox execution, or prove that the skill is safe
• Some checks consider patterns across multiple lines, but unfamiliar or indirect behavior can escape detection
• Skill content created or updated through the cloud library service is also sanitized on the server
• A skill does not create a separate security boundary. Actions it requests use the permissions and controls of the tools that perform them
• The desktop pre-scan can return unchanged content if scanning is unavailable or fails. Server sanitation still applies to supported cloud content saves

Use skills from trusted sources. Review what a skill asks your assistant to read, change, run, or send before enabling it. A skill can influence powerful tools even when the skill itself is only text. A successful scan is not proof that it is safe.

Guardrail Rules

Written guardrail rules can be included in the assistant's context to guide security, code quality, data handling, and tool use. These instructions are advisory: a model can misunderstand or fail to follow them. They are different from directory checks and operating-system permissions that restrict access in code.

Platform Security

Platform and channel availability depends on the current release, account, operating system, and region.

Desktop App Hardening

• The main desktop interface uses context isolation and has direct Node.js integration disabled. Supported system operations are exposed through the app's desktop bridge
• The bridge still provides powerful capabilities, including file and tool operations. These settings do not make the interface a complete security sandbox
• The packaged main app window disables DevTools through Electron configuration
• A Content Security Policy restricts script, connection, and resource sources. It excludes ordinary JavaScript unsafe-eval, but permits inline scripts, WebAssembly evaluation, and selected external sources required by the app
• Main-window navigation is restricted and ordinary external links open in your system browser. Supported embedded content and authentication popups have separate handling
• Production builds use platform signing and hardened-runtime settings where configured
• macOS notarization runs only for release jobs where notarization is enabled and Apple credentials are present
• Update-signature verification depends on the platform and release configuration

Session Security

• The main production app WebSocket services verify Firebase credentials. Account, device, and session identifiers help route messages; a session identifier is not itself an authentication credential
• Authenticated connections are checked against the relevant account and device access
• Task-result routing is scoped to the relevant account and device or session, while account updates intentionally synchronize across signed-in devices
• Disconnect cleanup can allow a short reconnection window; a network disconnect is not immediate deletion of server-side task or session state
• Phone, live voice, and other provider connections use their own authentication arrangements; they do not all use the same app session mechanism

Authentication and Token Security

• The desktop app uses Firebase's browser-local persistence to keep its sign-in session in local browser storage
• Selected application storage values use AES-GCM with a PBKDF2-derived key in production when WebCrypto initialization succeeds. The key seed is kept in the same app storage; this is not OS-keychain protection against someone or code with access to that storage
• If local encryption initialization or encryption fails, the current desktop implementation can fall back to plaintext storage
• Cookie attributes such as SameSite and Secure apply only where an HTTP cookie is used
• Sign-in credentials can be refreshed to keep authorized sessions working; expiration, revocation, and connection failures can require signing in again
• API middleware adds security headers and checks duplicate request parameters on the routes it covers. This is not a claim that every public endpoint or embedded service has identical protections
• Supported production API endpoints use TLS

Transport and local-storage encryption serve different purposes. Zinley is not an end-to-end encrypted service: our systems and the providers needed for a feature can process its content. Do not assume every local cache, downloaded file, or browser profile is encrypted by Zinley.

Input Validation

• Supported file operations normalize paths and apply the relevant access checks. Validation and handling of relative paths depend on the operation
• Supported web-fetch handlers validate URL protocols and internal-network targets to reduce server-side request forgery risk. Browser and computer tools have different capabilities and controls
• Supported handlers sanitize input and apply length limits. Coverage depends on the endpoint and tool
• Supported device-connection handlers restrict identifier formats and lengths

Rate Limiting

• API controls: General request limits and additional limits on selected routes help manage abuse and load. Authentication, file indexing, AI generation, and bug-report routes have specific controls
• Client controls: Selected client operations, including automatic error reports and site deployments, apply additional limits
• Usage controls: Plan allowances, credits, and feature-specific limits can pause or prevent further work. These limits are not a guarantee against unexpected or unwanted actions

Network Domains

Common network destinations include the following. This is not a complete firewall allowlist: connected apps, AI, search, media, and other selected features can need additional destinations. Ask support for the requirements of your intended deployment before restricting network access.

• snowx.ai and *.snowx.ai: API requests, AI processing, skills and guardrails, and WebSocket connections
• zinley.com and its service subdomains: Website and supported account or product services
• Google and Firebase service domains, including googleapis.com, firebaseapp.com, and firebaseio.com: Authentication, stored data, and supported direct service connections
• storage.googleapis.com: Hosted files and app updates, including the legacy meetorion release bucket

Messaging Apps

Messages received through supported messaging connections are processed by the platform and Zinley and can become part of saved conversation history. Each platform has its own account, credentials, access controls, and retention rules. Deleting a message in Zinley does not delete copies held by the platform or recipients.

Phone Calls

Supported AI phone calls are recorded and transcribed. Audio, transcripts, summaries, numbers, and call metadata can pass through communications, AI, and storage providers. The history visible in the product depends on your plan; a visibility window does not itself delete older records. See the Privacy Policy and Terms for disclosure, consent, and recipient considerations.

AI Requests

Zinley makes AI requests when you chat, use supported calls or tasks, and enable background features that build context or use memory. A request can include relevant history, files, images, memory, connected data, Health or financial context, and task results. Many requests pass through our backend and may use Portkey to reach a provider. Some features, including live voice, use an authorized direct connection from the app to the provider.

Zinley's supported production service connections use TLS to protect information in transit. A task can also visit independent websites whose connections and handling differ. Routing, retention, and provider controls depend on the feature and endpoint. Our hosting, AI processing, logs, and backups are contractually US-only; this does not control independent destinations you choose to contact or publish to.

AI Providers and Model Training

Zinley does not use private customer content to train a general-purpose generative AI model. We use API services and data controls intended to prevent provider training on customer content. Data you connect from Google Workspace is additionally subject to the Google API Services User Data Policy Limited Use restrictions, which prohibit its use for creating, training, or improving any generalized AI or ML model.

• Health and connected Google content are not used for advertising or general-purpose AI model training; no-training restrictions do not mean providers retain no data
• Provider controls and retention vary by route and may change with the model lineup
• Some request and response content is stored in restricted operational AI logs configured to expire after seven days
• Authorized personnel may access content for reliability, support, safety, security, abuse prevention, or legal obligations, subject to the stricter Google Limited Use and health-data rules in our Privacy Policy

Data Retention

• Saved conversations: Generally remain until deleted. Moving a conversation to Trash allows restoration for up to 30 days unless you permanently delete it sooner
• Operational AI logs: Some request and response content is stored in logs configured to expire after seven days
• Phone and email history: Product visibility depends on your plan and does not itself delete older records
• Product telemetry: The default raw-event expiry is 90 days; session rollups are configured for 180 days. Other summaries have different lifetimes. Supported per-user records are included in the account-deletion workflow
• Other records: Feedback, security, fraud-prevention, billing, deletion, aggregate, and legal records may be retained as reasonably needed or required by law

Expiry and deletion run through background processing and are not instantaneous erasure of every provider or backup copy. Memory, People, indexed files, Health, and financial records have their own stores and deletion controls. See Retention, disconnection, and deletion for those differences and your rights.

File Indexing and Memory

Supported search features can split provided or connected content into excerpts and create numerical representations, called embeddings, to find relevant information later. Search storage can contain the excerpt itself as well as its embedding, file name or path, and account or device identifiers. An embedding is not a promise that the original content has been discarded or anonymized.

Your assistant can also save preferences, information about people, and ongoing context in separate memory records. The information available for reading or indexing depends on the feature, content you provide, and connection or device permissions.

Controlling future access and existing copies: Use the relevant connection, file, and desktop directory controls to limit future access. Blocking a directory or disconnecting a source does not erase excerpts, memories, uploads, or conversations already saved. Use the applicable deletion controls or contact us for a broader deletion request.

Telemetry and Diagnostics

We collect operational metrics, errors, traces, and crash reports to maintain performance, security, and reliability. Reports can include account identifiers, email, name, and technical context. The mobile app can attach screenshots and interface details, which may contain private information visible on screen. The website also uses Google Analytics, and first-party measurement can link signed-out activity to an account after sign-in. See the Privacy Policy for details and controls.

Enterprise Security Controls

Enterprise security, identity, audit, retention, and compliance controls are available only when they are documented in a signed order form or service agreement and verified for that deployment. Contact [email protected] for current availability. The standard hosted service should not be treated as zero-retention.

What You Can Do

No software system can guarantee complete security. AI security in particular is a rapidly evolving field where new attack techniques emerge regularly and defenses must adapt. We recommend the following best practices:

• Review skills before enabling them. Prefer sources you trust and inspect what a routine can read, change, or send
• Block sensitive directories. Add folders Zinley should not access to the desktop guardrail blocklist and keep the guardrail enabled
• Review permission prompts carefully. Do not approve an action you have not reviewed
• Keep Zinley updated. Install supported security and reliability updates when they are available
• Limit outside integrations. Each connected service increases the attack surface, so only connect services you actively use

These controls work at different points in the service and aim to reduce risk together. A failure can still expose information or allow an unwanted action. We describe their limits so you can make informed choices about the access you grant.

Account Deletion

Use the account-deletion control in Settings to request deletion. A three-day grace period lets you cancel the request. After it expires, the deletion workflow disables account access and removes covered conversations, People data, saved skills and guardrails, memory, Health records, linked-bank data, and supported per-user telemetry. Cleanup and provider requests can take time. Some account and authentication records, billing, fraud-prevention, security, deletion, backup, aggregate, or legally required records may remain. The current self-service workflow does not automatically erase every connected-account credential or cloud workspace. Ask us to include them in your deletion request; the limits of the self-service controls do not reduce your legal deletion rights. Check subscriptions and phone services separately; do not assume an account-deletion request immediately cancels every paid service. You can also make a privacy request at [email protected] as explained in our Privacy Policy.

Vulnerability Disclosures

To report a vulnerability, email [email protected]. We aim to acknowledge complete reports promptly, but do not promise a fixed response time on this page.

Avoid accessing data that is not yours, disrupting the service, or destroying data, and allow reasonable time for assessment before public disclosure. Any formal safe-harbor or bounty terms must be confirmed in writing.