Security

Zinley can work on computers you connect and communicate with other people as itself. This page explains how we protect your data, tools, messages, and calls.

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

The following lists the primary third-party services we currently use, organized by level of data access. The exact provider can depend on the model, channel, and feature you choose. Every AI provider below is reached through an enterprise API endpoint whose terms exclude customer content from provider training, and none of those accounts is enrolled in a data-sharing or model-improvement program.

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. Current routing and regional availability can change as providers change.

Internal Access

Team access is restricted through role, service, network, and secret-management controls, with multi-factor authentication where supported. Authorized access to customer content is limited to operational needs such as a support request you submit, reliability work, safety or abuse review, a security investigation, or a legal obligation.

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

Zinley is a personal AI assistant that can take real actions and represent you within your rules, which makes it a valuable target for attackers. Malicious instructions can arrive through a file, message, or webpage, so the following protections are built into the system.

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: A dedicated system scans external content for known injection patterns, including instruction overrides, role manipulation, hidden system commands, and encoded payloads. Detected content is flagged and wrapped in security boundaries that mark it as data, not instructions
• Unicode normalization: Catches obfuscated attacks using fullwidth characters and lookalike substitutions
• Input sanitization: Control character stripping and length enforcement before content reaches the AI
• System prompt protection: Zinley's system instructions explicitly tell the AI to treat all external content as data. Server-injected context markers that only our infrastructure can create ensure the AI can distinguish real instructions from injected ones

This system detects and wraps suspicious content. It is not a hard block, and its effectiveness depends on the model following its security instructions. The permission system described below adds another safeguard, so sensitive actions still need your approval even if an injection bypasses detection.

Call Fraud Detection

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

• AI-powered analysis checks every call request before it is placed for money transfer fraud, impersonation, scam patterns, harassment, illegal activity, privacy violations, and threats
• Input sanitization removes control characters and enforces length limits on all fields before they reach the analysis model
• The fraud detector is hardened against injection and checks for jailbreak attempts, role manipulation, encoded payloads, and emotional manipulation
• Repeated fraud flags automatically restrict phone access
• If the AI analysis service is unavailable, calls are denied rather than allowed through
• Phone numbers in audit trails are hashed for privacy

Assistant Safety Context

• The system tracks assistant behavior patterns and failures across operations with a rolling memory window
• When repeated failures or suspicious patterns are detected, additional safety context is added to the assistant's prompts to help it reason about what went wrong
• This signal is advisory. The assistant considers it with the rest of the context. It is not a hard block
• Hard iteration limits prevent infinite loops or runaway assistant behavior regardless

Quality Gate

After the assistant makes file changes, a quality gate triggers verification. For larger changes, fresh reviewers with no shared context can inspect the work before you see it. Hard limits on retries and time prevent infinite loops.

How Actions Stay Within Your Rules

Zinley can use the connected accounts, operating-system access, and permissions available to the app. Protected actions are designed to require approval unless you have configured them to run automatically, and supported permissions can be changed or revoked.

Permission Model

• Supported tools expose permission controls appropriate to that tool, which may include enable or disable settings and per-action approval
• Review each tool’s approval settings. Some supported operations can be allowed automatically.
• Each action type needs separate permission. Granting file access does not grant shell access
• You can approve actions individually or allow them automatically for trusted operations
• Supported destructive actions can require confirmation, depending on the tool and settings.

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; disabling the guardrail or leaving the blocklist empty allows all paths
• Zinley's own internal data directories remain available so the app can operate
• Path checks normalize and resolve paths, including symlinks, before comparing them with blocked directories
• The settings interface does not allow an entire root drive or the Unix root directory to be added to the blocklist

Electron's renderer sandbox is disabled to support the desktop bridge. Use operating-system permissions and a separate user account when stronger isolation is required.

Skill Security

Zinley supports custom skills, which are reusable routines that extend its capabilities. Skills and guardrail rules are stored in your account's cloud library, so the same set is available through every approved device and channel. Every skill undergoes security scanning:

• Automatic static analysis checks every skill when it is created or updated for shell commands, dynamic code evaluation, crypto mining, environment variable harvesting, and data exfiltration
• Critical findings trigger automatic sanitization: dangerous calls are commented out, mining URLs are removed, suspicious network connections are blocked
• Analysis of the full source catches patterns across several lines, such as reading a file and then sending it to a remote server
• Every write to the cloud library is scanned again on our servers, so the result does not depend on the client that submitted it
• Skills use the same permission and guardrail framework. A skill cannot bypass directory restrictions or execute commands without approval
• If the scanner encounters an error, the skill passes through without sanitization. This is a known trade-off between security and usability

Use skills from trusted sources. We recommend skills provided and maintained by the Zinley team because they are vetted and regularly updated. If you use a skill from somewhere else, treat it as executable code. Review what it does before enabling it, and never add one that asks you to disable security features.

Guardrail Rules

The client can load guardrail rules into the assistant's context for security, code quality, data handling, and tool misuse. When present, the assistant reads them before taking risky actions. These rules complement the permission system but remain advisory. They guide behavior rather than enforce it at the system level.

Platform Security

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

Desktop App Hardening

• Context isolation prevents the rendering layer from accessing system APIs directly
• Node.js integration is disabled in the renderer, preventing direct system access from the interface
• All communication between UI and system layers goes through a whitelisted context bridge
• DevTools are blocked in production with multiple detection methods
• Content Security Policy restricts scripts, connections, and resources. unsafe-eval is excluded
• Navigation is locked down. The app cannot be redirected to external sites, and external links open in your system browser
• 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

• WebSocket sessions use composite keys that combine device identity with session-specific tokens. A device ID alone is never sufficient
• Session tokens are required on connection; connections are rejected if missing
• Responses are delivered only to the exact session that requested them
• Sessions are cleaned up immediately on disconnect or logout
• Firebase token verification is enforced on all WebSocket connections in production

Authentication and Token Security

• The desktop app uses Firebase browser-local persistence, which stores the Firebase sign-in session in IndexedDB
• Selected application storage keys are encrypted with AES-GCM and a PBKDF2-derived key in production when WebCrypto initialization succeeds
• 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
• Token refresh with buffer window to prevent expired-token race conditions
• Security headers via Helmet middleware (X-Content-Type-Options, Strict-Transport-Security, X-Frame-Options)
• HTTP Parameter Pollution protection on all API endpoints
• Supported production API endpoints use TLS

Input Validation

• File paths validated against null byte injection, path traversal, tilde expansion, and non-absolute paths
• URLs validated to block non-HTTP protocols and localhost/internal IP access (SSRF prevention)
• All inputs sanitized for control characters with enforced length limits
• Device IDs validated against injection characters

Rate Limiting

• API-level: Each endpoint type has its own threshold, including general requests, AI generation, file operations, authentication, and bug reports
• Infrastructure-level: Per-IP request and connection limits at the reverse proxy, with stricter limits on auth endpoints
• Client-level: Built-in limits for API calls, file operations, auth attempts, tool execution, and WebSocket messages
• Usage quotas: Tier-based token limits with rolling windows
• Fraud auto-blocking: Repeated abuse flags automatically restrict high-risk features

Network Domains

If you are behind a corporate proxy or firewall, allow the following domains:

• snowx.ai and *.snowx.ai: API requests, AI processing, skills and guardrails, and WebSocket connections
• zinley.com: Authentication, dashboard, and account management
• storage.googleapis.com/meetorion (legacy bucket name): App updates and releases

Messaging Apps

When you access Zinley through a supported messaging app, messages are processed through our API and may become part of saved conversation history. Saved conversations remain until you delete them; limited operational AI logs are configured to expire after seven days. Each platform connection uses its own credentials or tokens.

Phone Calls

The call history visible in the product depends on your plan. Those visibility windows do not themselves delete older records, and some call records and recordings may be stored longer.

AI Requests

Zinley makes AI requests when you chat, when it handles supported calls or tasks, and when authorized background work builds context or uses memory. A request may include conversation history, relevant files, memory context, and task state. It reaches Zinley's Google Cloud backend and may then be routed through Portkey or directly to the model, inference, search, or speech provider used for that task.

Supported production network traffic uses TLS. Provider routing, regions, retention, and data controls depend on the feature and endpoint in use and may change as the lineup changes.

AI Providers and Model Training

Zinley trains no model on customer content. Model traffic goes only to enterprise API endpoints whose terms exclude customer content from provider training. 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.

• We use enterprise API endpoints and terms that exclude customer content from provider model training, and we opt in to no data-sharing or model-improvement program
• 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

Data Retention

• Saved conversations: Remain until you delete them. Deletion moves a conversation to Trash 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: Raw events are configured to expire after 90 days and session rollups after 180 days; 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

File Indexing and Memory

Zinley can semantically index accessible files and build persistent memory of your preferences and routines. Availability and controls depend on the current product and device configuration.

When enabled, indexing may scan files available to the app, compute hashes, and send selected content for chunking and embedding. Directory blocklists and ignore settings can exclude configured paths. We store embeddings with device identifiers and file-path metadata for search and coordination.

Blocking specific files: Configure your device privacy settings to exclude specific files. Zinley will make a best effort to exclude those files from all requests.

Telemetry and Diagnostics

We collect operational metrics, errors, traces, and crash reports to maintain performance, security, and reliability. We configure supported diagnostics to avoid automatic PII attachment and design telemetry to minimize customer content. Limited identifiers, technical metadata, or context you submit with a report may still be included.

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:

• Use Zinley's built-in skills. They are vetted by our team and updated automatically. Avoid skills or routines from untrusted sources
• 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

Our security architecture uses several independent layers, so if one is bypassed, others still provide protection. We are committed to being clear about both our capabilities and their limits.

Account Deletion

To request deletion, open Settings, scroll to the "Danger zone," and choose "Delete account." A three-day grace period begins. After it expires, account access is disabled and supported conversations, people data, agent assets, memory, and per-user telemetry are erased through the deletion workflow. Minimal account, billing, fraud-prevention, security, deletion, backup, aggregate, or legally required records may remain. Subscriptions and phone lines may require separate cancellation or release.

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.