Security Practices
How A & A Labs protects customer and end-user data, and how to report a vulnerability.
Version 1.0 · effective . Previous versions are available on request from legal@aa-labs.co.
This page describes how A & A Labs protects the data our customers and their end users trust us with. It is deliberately specific: everything below is a control that exists today, not an aspiration.
1. Reporting a vulnerability
Email security@aa-labs.co. Include enough detail to reproduce the issue. We will acknowledge within 3 business days and keep you updated until it is resolved.
Safe harbour. We will not pursue legal action against researchers who:
- act in good faith and avoid privacy violations, data destruction and service degradation;
- test only against their own account or assets we have agreed in writing — never against another customer’s workspace;
- access only the minimum data needed to demonstrate a finding, and delete it afterwards;
- give us reasonable time to remediate before public disclosure.
We do not currently run a paid bug bounty. We will credit reporters who want to be named.
2. Application security
- Tenant isolation. Every query against tenant-owned data is scoped to the authenticated user’s tenant at the framework level, so a missing filter in one place cannot leak another workspace’s records. Inbound messages that cannot be matched to an active channel are quarantined for review rather than filed under an arbitrary account.
- Credential encryption. Connected-channel access tokens are encrypted at the application layer, are excluded from serialisation, and are never returned to the browser or included in an export.
- Password storage. Salted hashes only. We cannot recover a password, and neither can anyone who obtains the database.
- Role-based access. Owner, administrator and agent roles limit what each team member can see; agents see only conversations assigned to them or ones they participate in.
- Webhook authentication. Inbound webhooks from Meta and from every payment gateway are rejected unless their signature verifies. The Meta data deletion callback on this site verifies an HMAC over the signed request before it will record anything.
- Rate limiting. Authentication endpoints are throttled to blunt credential-stuffing.
- Mass-assignment protection on privilege-bearing fields, so a crafted request cannot elevate an account.
- Audit logging of administrative actions.
3. Infrastructure
- All traffic served over TLS; HTTPS enforced in production.
- Data encrypted at rest by the underlying managed storage services.
- Secrets supplied through the environment at deploy time and never committed to source control or baked into container images.
- Databases and caches reachable only from the application’s private network, not from the public internet.
- Encrypted backups, rotated on a 90-day cycle.
- Health checks and a queue supervisor so a failed background job is retried and surfaced rather than lost.
4. Personnel access
- Production access is limited to the people who need it for support or incident response.
- Access is individual — no shared accounts — and is logged.
- Access is reviewed periodically and revoked when someone changes role or leaves.
- We access customer conversation content only when required to resolve a support request or investigate an incident.
5. Incident response
- We triage suspected incidents on discovery and contain before we investigate.
- Customers affected by a personal data breach are notified without undue delay and within 48 hours of us becoming aware, as required by our DPA.
- Notifications state what happened, what data was involved, what we have done, and what you should do.
- We conduct a post-incident review and fix root causes, not just symptoms.
6. Dependencies and change management
- Dependencies are pinned by lockfile and updated on a regular cadence; security advisories are checked on every install.
- Changes go through version control and code review before deployment.
- Sub-processors are reviewed before engagement and listed publicly at omvio Sub-processors.
7. What we do not yet claim
We hold no SOC 2 or ISO 27001 certification today, and we would rather say so than imply otherwise. If your procurement process requires one, tell us — we will be straight with you about timelines. In the meantime we are happy to complete a security questionnaire and to discuss specific controls in detail.
8. Contact
Security: security@aa-labs.co · Data protection: dpo@aa-labs.co