Security Practices

Avalon is a product of Questili LLP. For this policy, "Avalon," "we," "us," or "our" means Questili LLP, unless a signed order form or customer agreement identifies a different contracting entity.

This Security Practices document summarizes the safeguards Avalon uses to protect Customer Content and operate the service responsibly. It is a security overview, not a promise of a specific certification, audit report, compliance status, uptime level, private-cloud deployment, or enterprise control unless a signed customer agreement expressly says so.

1. Security principles

Avalon is designed around these principles:

• minimize access to sensitive inbox, calendar, prompt, output, memory, and workflow data;
• use least-privilege permissions for connected services where practical;
• require human approval for material external actions unless a customer expressly configures an approved automation workflow;
• keep audit and execution receipts for sensitive actions where supported;
• avoid raw Customer Content in normal analytics, telemetry, logs, and support bundles;
• give customers controls to disconnect integrations, disable risky routes, and request deletion/export.

2. Current trust status

Avalon can describe the security controls that are implemented today, but should not overstate external assurance:

• SOC 2 readiness is in progress; no SOC 2 Type I or Type II report has been issued yet.
• External penetration testing must be completed and evidenced before Avalon makes broader enterprise assurance claims based on a pentest.
• The Subprocessor List explains hosted AI providers separately from BYO keys, custom endpoints, local models, and other customer-controlled systems.
• Organization admins can export audit-log evidence with digest-chain fields for sensitive security, privacy, integration, AI, and automation events.
• Incident response evidence, no-incident attestations, tabletop drills, customer notifications, and postmortems should be stored as restricted evidence, not committed to public source code.

3. Access control

Avalon uses account authentication, session controls, workspace/account boundaries, and role-based or feature-based access where available. Internal access to Customer Content is limited to authorized personnel with a business need such as support, security, incident response, or service operation.

Support access to sensitive Customer Content should be limited, logged where feasible, and used only for support, troubleshooting, security, or legally required purposes.

4. Encryption and secret handling

Avalon uses encryption in transit where supported by modern browsers, providers, and infrastructure. Sensitive credentials such as OAuth tokens, API keys, webhook secrets, and model-provider credentials should be stored and transmitted using appropriate safeguards.

Avalon has two protected-data modes during the protection update rollout. Legacy encrypted records depend on a private key unlocked with the user’s passphrase and a separate KMS boundary. After an account completes a verified protection update, migrated records use mailbox-scoped, server/KMS-managed encryption. Existing accounts do not change modes merely because this page has changed.

In managed-encryption mode, authorized Avalon server code can decrypt migrated records for app features and enabled background workflows. An optional app lock is an additional access check for the signed-in user; it does not remove the server’s ability to run authorized automation. This is not end-to-end or zero-knowledge encryption. The protection update must verify migration before the legacy passphrase dependency is removed.

Customers are responsible for protecting their own credentials, admin accounts, custom endpoints, local models, BYO model providers, and connected-service secrets.

Users can rotate their private passphrase. Legacy records may be unrecoverable if the passphrase is lost and no usable unlocked key remains; reconnecting a provider cannot restore Avalon-only notes or other data that the provider never held. After verified migration, an app-lock passphrase is separate from the data-encryption keys. Losing it does not itself destroy migrated data, but any recovery must still verify account ownership; this does not promise an available self-service recovery method.

Server-side KMS rotation is designed as a controlled rewrap: Avalon can re-encrypt protected-data boundary keys under a new AWS KMS key without decrypting mailbox content or changing the user's private passphrase. Old KMS keys should not be retired until rewrap evidence and sampled unlock/read checks pass.

5. Privacy boundary and authorized processing

Avalon distinguishes between encrypted storage, interactive app access and authorized background processing. Legacy encrypted records retain their passphrase-backed key dependency until verified migration. For migrated records, authorized app features and enabled workflows can use server-managed keys. Server-side AI automation may receive selected context to classify, draft, summarize, brief, search, update Flowboard, or execute an approved workflow.

Processing remains subject to these boundaries:

• AI features should receive only the context reasonably necessary for the task;
• onboarding mailbox processing requires the applicable account protection setup and the final onboarding step; the managed-encryption rollout does not waive feature, entitlement or mailbox-authorization checks;
• normal analytics, telemetry, logs, support bundles, and compliance evidence should not contain raw customer content, raw prompts, model completions containing customer content, OAuth tokens, API keys, or passwords;
• customer-selected AI providers, custom endpoints, and local models are separate trust boundaries controlled by the customer.

Neither an app-lock screen nor encryption at rest means Avalon is technically unable to process content. App lock, encryption and permission to run a workflow are separate controls. Normal telemetry and support evidence should remain metadata-only in both protection modes.

6. Google, Microsoft, and connected-service permissions

Avalon uses Google APIs/Gmail, Microsoft Graph/Outlook, and other connected-service permissions to provide enabled features. Permissions should be scoped to the customer workflow and reviewed before production use. Write-capable permissions and external actions should be handled carefully and approval-first unless the customer has explicitly configured a narrower automation workflow.

More detail is available in the Connected Services Permissions Disclosure.

7. AI, local models, and custom endpoints

Avalon may process Customer Content through hosted AI providers, customer-selected AI providers, local/private models, or custom endpoints depending on configuration. Avalon aims to send only the context reasonably necessary for the enabled feature.

Enterprise tenant controls can disable Avalon-hosted AI providers, require BYO/custom/local AI routes, disable autonomous actions, and require approval before outbound sends or mailbox mutations. Customer-controlled model routes, local models, BYO providers, self-hosted inference, and custom endpoints create additional security and data-handling risk. Customers are responsible for securing, validating, licensing, monitoring, and approving those systems. Avalon may restrict model routes or endpoints that create risk.

8. Logging, telemetry, analytics, and audit exports

Avalon uses logs, telemetry, analytics, health checks, and error tracking to operate and improve the service. Normal telemetry should avoid raw email bodies, calendar descriptions, Slack messages, CRM notes, endpoint payloads, prompts containing customer content, model completions containing customer content, AI memory text, OAuth tokens, API keys, passwords, payment card numbers, or other secrets.

Organization audit logs record security, privacy, integration, AI, automation, and admin events with redacted metadata. Admin CSV exports include request/support identifiers and hash-chain fields (prevDigest and digest) so a customer can preserve evidence without exposing raw mailbox content in the export by default.

Queue and internal background jobs use signed internal requests or verified QStash signatures, include route-scoped job headers, and reject jobs whose declared scope does not match the route being invoked. High-risk retry paths keep separate idempotency controls at the job or provider-event layer.

Avalon also separates first-party system emails from customer mailbox workflow using signed provenance rather than trusting display names, sender addresses, or unsigned custom headers. App-generated emails sent through Avalon-controlled delivery paths include an HMAC-backed system-email marker bound to the reason, sender, recipient, and subject. When those messages re-enter a connected Gmail or Outlook mailbox, Avalon verifies the marker before excluding them from Flowboard summarization, lane classification, and digest summarization. Unsigned or tampered messages continue through normal mailbox processing.

9. Vulnerability management

Avalon reviews security issues, dependency risk, application behavior, and vulnerability reports. Security researchers may report vulnerabilities according to the Vulnerability Disclosure Policy.

Avalon should complete an external penetration test and store the report, remediation plan, and retest evidence in restricted evidence storage before using pentest-backed enterprise claims in customer-facing materials.

Avalon may restrict, disable, patch, rotate credentials, or change behavior in response to a vulnerability, incident, provider change, dependency issue, or abuse signal.

10. Incident response

Avalon investigates suspected security incidents involving unauthorized access, data exposure, unsafe execution, token compromise, provider compromise, or other material security events.

When Avalon confirms an incident requiring customer notice, Avalon will notify affected customers without undue delay and provide available information about the nature of the incident, affected data, mitigation steps, and recommended customer actions where appropriate.

Avalon should run and record incident-response drills or no-incident attestations on a recurring cadence. Evidence should include incident commander, timeline, impacted systems, customer-notification decision, corrective actions, and redacted logs where applicable.

11. Backups, retention, export, and deletion

Avalon may use backups, audit logs, security logs, billing records, and operational records to maintain reliability, security, compliance, and dispute-resolution posture. The application has scheduled TTL cleanup for mailbox snapshots, cached metadata, generated digests, AI context, chat memory, saved knowledge, and expired Flowboard-derived content. Audit and security logs are retained longer for integrity, investigation, legal, and compliance reasons. Retention and deletion are described in the Data Retention and Deletion Policy.

12. Compliance and certification claims

Avalon does not claim SOC 2, ISO 27001, HIPAA, GDPR certification, DPDP certification, PCI certification, data-residency guarantees, private-cloud readiness, on-prem readiness, pentest completion, or enterprise-grade controls unless such claims are expressly published by Avalon after the relevant external evidence exists or included in a signed customer agreement.

Customers should not rely on roadmap items, implementation notes, or informal statements as security or compliance commitments.

13. Customer responsibilities

Customers are responsible for:

• configuring users, scopes, integrations, automations, custom endpoints, and model routes safely;
• reviewing AI outputs and external actions;
• protecting credentials and administrator accounts;
• complying with connected-service terms, model licenses, privacy obligations, and laws;
• notifying Avalon promptly about suspected security incidents involving Avalon.

14. Contact

For security questions or vulnerability reports, contact support@avalonflow.com.