Security Policy

1. Security program

Juno AI Labs maintains technical and organizational safeguards proportionate to Avalon’s risks. This page is a public summary, not a guarantee that every threat can be prevented and not a claim of a certification we have not listed. Contractual security commitments in an Order or Data Processing Addendum control if they conflict with this summary.

2. Regional service architecture

Each workspace is provisioned in a selected Global or EU architecture. The regional API scopes database, object storage, durable coordination, queues, and workflows to that environment. Workspace identifiers are included in resource queries and authorization checks, and workspace role checks protect administrative actions.

Network and provider services can operate outside the selected data region as explained in the Privacy Policy and Sub-processors list.

3. Identity and access

• Short-lived sessions and scoped handoffs limit reusable browser-to-desktop credentials.
• Google authorization uses state validation and PKCE, with single-use exchange tickets.
• WebSocket access requires exact allowed origins and one-time ticket handling.
• Workspace membership and role checks are enforced at protected resource boundaries.
• External actions run with the permissions of the connected user or workspace installation.

4. Credentials, encryption, and secrets

Provider tokens are encrypted using authenticated encryption with associated workspace and provider context and versioned keys. Global and EU environments use separate key material. Secrets are supplied to services through protected deployment bindings and are not committed to source control. Sensitive authentication material is redacted from logs and excluded from model prompts.

The desktop application uses the operating system’s protected storage for refresh material. Invitation tokens are stored as hashes; plaintext invitation material is fragment-protected during handoff and is not placed in server query strings or logs.

5. Desktop application hardening

Avalon’s Electron renderer uses context isolation, disables Node.js integration, and runs in a sandbox. A narrow preload bridge mediates privileged operations. Content Security Policy restricts executable sources, and unexpected navigation and popup creation are denied. Deep links and OAuth handoffs are parsed against exact schemes, hosts, paths, and parameter shapes before launch.

6. Connected tools and automation safety

• Tool proposals are validated before execution and bounded to the authorized principal and workspace.
• Model context is limited to the resources needed for the task; connector tokens are never placed in prompts.
• Webhook ingestion uses HMAC verification, timestamp windows, replay protection, deduplication, schema checks, and body-size limits.
• Writes use idempotency and retry-safety controls. When a provider’s outcome is ambiguous, Avalon surfaces the uncertainty instead of blindly repeating a consequential write.
• User-directed activity is recorded through tool receipts and audit events where supported.

7. Logging, monitoring, and audit

Operational logging is designed to exclude secrets, private content, and model context. Security and audit events cover sign-in and session activity, membership changes, connector authorization and revocation, external writes, and automation lifecycle events. We use logs and request identifiers to investigate errors and suspected misuse.

8. Provider and software risk

We evaluate providers in light of the data and function they receive, restrict access by contract and configuration, and maintain a public Sub-processors list. We review application dependencies and deploy updates as risks and product changes require. Customer administrators remain responsible for their user access, connected-service configuration, endpoints, and data-classification decisions.

9. Incident response

We investigate suspected security incidents, contain affected systems, preserve relevant evidence, remediate confirmed issues, and notify affected customers or authorities as required. Processor breach notification obligations are described in the DPA. Do not send secrets or full Customer Content in an initial report.

10. Coordinated vulnerability reporting

When researching Avalon:

• use accounts and workspaces you own or have explicit permission to test;
• do not access, alter, retain, or disclose another person’s data;
• do not use denial of service, social engineering, spam, destructive testing, automated high-volume scanning, or physical attacks;
• stop and report if you encounter sensitive information or risk service availability; and
• give us a reasonable opportunity to investigate and remediate before public disclosure.

For good-faith research that follows these rules, we will not initiate legal action solely because you tested and reported a vulnerability. This statement does not authorize testing of third-party services or excuse violations unrelated to the research. We do not currently promise cash awards.

11. Customer security questions

For architecture or procurement questions, contact support@with-avalon.com. For personal-data questions, contact privacy@with-avalon.com.