Security

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

Orion is built by the Zinley team (zinley.com). 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 Orion (and any AI tool) carefully. This page is intended to provide the transparency needed for that evaluation.

To report a vulnerability, contact security@meetorion.app or submit it through our GitHub Security page. 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.

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.

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 conduct penetration testing at least annually through reputable third-party firms. Visit trust.meetorion.app to request reports.

How We Protect the Representative

Orion is an interconnected personal 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: Orion'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. The representative is prompted to review its own work before delivering results. For larger changes (10+ edits), sub-representatives with reviewer personas are spawned for a more thorough review. This operates within the same LLM -- it is a structured self-review process, not an independent verification system. 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 Orion -- file access, shell, browser, APIs -- is individually gated with its own enable/disable control
• Explicit user approval is required before any action is taken (file changes, calls, system operations)
• 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

Orion's primary containment mechanism for file access:

• You define exactly which folders Orion 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 Orion 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 Orion work. Containment relies on the guardrail system checking every file and shell operation, combined with the permission model above.

Skill Security

Orion supports custom skills -- reusable routines that extend its capabilities. Every skill undergoes security scanning:

• Automatic static analysis when a skill is loaded, created, updated, or modified externally -- 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
• The scanner runs in the main process, so a skill cannot tamper with 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 Orion 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 apply skill files from untrusted sources, do not import 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

Orion runs on desktop (macOS, Windows, Linux), mobile (iOS, Android), CLI, and through messaging apps (Telegram, Discord, WhatsApp, Slack, iMessage).

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, and WebSocket connections
• meetorion.app: Authentication, dashboard, and account management
• api.zinley.dev: Skills and characters
• storage.googleapis.com/meetorion: App updates and releases

Messaging Apps

When you access Orion 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 audio is processed in real-time and not recorded or stored beyond the active session. Call metadata (time, duration, outcome) is retained for up to 90 days for your records.

AI Requests

Orion 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 (OpenAI/Anthropic/Google).

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 third-party models from OpenAI, Anthropic, and Google, and we maintain zero data retention agreements with all of them. 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 is not viewable by any Zinley team member
• 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): Retained for up to 30 days for service operation, then deleted
• Enterprise (Zero Data Retention): No data persisted beyond the active request -- available on request
• Phone call audio: Not recorded or stored. 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@meetorion.app.

File Indexing and Memory

Orion 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, Orion 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. Orion 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 Orion'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 available for qualifying customers
• 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 Orion'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 Orion requires for your tasks
• Review permission prompts carefully -- Orion requests approval before acting. Do not approve actions without review
• Keep Orion 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, navigate to Settings, select "Advanced," and 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, follow the guide on our GitHub Security page or email security@meetorion.app. 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.