Security

Security is foundational to how we build and operate Zinley. This page provides a transparent overview of how we protect your data across every platform Zinley supports -- desktop, mobile, messaging apps, and phone calls made on your behalf.

We are actively growing and continuously improving our security posture. If you operate in a highly regulated or sensitive environment, we encourage you to evaluate Zinley (and any AI tool) carefully. This page is intended to provide the transparency needed for that evaluation.

To report a vulnerability, contact security@zinley.com. For security-related inquiries, use the same address.

Infrastructure and Compliance

Subprocessors

The following lists all third-party services that process your data, organized by level of data access. Your data is never used for model training and is retained only for the minimum period needed for service operation.

None of our infrastructure is located in China. We do not directly use any Chinese company as a subprocessor, and to our knowledge, none of our subprocessors do either. Some open-weights models in our lineup (Kimi, Qwen, GLM, MiniMax, DeepSeek) were originally developed by Chinese labs, but we run them exclusively on US-based infrastructure — the labs that built them never receive your data.

Internal Access

All team members are granted least-privilege access. Multi-factor authentication is enforced for AWS. Access is controlled through both network-level restrictions and secret management. Access reviews are conducted quarterly, and just-in-time privileged access requires approval workflows. Conversation content is not accessible to any Zinley team member, with two exceptions: content our automated safety systems flag, and any conversation you attach to a bug report.

Certification Roadmap

• SOC 2 Type II: In progress -- audit underway
• ISO 27001:2022: Information Security Management Systems -- planned
• ISO/IEC 42001:2023: AI Management Systems -- planned
• CSA STAR: Cloud Security Alliance -- under evaluation

We are establishing a recurring third-party penetration testing program as part of our SOC 2 Type II work, with engagements conducted by reputable independent firms. Email security@zinley.com for the current status and any available reports.

How We Protect the Representative

Zinley is a personal AI representative that takes real actions on your behalf, which makes it a high-value target for adversarial attacks. If an attacker can manipulate the AI into following malicious instructions -- through a file, a message, or a webpage -- the consequences can be significant. The following describes our defense mechanisms.

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 -- instruction overrides, role manipulation, hidden system commands, 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 is a detection-and-wrapping system, not a hard block. The AI is instructed to respect the security boundaries, but as with all LLM-based defenses, effectiveness depends on the model following instructions correctly. The permission system (described below) serves as an additional safeguard -- even if an injection bypasses detection, actions still require your explicit approval.

Call Fraud Detection

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

• AI-powered real-time analysis of every call request before it is placed -- checking 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 itself is hardened against injection -- it detects jailbreak attempts, role manipulation, encoded payloads, and emotional manipulation tactics
• Automatic blocking after repeated fraud flags -- phone access is restricted when suspicious patterns are detected
• If the AI analysis service is unavailable, calls are denied rather than allowed through
• Phone numbers in audit trails are hashed for privacy

Representative Safety Context

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

Quality Gate

After the representative makes file changes, a quality gate triggers verification. For larger changes (10+ edits), sub-representatives with reviewer personas are spawned for a more thorough review. Fresh agents with no shared context review the work before you see it -- independent checks, not the same model grading itself. Hard limits on retries and time prevent infinite loops.

How We Protect You from the Representative

In addition to protecting the representative from external threats, we ensure that the representative itself cannot act without appropriate oversight and user consent.

Permission Model

• Every tool available to Zinley -- file access, shell, browser, APIs -- is individually gated with its own enable/disable control
• Sensitive and novel actions require your explicit approval; routine actions run inside a permission envelope you define and can revoke
• Each action type requires separate permission -- granting file access does not grant shell access
• You can approve actions individually or allow them automatically for trusted operations
• Destructive commands (delete, remove) trigger a dedicated confirmation request
• Unrecognized or ambiguous operations fail closed and require manual approval

The permission model is our most critical security layer. Even if other defenses are bypassed -- such as prompt injection evading detection or a malicious skill passing the scanner -- the representative cannot act without your explicit approval.

Directory Guardrails

Zinley's primary containment mechanism for file access:

• You define exactly which folders Zinley can access -- everything else is off-limits
• All file operations and shell commands are checked against your allowed directories before execution
• Protection cascades automatically: blocking a folder blocks all its subfolders
• Root directory access (/ or C:\) is explicitly blocked
• Symlink resolution prevents bypass attacks where a symlink inside an allowed folder points to a restricted location
• Case-insensitive path comparison on macOS and Windows prevents case-manipulation bypasses
• Path traversal detection catches .. patterns attempting to escape allowed directories
• When Zinley encounters a path outside allowed directories, it prompts you with "Allow Once," "Allow Always," or "Deny"

This is not an OS-level sandbox. Electron's renderer sandbox is disabled to support the IPC bridge that makes Zinley work. Containment relies on the guardrail system checking every file and shell operation, combined with the permission model above.

Skill Security

Zinley supports custom skills -- reusable routines that extend its capabilities. Skills and guardrail rules are stored in your account's cloud library, not as files on your machine, so the same set is available to you on every device and surface. Every skill undergoes security scanning:

• Automatic static analysis whenever a skill is created or updated -- checking for shell command execution, 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
• Full-source analysis catches multi-line patterns (e.g., "read a file then send it to a remote server"), not just line-by-line
• 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 operate within 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 is passed through unsanitized -- a known trade-off between security and usability

Use skills from trusted sources. We recommend using skills provided and maintained by the Zinley team, as they are vetted, regularly updated, and automatically improved. Additional official skills are added over time. If you choose to use third-party skills, treat them as executable code: do not add skills from untrusted sources, do not add skills that request disabling security features, and review the skill's behavior before enabling it.

Guardrail Rules

The client application can load guardrail rules into the representative's context covering security (SQL injection, XSS, exposed tokens), code quality, data handling, and tool misuse. When present, the representative reads and follows these rules before taking risky actions. These complement the permission system but are advisory -- they guide the representative's behavior rather than enforce it at the system level.

Platform Security

Zinley runs on desktop (macOS, Windows, Linux) and messaging apps (Telegram, Discord, WhatsApp, Slack, iMessage) today; iOS, Android, and CLI in early access.

Desktop App Hardening

• Context isolation enabled -- the rendering layer cannot access system-level APIs directly
• Node.js integration disabled in the renderer -- preventing direct system access from the UI
• 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 locked down -- the app cannot be redirected to external sites; external links open in your system browser
• Code is signed and notarized (macOS) with hardened runtime -- tampered builds will not launch
• Auto-updates are signature-verified before installation

Session Security

• WebSocket sessions use composite keys combining 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

• Authentication tokens stored with SameSite=Strict and Secure flags
• Sensitive local data (auth tokens, device identifiers) encrypted using AES-GCM 256-bit with device-specific keys derived via PBKDF2 (100,000 iterations) in production builds
• 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
• All API traffic flows over 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: Tiered limits per endpoint type -- general requests, AI generation, file operations, auth, and bug reports each have their own thresholds
• 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 messaging apps, your messages are processed through our secure API. Message content is retained for up to 30 days for service operation and then deleted. Each platform connection uses its own authentication tokens.

Phone Calls

Call metadata (time, duration, outcome) is retained for up to 90 days for your records.

AI Requests

Zinley makes AI requests to our server when you chat, when it makes calls, when it runs tasks, and sometimes in the background to build context or leverage its memory. A typical request includes your conversation history, relevant files, memory context, and task state. This goes to our AWS infrastructure, then to the appropriate model provider (Anthropic, OpenAI, Google, or a US-hosted open-weights provider — see the subprocessor list above and the full lineup on our Models page).

All data flows over TLS. Even if you have configured your own API key, requests are routed through our AWS infrastructure, as request construction occurs server-side. Direct routing to enterprise AI deployments or self-hosted servers is not currently supported.

Your Data Is Never Used for Training

Zinley does not build AI models. We use frontier models from OpenAI, Anthropic, and Google under zero data retention agreements, and open-weights models served by US-based inference providers that do not train on your data. Your data is never used for model training.

• Your inputs, outputs, and conversation history are never used to train any AI model
• We have zero data retention agreements with all our AI model providers
• Your conversation content isn't viewable by any Zinley team member -- with two exceptions: content our automated safety systems flag, and any conversation you attach to a bug report
• We log only errors, performance metrics, and operational data -- not your raw conversation inputs or file contents

All users -- Free, Plus, Pro, Max, and Enterprise -- receive the same level of data protection. There are no tiers or configuration options that affect this policy.

Data Retention

• All plans (default): Server operational copies of inputs and outputs are retained for up to 30 days for service operation, then deleted. Your saved conversation history stays in your account until you delete it
• Enterprise (Zero Data Retention): No data persisted beyond the active request -- available on request
• Phone call metadata: Retained for up to 90 days
• Safety-flagged content: Up to 2 years for inputs/outputs; up to 7 years for trust and safety scores
• Feedback and bug reports: Retained for up to 5 years (bug reports include full conversation history)

Enterprise customers can request Zero Data Retention (ZDR) configuration. Contact sales@zinley.com.

File Indexing and Memory

Zinley can semantically index your files and build persistent memory of your preferences and routines. Indexing is enabled by default and can be disabled in settings.

When enabled, Zinley scans permitted files on your device and computes secure hashes. Files and directories in your ignore settings are excluded. On our end, we chunk and embed the data, storing embeddings securely with obfuscated device identifiers and file paths for filtering. Indexing is used solely for search and coordination -- never for model training.

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 (latency, reliability, usage patterns) to maintain service performance. This does not include your conversation content, file paths, or personal data. We also collect error logs and crash reports for debugging purposes -- strictly operational data, no personal content.

You can disable telemetry and error reporting in your account settings. Disabling these does not affect Zinley's core functionality.

Enterprise Security Controls

For organizations with stricter requirements:

• SSO: SAML 2.0 and OIDC-based single sign-on
• Zero Data Retention: No data persisted beyond the active session
• HIPAA: BAA support is on our roadmap -- contact sales@zinley.com to discuss timelines and qualifying requirements
• Audit Logging: Comprehensive logs of all operations for compliance review
• Role-Based Access: Granular permission controls for team members and devices
• Admin Data Controls: Organization-wide data retention and privacy policies

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 automatically updated. Avoid skills or routines from untrusted sources
• Restrict directory access -- only grant access to folders Zinley requires for your tasks
• Review permission prompts carefully -- Zinley requests approval before acting. Do not approve actions without review
• Keep Zinley updated -- security improvements are included in every release
• Limit third-party integrations -- each connected service increases the attack surface. Only connect services you actively use

Our security architecture is designed with defense in depth -- multiple independent layers so that if one is bypassed, others provide protection. We are committed to transparency about both our capabilities and their limitations.

Account Deletion

To delete your account, open Settings and scroll to the "Danger zone" at the bottom, then choose "Delete account." All associated data -- including indexed files, memory, conversation history, and connected platform data -- is permanently removed. Data is not moved to a backup or archive.

Vulnerability Disclosures

To report a vulnerability, email security@zinley.com. We will acknowledge your report within 5 business days.

We request that you allow reasonable time for us to address vulnerabilities before public disclosure. We do not pursue legal action against security researchers acting in good faith. A bug bounty program is under evaluation.