Privacy Policy

1. Who we are and what this covers

Sythe LLC, doing business as Sythe Labs ("Sythe Labs", "we", "us"), operates Knell, a continuous cloud security posture scanner. This policy applies when you use Knell: creating an account, signing in, connecting cloud provider accounts, running scans, and reading findings, inventory, and attack paths.

Where a customer uses Knell under a subscription or services agreement, that agreement governs how we handle the customer's data and controls over this policy if the two conflict. In that relationship the customer decides what data enters Knell and we process it on the customer's instructions.

2. What we collect

• Account and sign-in records: your name, email address, organization membership, role, OAuth claims from Google or Microsoft when you sign in that way (including your Google email address), and the IP address recorded on each session.
• Cloud-scan snapshots: for every connected provider account, the identities, identifiers, IP addresses, tags, configuration, and status our documented read operations return, stored with each scan.
• Customer-supplied cloud credentials: the role details, keys, and tokens you provide so scans can read your cloud accounts, described in sections 3 through 6.
• Billing records for your organization's subscription, processed through Stripe.
• Sign-in emails sent through Resend, and operational logs, which also ship to PostHog only when that integration is configured.
• Cookies: a session cookie under our own prefix that resolves SameSite lax or strict, and a sidebar-state cookie that remembers whether the navigation is open.

Scanning only reads. Every connector performs documented read operations and never deploys or changes anything in your cloud accounts. Full snapshots are stored with each scan so findings, inventory, and attack paths derive from the same data. Harvested secrets are redacted before results are stored, and credential material is write-only: accepted on create or rotate, never returned to a client, and never written to logs.

We do not sell personal information, and we do not use any of it for advertising. We do not knowingly collect information from anyone under 16.

3. Amazon Web Services

When an authorized user connects AWS we process either an IAM role ARN with a server-generated external ID, our recommended method, or an access key ID with its secret access key and optional session token. During identity capture we also call DescribeOrganization to record the organization ID and management account ID shown on the provider detail page.

From scheduled and manual scans we process account identity, resource inventory, configuration, findings, and coverage across the collected services. Whatever the credentials allow, Knell performs only documented reads and never creates, edits, or deletes anything in your AWS accounts.

4. Azure, Google Cloud, and Kubernetes

When an authorized user connects Azure with a service principal we process the tenant, subscription, client ID, and client secret you supply. Host-based modes use the worker's own credentials and store no secret. When an authorized user connects Google Cloud with a service account key we process the key you supply; host-based user and service account modes store no secret. When an authorized user connects Kubernetes we process the kubeconfig you supply; managed AKS, EKS, and GKE clusters are read through the host's cloud credentials.

From scans we process identities, role assignments, resource inventory, configuration, and findings, including directory and membership reads used for access review. Whatever the credentials allow, Knell performs only documented reads and never creates, edits, or deletes anything in your tenants, projects, or clusters.

5. DigitalOcean, Railway, Neon, and Vercel

When an authorized user connects one of these providers we process the customer-owned API token or key you supply, stored server-side and write-only in the interface. From scans we process identifiers, names, configuration, and status for the resources the documented read operations return, which feeds your inventory, findings, and compliance evidence.

Whatever the token or key allows, Knell performs only documented read operations and never creates, mutates, or deletes anything at the provider. We do not use this data for advertising.

6. Cloudflare

When an authorized administrator connects Cloudflare we receive the selected account ID and a customer-owned API token, and we read the account name to tie the connection to the right organization. The token is stored server-side for as long as the connection is active.

From those reads we process account identity and settings and, for each zone, its identifier, name, type, lifecycle status, and security settings, which feeds your inventory and compliance evidence. Whatever the token can do, Knell performs only documented read operations and never creates, edits, pauses, deletes, rotates, or revokes anything in Cloudflare.

7. How we use it

• To run, secure, and support Knell and every connected provider account.
• To scan on schedule and on demand, and to derive findings, inventory, coverage, attack paths, and posture from the stored scan results.
• To keep an inventory of the cloud services connected to your organization.
• To answer support requests, tell you about the service, and fix problems.
• To detect and investigate misuse, and to meet our legal obligations.

8. Retention, disconnection, and deletion

We keep every scan by default, so history, trends, and first-seen and last-seen dates keep working. Archiving a provider account stops its schedule and deletes its stored credentials, while its scan history stays. Magic sign-in links expire after 15 minutes and sessions expire 7 days after they are created.

Users, organizations, and scans have no hard-delete path: removing an account archives it and keeps its history, and the staff audit log is append-only, keeping an intent row before every staff write and an outcome row after. Removing a connection does not revoke customer-owned tokens or keys at the provider; revoke those yourself in the provider's own console.

Historical evidence versions may remain where they are needed for security, legal, or operational reasons, including to preserve an audit trail you have already relied on. To correct provider-sourced information, change it at the provider and scan again.

9. Who we share it with

We use Resend to deliver sign-in emails, Stripe to process subscriptions, Railway to host the application and its database, PostHog for operational logs only when configured, and Google and Microsoft to sign you in. We use other service providers to host, operate, secure, and support the service; each is bound by contract to process data only on our instructions. We disclose information when the law requires it, to protect people, systems, or rights, or as part of a merger, acquisition, or sale of assets, in which case the successor is bound by this policy. We never use provider integration data to deploy, change, or manage resources at the provider.

10. Security

Harvested secrets are redacted before scan results are stored. Credential material is write-only: it is never returned to a client and never written to logs. Access is scoped to the organization that owns the data, and staff support access is gated with every staff write recorded in the audit log. No system is perfectly secure, and we will notify affected customers of a security incident involving their data as the law and our agreements require.

11. Your rights

You can ask us to access, correct, or delete your personal information, or object to how we process it, by contacting Sythe Labs from the email address on your Knell account and describing the request. We may ask you to verify your identity first. If your data reached us through a customer's connected cloud accounts, we may direct the request to that customer, since they control the data. Where a privacy law such as the GDPR or CCPA gives you additional rights, we honor them within the time the law allows.

12. International transfers

We are based in the United States and process data there. If you use the service from elsewhere, your information is transferred to and stored in the United States, and we rely on contractual safeguards with our service providers for any onward transfer.

13. Changes

We update this policy when our services or practices change. The current version is always at this address with its revision date. If a change materially reduces your rights, we will notify connected organizations before it takes effect.