SOC 2 readiness in progress. No SOC 2 report has been issued yet. Subprocessors are listed separately.

Start Avalon

Security Practices

Last updated Effective Avalon Flow Inc., a subsidiary of Questili LLPsupport@avalonflow.com

For this policy, "Avalon," "we," "us," or "our" means Avalon Flow Inc., a subsidiary of 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.

For protected mailbox content, Avalon is designed to be zero-knowledge while the user's private passphrase is locked. The private passphrase gates the user-side unlock path, while tenant-aware AWS KMS wrapping protects Avalon’s protected-data boundary keys at the application layer. The intended defense-in-depth model is database encryption at rest, per-tenant application encryption for sensitive data, and KMS-managed key wrapping instead of relying on database-level logical separation alone.

The intentional exception is an unlocked session: when a user enters the passphrase, Avalon may temporarily decrypt protected content for the app and for server-side AI automation the user requests or enables, such as classification, drafting, meeting briefs, search, Flowboard updates, or approved actions. Outside that unlocked automation path, protected content remains unreadable without the passphrase-backed key.

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. If a user loses the passphrase while protected content is locked, Avalon cannot recover that locked content for support; recovery means reconnecting/re-ingesting data that still exists at the connected provider or deleting/resetting protected Avalon data.

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 AI automation carve-out

Avalon distinguishes between protected storage and intentional server-side automation. Protected customer content should remain unreadable while locked. The explicit exception is server-side AI automation that a user or customer enables and that needs selected context to classify, draft, summarize, brief, search, update Flowboard, or execute an approved workflow.

That carve-out is intentionally narrow:

  • AI features should receive only the context reasonably necessary for the task;
  • onboarding mailbox processing waits until private passphrase setup is complete and the final onboarding step is reached;
  • 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.

Avalon should not be read as claiming that end-to-end encryption remains intact while server-side AI automation is actively processing selected unlocked content. The accurate commitment is zero-knowledge/protected by default, with explicit AI processing where automation requires it.

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.