Security Practices

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. 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.

3. 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.

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

4. 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.

5. 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.

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.

6. Logging, telemetry, and analytics

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.

7. 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 may restrict, disable, patch, rotate credentials, or change behavior in response to a vulnerability, incident, provider change, dependency issue, or abuse signal.

8. 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.

9. 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. Retention and deletion are described in the Data Retention and Deletion Policy.

10. 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, or enterprise-grade controls unless such claims are expressly published by Avalon or included in a signed customer agreement.

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

11. 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.

12. Contact

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