Security & Responsible Disclosure

ALYT runs inside your home — a microphone, a set of automations that can control physical devices, and a platform that talks to your accounts on other services. We take security seriously precisely because of what a failure here could mean, not as a marketing line. This page describes how we build ALYT with that in mind, and how to tell us if you find something we missed.

ALYT's Security Practices

Architecture and design

Defense in depth — multiple independent layers (firewalling, rate limiting, encryption, authentication, and tenant isolation) so that a failure in one layer does not by itself compromise your data
Least privilege — services and credentials hold only the access they need to do their specific job
Tenant isolation — strict separation between households at the data layer, enforced by an explicit tenant identifier on every scoped request rather than inferred implicitly, specifically to prevent one household's data leaking into another's view
No inbound connections to a customer's home — the software running in your home reaches out to ALYT's servers; nothing reaches in. This removes an entire class of attack that depends on a customer's network being reachable from the internet.
Never keyed by IP address — a device's identity is its serial number or a stable protocol identifier, never its network address, which can change or be spoofed
No credentials shipped in firmware or images — a device knows only its own serial number when it leaves the factory; everything else (network credentials, broker access) arrives at provisioning time, over an authenticated channel, never baked into a shared image

Data protection

Encryption in transit — TLS/HTTPS on every connection, minimum TLS 1.2
Password hashing — Argon2id, a modern, deliberately slow hashing algorithm resistant to brute-force and GPU-accelerated cracking attempts
Hashed, not reversible, storage of tokens — refresh tokens, password-reset tokens, and API key secrets are stored as one-way hashes; we cannot recover your actual credential from our database even if we wanted to, and neither could an attacker who stole it
Sealed secrets at rest — MFA (TOTP) seeds and OAuth client secrets are encrypted at rest with an application-level key, separate from database access
Per-device credentials — each physical device gets its own unique broker (MQTT) credentials, so the compromise of one device's credentials does not expose any other device

Access control

Optional multi-factor authentication — TOTP-based two-factor sign-in, available to every account
Comprehensive audit logging — every security-relevant action is logged with who did it, when, and what changed
Short-lived access tokens with rotating refresh tokens — session tokens expire quickly, and refresh tokens rotate on use, so a stolen token has a limited useful lifetime
Rate limiting — on authentication and API endpoints, to slow brute-force and abuse attempts

Software practices

No hardcoded secrets — all sensitive configuration is loaded from the runtime environment, never committed to source control
Type safety — the platform is written in TypeScript throughout, which catches an entire class of bugs before they ship
Automated linting and testing — enforced on every change before it reaches production

Reporting a Security Vulnerability

Where to report

Email security@alyt.co. This mailbox is monitored and is the fastest way to reach us about a security issue specifically — please do not use general support channels for a vulnerability report.

A machine-readable version of this contact information is also published at /.well-known/security.txt, following the IETF's standard format (RFC 9116) so that automated security tools and researchers' workflows can discover it directly.

Please do not

Open a public GitHub issue describing the vulnerability
Post about it on social media or a public forum before we have had a chance to respond
Share it with anyone else before coordinated disclosure
Exploit it beyond the minimum necessary to demonstrate it exists
Access, modify, or exfiltrate data beyond what is strictly needed to prove the vulnerability, and never access another real household's data — use a test account you control

What to include

Summary — a one-line description
Vulnerability class — e.g., authentication bypass, injection, cross-site scripting, insecure direct object reference
Affected component — which service, endpoint, or app screen
Steps to reproduce — clear, ordered instructions
Impact — what an attacker could actually do with it
Proof of concept — code, screenshots, or a short video, without leaking any real household's data
Your contact details — email, and optionally a phone number for urgent follow-up
How you'd like to be credited, if at all
Your preferred disclosure timeline — 30, 60, or 90 days

Our response timeline

We acknowledge every report within 3 business days. From there:

Critical (affects household data, device control, or authentication broadly): patch target 7 days
High (a real security issue, partially mitigated by other controls): patch target 30 days
Medium: patch target 60 days
Low: addressed in the ordinary release cycle

If we cannot meet a target, we will tell you why and give you a revised one — silence is not an acceptable response to a security report, from us or to us.

Coordinated disclosure

We ask for time to patch before public disclosure — typically 90 days after the patch ships, or a shorter window (30–60 days) by advance agreement. In return, once the patch is out, you are free to publish, and we will credit your contribution in our release notes (unless you prefer to remain anonymous).

What happens after you report

Days 1–3: acknowledgment and a case reference
Days 3–5: confirmation we can reproduce it, and an initial severity assessment
Days 5–7: a target patch date
Patch release: we deploy the fix and notify you
After the agreed embargo: you are free to publish

What we do not offer

We do not currently run a paid bug bounty program. We are genuinely grateful for good-faith research and will say so publicly, but we want to be upfront that there is no monetary reward attached today, rather than let that assumption go uncorrected.

What Counts as Responsible

Good practice

Reporting only to security@alyt.co, not to other parties, until coordinated disclosure is agreed
Giving us reasonable time to patch before publishing
Testing only against accounts and data you control
Documenting your findings clearly, with reproduction steps
Cooperating with us to verify a fix before disclosure

Not responsible

Public disclosure before we have had a chance to patch
Selling the vulnerability, or attempting to extort payment for silence
Testing against another real household's account or data without their authorization
Accessing more data than necessary to demonstrate the issue
Refusing a reasonable embargo request for a serious issue

Legal Safe Harbor for Good-Faith Research

What is protected

If you conduct security research in good faith, consistent with this policy, we will not pursue legal action against you — including under the Computer Fraud and Abuse Act (CFAA) or equivalent state and international computer-misuse laws, the Digital Millennium Copyright Act (DMCA), or other applicable law — for:

Accessing your own test account or data
Testing against ALYT's own systems (not third-party services we integrate with, and not another user's devices)
Accessing data only to the minimum extent needed to demonstrate a vulnerability
Reporting through the process described above

What is not protected

Accessing another user's account or data beyond the minimum needed to prove a flaw
Deliberately causing your own data loss and then reporting it as a discovered vulnerability
Making unauthorized purchases or enabling paid features without authorization
Disrupting service for other users
Publicly disclosing before informing us, or before an agreed embargo expires

Known Security Trade-offs, Stated Plainly

We would rather tell you about a deliberate design trade-off than have you discover it and wonder whether we knew.

Push tokens are stored in plaintext

Apple's and Google's push infrastructure requires the actual device token on every send — there is no way to deliver a push notification using only a hash of the token, the way we can authenticate a password using only its hash. So push tokens are the one credential-like value we store unhashed. We mitigate this by treating them as secrets in every other respect: never returned by any API response, never written to logs, and deleted the moment the provider tells us the corresponding app installation no longer exists.

No end-to-end encryption on device commands

Commands travel from your app or console to ALYT's servers, then on to your device (directly or through an integration), encrypted in transit at each hop (TLS) but decrypted and processed at ALYT's servers in between — they are not end-to-end encrypted from your phone directly to your device. This is a deliberate architectural choice that enables the platform's automation, remote-access, and multi-device coordination features; it means that, in principle, someone who fully compromised our server infrastructure (and defeated TLS) could observe commands in transit. We mitigate this with the layered access controls and encryption described above.

Third-party integration credentials are held by ALYT

When you connect a service like Sonos, Ring, or SwitchBot, the credentials you provide are stored in ALYT's database (encrypted where the integration supports it) so that ALYT can act on your behalf. A compromise of that database could, in principle, expose those credentials. We mitigate this with encryption, access controls, and immediate deletion of credentials when you disconnect an integration.

Security Acknowledgments

We will list security researchers who have responsibly disclosed a vulnerability here, with their permission.

None yet recorded. If you are the first, we will credit you here and in our release notes.

Contact

Security vulnerability: security@alyt.co | machine-readable: /.well-known/security.txt

Other security concerns: support@alyt.co

Fizzify Inc.
30 N Gould St STE N
Sheridan, WY 82801
United States

Last updated: September 6, 2026