Security
Practices, data handling, compliance, and how to report vulnerabilities at Heal.
We take security seriously. Learn about our practices, data handling, and compliance measures.
General
Do you have a trust center?
Yes. Visit the Heal trust center or contact us.
Who are your data subprocessors?
We work with a limited set of trusted third-party service providers to help us provide, improve, and secure our services:
| Provider | Purpose |
|---|---|
| AWS | Infrastructure and hosting |
| GCP | Infrastructure and hosting |
| Azure Open AI | Large language models |
| Heroku | Application hosting |
| Clerk | Identity management |
| Betterstack | Log management |
| Linear | Issue tracking |
| Slack | Internal communications |
| Sentry | Application monitoring |
| PagerDuty | On-call and incident notifications |
Can you permanently delete my data?
Yes, we provide mechanisms for permanent data deletion, as governed by our Terms.
How can security vulnerabilities be reported?
We appreciate the work of security researchers and take all reports seriously. Security vulnerabilities can be reported confidentially to security@heal.dev.
We follow responsible disclosure practices and will:
- Acknowledge receipt of your report within 24 hours
- Provide an initial assessment within 72 hours
- Work diligently to verify and address valid vulnerabilities
- Keep you informed of our progress
Do you have a bug bounty program?
We do not have a compensated bug bounty program yet (stay tuned!). For now, we're very happy to celebrate researchers who submit security findings publicly on social media.
Researchers may report vulnerabilities using the following channels:
- Email: security@heal.dev
- PGP key: available upon request for encrypted communication
How do you keep one customer’s data isolated from another’s?
For our multi-tenant offering, row-level security enforces hard multitenancy. For our single-tenant offering, each customer has their own cluster, database, and (upon request) single-tenant LLM deployment.
What customer data do you collect, and how is it encrypted?
We store only the artifacts required to generate, execute, and debug tests — test steps, test variables, logs, screenshots, and (optionally) API keys or seeded credentials.
At rest: Data lives in our cloud provider’s encrypted block storage (AES-256), with AWS/GCP managed keys.
In transit: All traffic flows over TLS 1.2/1.3 with modern cipher suites.
How do you do quality assurance?
Testing is automated with Heal!
We also run exploratory QA on all new features to inform what Heal should automate!
Audit and Certifications
Do you run regular external security audits?
Yes, we conduct regular external security audits and assessments to ensure the security and integrity of our platform. Our security program includes:
- Annual penetration testing by independent third-party security firms
- Quarterly vulnerability assessments
- Continuous automated security scanning
- Regular code reviews with security focus
Summary reports of our security audits are available to enterprise customers under NDA.
Is Heal.dev SOC2?
Yes. Heal is SOC2 type 2 certified. Additional details can be found on the Heal trust center.
Enterprise
Can you provide a single-tenant offering?
Yes, for enterprise customers with specific compliance or security requirements, we offer single-tenant deployment option, including single-tenant LLM services. This provides dedicated AI resources that are isolated from other customers' environments. Please contact our sales team to discuss your specific requirements and available options for single-tenant LLM solutions.
Do you provide SSO/SAML?
Contact support@heal.dev if you need Single Sign-On via Security Assertion Markup Language (SAML) or other enterprise-grade authentication controls for your organization.
Tests
Does Heal.dev access source code?
Heal.dev does not access customer source code. It uses a browser to interact with your app just as a user would. The only data Heal sees is what the browser sees.
Access to customer source code may occur only in limited circumstances:
- When explicitly requested by the customer for troubleshooting or support
- When necessary to address critical security vulnerabilities
- As required to fulfill specific contracted services
Any access to customer source code is:
- Limited to the minimum necessary for the specific purpose
- Conducted only by authorized personnel
- Subject to strict access controls and logging
- Handled in accordance with our confidentiality obligations
Customers maintain full ownership and control of their source code at all times.