Security

01Security model

Orrerie treats the public browser, generated content, model output, third-party services and websites visited by an agent as separate trust boundaries. Identity, object ownership, plan rules and sensitive mutations are enforced on the server.

Client-side obfuscation and encrypted payload wrappers discourage casual extraction but are not treated as authorization. HTTPS, authenticated sessions, origin checks and server-side ownership checks are the security boundary.

02Accounts and sessions

• Google or verified email/password authentication when account mode is enabled.
• Password hashing, time-limited verification/reset flows and login throttling.
• Optional TOTP two-factor authentication with one-use hashed backup codes.
• Secure, HttpOnly session cookies and revocable HMAC-derived session handles.
• Separate administrator authentication and CSRF boundary.

03Secrets and connectors

API keys, OAuth tokens, vault values and connector credentials are encrypted at rest, masked on readback and scoped to the account and mission that needs them. Known secrets are redacted from mission events and logs at multiple boundaries.

Remote MCP connections use public HTTPS endpoints and are screened against loopback, private, link-local, reserved and metadata addresses. Redirects and DNS resolution are rechecked.

04Agent and browser isolation

Agent work is constrained to an account- and conversation-scoped workspace. The sidecar is loopback-only and authenticated by the PHP service. Local-network access and local port binding are denied inside the mission containment model.

Browser targets have separate network guards and scoped profiles. External writes can require user approval. These controls reduce risk but do not make arbitrary instructions safe; users must follow the Acceptable Use Policy.

05Content and publication isolation

User and model HTML is sanitized. Executable artifacts run in sandboxed frames, and folder applications use a separate publication origin so they do not share authenticated-console access. Public shares use random public identifiers and can be revoked.

06Payments

Current cryptocurrency payment callbacks require provider HMAC verification before they can change payment or plan state. Activation is idempotent, and confirmed paid records do not regress because of a stale status.

Orrerie does not currently collect card details. Any future card integration should use provider-hosted collection, signed webhooks, idempotent fulfillment, fraud controls and refunds to the original method.

07Responsible reporting

Send suspected vulnerabilities or account compromise to hello@orrerie.com with SECURITY in the subject. Stop testing if you encounter another user’s data, do not retain or disclose it, avoid disruption, and provide the minimum reproduction detail needed.

This page describes implemented controls; it is not a claim of SOC 2, ISO 27001, PCI certification or a guarantee that incidents cannot occur.