Privacy Policy

This policy covers the ShellOrbit website, the ShellOrbit dashboard, the source intake, and the API, and Leak Alarm, including log drains, the JavaScript SDK, Incident Alerts, and the MCP server. It explains what we hold and why in the same terms we would want to read.

Changes in version 1.8. Webhook forwarding has ended. Sources now receive security events from the systems you connect, and those events usually carry personal data about people in those systems, such as account names, email addresses, IP addresses, and approximate locations; we read them only to run your rules and raise findings (section 2). On Pro and Business the SDK can report the hostnames your app connects to (section 2). Resolved findings are deleted after your plan’s history window (section 4). This version applies to accounts created from 25 October 2026 at once, and to every other account from 24 November 2026; until then the previous version applies to them.

Changes in version 1.7. From 22 October 2026, revoking covers more providers, and you can send leaked keys to your own system. On Pro and Business, using credentials you give us, we can act on leaked keys at AWS, OpenAI, Anthropic, Google Cloud, Azure, Twilio, SendGrid, and Supabase. Where you turn it on, a key we find is sent, as data and never as a credential, to its issuer’s own endpoint: GitHub’s and Hugging Face’s token revocation services and Google’s API key lookup. A revocation webhook you add receives a masked value and a match code, never the key. Azure AI services keys are regenerated only after you confirm. Incident Alerts also matches the packages you declare (registry, name, and version) against OSV.dev, a public database of malicious releases and package advisories; we download its export whole and send nothing about you, not even a package name. From 22 October 2026, the sign up, sign in, emailed sign in, and password reset pages and the contact form on shellorbit.com use Cloudflare Turnstile to check that a person, not a script, is using them; Cloudflare receives your IP address and browser and device signals for that check. The contact form now sends your enquiry through ShellOrbit’s API to Zoho CRM, instead of straight from your browser, and we now record when and from where you accept the Terms and this policy. See section 2. This version also aligns the policy with India’s Digital Personal Data Protection Act 2023 and the Digital Personal Data Protection Rules 2025: it sets out the consent you give at sign up and how to withdraw it, your rights and how to exercise them, the right to complain to the Data Protection Board of India, how we tell you about a personal data breach (section 7), and cross border transfers (section 6). ShellOrbit is only for people 18 and older, and sign up now asks you to confirm it and to accept the Terms and this policy (section 11). This version applies to every account from 22 October 2026. Section 8 lists every cookie and browser storage item we use; all are strictly necessary, so there is no cookie banner.

Changes in version 1.6. From 22 October 2026, you can add your own AI provider to have incidents and findings explained. When you ask for an explanation, we send that item’s details, with masked values only, to the provider you chose, as described in section 2. That provider is your own, not our subprocessor. We store its credentials encrypted and keep each explanation for 7 days.

Changes in version 1.5. From 22 October 2026, ShellOrbit no longer scans GitHub repositories: the GitHub App is withdrawn and we no longer read any repository. From the same date, Incident Alerts uses the runtime versions the SDK reports, the certificate and server header details of your verified domains, and the stack you declare, as described in section 2. Matching happens inside our own AWS account, and nothing about you or your stack is sent to the public sources we download advisories from. This version also states that sign-in location is recorded only where it is available, sets out which plans and providers revoking covers, gives the retention of tripwire hits on its own line, and corrects the description of the dashboard’s session cookie.

Changes in version 1.4. From 19 October 2026, all email we send goes through Amazon SES, and our previous email provider no longer receives any data. The account records in Zoho CRM, product update email through Zoho Campaigns, support tickets in Zoho Desk, and the Leak Alarm sections described below apply from the same date, as does the sign-in history, with IP address, device, and approximate location, on every plan. Support tickets and contact form enquiries are now kept for 180 days from the last message.

Two kinds of data pass through the service, and they are treated differently:

• Account data is about you: your login identity, your source and rule configuration, your billing record, your account record, and your support messages. For this data we are the controller.
• Customer data is what we process for you on your instructions: event data, meaning what the systems you connect send to your sources, with headers and bodies, and the findings our rules raise from it, and Leak Alarm data, meaning findings, fingerprints, tripwire hits, and the stack details Incident Alerts uses. Either may contain personal data about other people. For this data you are the controller and we are the processor. The data processing addendum governs it.

1. Account data we collect

Identity and authentication. Email address, display name, username, sign in method, and session records, with the date you confirmed at sign up that you are 18 or older and the version of these terms you accepted. Authentication is operated by WorkOS on our behalf, including single sign on where you use it. We receive the identity claims your provider releases, not your password.

Sign-in history and sessions. Each sign in, wrong password or code for an existing account, and sign out, with the time, the method, the result, the IP address, the browser and operating system from the user agent, and, where it is available, an approximate location (city, region, and country) worked out from the IP address by Amazon CloudFront in front of our API. For each signed in session we keep the same details plus when it was last active. Owners and admins of an organization can see this for its members; each member sees their own. We use it to keep accounts secure and to let you spot a sign in you do not recognise.

Source and rule configuration. Source names and kinds, intake identifiers, signature formats, silent hours, masked fields, IP allowlists, your custom rules, alert settings, and team membership.

Billing data. Plan, subscription state, billing email, country for tax, invoice history, and the metered event counts your invoice is based on. Payment is handled by Dodo Payments as merchant of record. Dodo Payments collects and holds the payment instrument. We receive a transaction record and tax status, never a full card number.

Usage and telemetry. Event counts, event sizes, signature results, error classes, dashboard actions with timestamp and actor, and API request logs. Request logs include IP address and user agent.

Account record. When you create an account we keep a record of it in Zoho CRM: your email address, name, sign in method, plan, billing cycle, monthly revenue, account and user ids, signup date, the date you were last active, and the stage your account has reached, such as verified, trial, paying, or cancelled. We also record how you found us: the UTM source, medium, and campaign, the referring site, and the first page you visited. These travel in the signup link, not in a cookie. The last active date is updated at most once a day.

Product update email. Only if you tick the marketing box at signup, which is never ticked for you, or opt in later. We send your email address, name, and the record of your consent to Zoho Campaigns, and Zoho sends you a confirmation email before anything else. Zoho Campaigns records whether each email was delivered, opened, or clicked. Unsubscribe from any email or in the dashboard at any time. Transactional email, such as sign in codes, alerts, and billing notices, is separate and does not depend on this choice.

Support tickets and correspondence. Anything you send to a ShellOrbit address, with its attachments and metadata. A ticket you create in the dashboard is held in Zoho Desk with its subject, description, your email address and name, your plan, your account and user ids, and the status and priority shown back to you; replies continue by email.

Domains and connected services. The hostnames you verify, the verification record and the result of each recheck, and the log drains you create. Credentials you give us for a connected service, such as an account we may revoke keys in or the AI provider you add for explanations, are encrypted with a separate key, used only for what you allowed, and deleted when you disconnect or remove them.

Enquiries sent through the contact form. First and last name, email address, company, position where you give one, subject, and message. The form sends your enquiry to ShellOrbit’s API, which checks it with Cloudflare Turnstile and passes it straight on to Zoho CRM, where it becomes a contact record with your message as a note and the reply thread is kept. We do not store or log the enquiry on the way. Use one of the email addresses on the contact page if you would rather not have a CRM record created.

Diagnostic data. When something breaks in the dashboard, the API, or a background worker, an error report is sent to Sentry: the exception and stack trace, the request path and method, the source and event ids involved, browser and operating system, IP address, and your account id. Request and response bodies are stripped before the report is sent, and headers carrying authorization, cookies, or signatures are removed.

Site analytics. The marketing site is measured with aggregate, cookie free counts of page views and referrers. There are no advertising trackers, no cross site profiling, and no data broker feeds.

Security research reports. If you report a vulnerability to us, we hold your report, the correspondence about it, and whatever contact address you wrote from. If you ask to be credited on the Hall of Fame, we also publish the name or handle you choose and, where you give us one, a single link to a profile or site of yours.

That publication is the one thing on this page we do purely on consent. We do not publish anything until you have told us to, silence is treated as a no, and you can have the entry changed or removed at any time by writing to security@shellorbit.com. We will act on that without asking why, and it will never affect how a report of yours is handled. Reporting anonymously is always available and is not a lesser option.

2. Customer data we process for you

For each request a source receives we store the headers, source IP, timestamp, the raw body, and whether its signature checked out. Oversized bodies are stored in object storage instead of the primary table, with the same retention.

Events from the systems you connect are security records, and they usually carry personal data about people in those systems: account names and identifiers, email addresses, IP addresses, approximate locations, and what each person did, such as signing in, failing to sign in, or changing a setting. Your own app’s events carry whatever you choose to send, and we ask for an identifier rather than an email address where you can. You are the controller of this data, and you decide which systems to connect and which events they send.

We read event content only to run your rules over it and raise findings, show it back to you, check its signature, and enforce size limits. Findings keep the details a rule matched, such as the repository, the account, or the event name. Event content is not used to train models, is not shared with advertisers, and is not sold in any form.

You control what your systems send. Send only the events your rules need, mark fields to mask in the inspector, and if an event should not contain a national identifier, a health record, or card data, fix that at the system that sends it.

Leak Alarm. We process the following only for what you verify or connect:

• Scans of verified domains. We fetch the pages and files a browser would and look for exposed keys, exposed .env, .git, and source map files, open Supabase tables, and open Firebase rules. Content is discarded once scanned. A finding keeps the kind of key, where it was found, and a masked value such as sk_…a1b2. For an open table we record its name and that it can be read, never its rows. Each scan also records the certificate chain the site presents, with each certificate’s issuer, expiry, serial number, and a hash of its public key, and the server software and version the site announces in headers such as Server and X-Powered-By, with the hosting and backend platforms those headers and the page point to.
• Log drains. Each line is scanned as it arrives and then dropped. Log lines are never stored.
• Outbound traffic watch. Unless you turn it off, the SDK reports the hostnames, ports, and protocols your app connects to, and the name of the npm package or your app that opened each connection. Never a path, query string, header, or body. We keep the hostnames each project has used so a new one can raise a finding, for as long as the SDK project exists.
• The JavaScript SDK. It sends masked values and one way, salted fingerprints of your app’s keys, never a key itself, so we can tell you when your real key turns up somewhere. Unless you turn it off, it also reports the runtime it runs on: the Node.js and OpenSSL versions, the operating system platform, and the processor architecture. It sends no hostnames, environment variables, or package lists.
• Incident Alerts. The products, versions, and labels you declare as your stack, together with what scans, the SDK, and your findings show about it, are matched against public security advisories. Matching happens inside our AWS account. We download advisories from public sources, namely the Node.js release index, the Go vulnerability database, endoflife.date, the CISA Known Exploited Vulnerabilities catalog, Mozilla’s certificate revocation list, and OSV.dev’s export for the package registries, and send nothing about you or your stack to them, not even a package name. We never read your code or repository: packages are only those you declare or paste, and a pasted list is read in your browser and saved only as the packages you add. A match is kept as a finding.
• Tripwires. When a tripwire is touched we record the time, the tripwire, what was touched, and the source IP address and user agent of the request. The person who touched it is usually not your user and not ours, and may be an attacker or an automated agent. We keep only that request metadata and never run anything on their machine.
• Revoking. On Pro and Business, using credentials you give us, we act on leaked keys you have allowed at AWS, OpenAI, Anthropic, Google Cloud, Azure, Twilio, SendGrid, and Supabase (where we lock open tables), after ten minutes in which you can cancel. Azure AI services keys are regenerated only after you confirm. To find the right key we compare it with what the provider lists, in memory; we store only the provider’s own id for it. If you turn on GitHub or Hugging Face, a leaked token a scan of your verified domain finds is sent to that company’s token revocation service, which revokes it and tells its owner. If you connect Google Cloud, a Google API key we find is sent to Google’s API key lookup to learn which of your keys it is. Nothing else about you goes with these. If you add a revocation webhook, your own endpoint receives the finding with a masked value and a match code made with your webhook’s secret, never the key. We record what was done, when, and by whose permission.

AI explanations. If you add your own AI provider and ask for an incident or finding to be explained, we send that provider the item’s details as the dashboard shows them: for an incident, the advisory and where it matched your account; for a finding, its title, severity, source, the kind of key, the masked value, where it was found, and the fix. Never a secret, which we do not hold. The provider processes the request at your direction, under your account and its own terms. We use your provider credentials for nothing else. The explanation is kept for 7 days.

We never use a key we find as a credential, never test whether it works, never store a key in full, never scan a domain you have not verified, never probe a site for flaws, and never show a full key to you or to an AI agent connected through the MCP server.

3. Why we hold each category

Where we rely on legitimate interest we have considered your interests too, and you can object using the contact in section 9.

Under India’s Digital Personal Data Protection Act 2023. We process your account data on the consent you give when you create an account, by ticking the boxes that you are 18 or older and that you accept the Terms and this policy, for the purposes in the table above, which together let us provide the service you asked for. Data you give us yourself for a particular purpose, such as a support ticket or a contact form enquiry, is used for that purpose under section 7(a) of the Act. Product update email has its own consent, given only by ticking its own box. You can withdraw any consent as easily as you gave it: unsubscribe from product email in one click, or ask us at privacy@shellorbit.com. Withdrawing does not affect processing already done. The service cannot run without account data, so withdrawing consent for it means we close the account, and we will tell you before we do.

Records of your consent. So that we can show when and how you gave consent, as the Act requires, we record, for each acceptance, what you accepted (the Terms, this policy, and that you are 18 or older), the version, the date and time, your IP address, and your browser’s user agent, and whether you accepted at sign up or when we updated the documents. Each acceptance is a new record; earlier ones are never changed. We keep these records with your account and identity records: for the life of the account, then 30 days.

4. How long we keep it

Deletion means deletion from live systems on request, followed by expiry from backups on the schedule above. We do not keep a hidden archive of payloads past your retention window. Once the purpose a piece of data was collected for is served, and no law requires us to keep it, we erase it.

One thing survives deleting an account, and it is fairer to say so than to let you discover it. Request and access logs are kept for a year because Indian law requires it, and they record that a request reached a particular source or route at a particular time. They hold no event body and no message content. Section 8(7) of the Digital Personal Data Protection Act 2023 allows retention where another law compels it, and this is that case: we cannot delete these on request, and neither can anybody else operating a service in India.

We also keep a record that an account was deleted, being the date and a one way hash of the email address. It cannot be reversed into an email address, and it exists so we can show when a deletion happened without keeping the person’s details to prove it.

5. Who else processes it

We use a small number of subprocessors, each for one job. The current list, with purpose and data categories, is on the subprocessors page.

In summary: Amazon Web Services hosts the service in the United States, stores your events, runs Leak Alarm, and sends all our email through Amazon SES; WorkOS operates authentication; Zoho CRM holds enquiries sent through the contact form and your account record; Zoho Campaigns sends product update email to people who opted in, and Zoho Desk holds support tickets; Sentry receives error reports with payload content stripped; Cloudflare Turnstile checks the sign up, sign in, emailed sign in, and password reset pages and the contact form for automated use; Dodo Payments processes payment as merchant of record. Each is bound by a written agreement with confidentiality and security obligations, and none is permitted to use your data for its own purposes.

We do not use advertising networks, session recording tools, or customer data platforms. Services you connect yourself, such as a log platform, are your own providers and their own policies apply. The public sources we download security advisories from receive no data about you. An AI provider you add for explanations is also your own provider: it receives only what you ask to have explained, and its own terms apply.

6. International transfers

The service runs on Amazon Web Services infrastructure in the United States. Zoho CRM, Zoho Campaigns, and Zoho Desk run in Zoho’s India data centre. Our subprocessors may process data outside the country where you are based, including in the United States, India, and the European Economic Area. Under section 16 of India’s Digital Personal Data Protection Act 2023, personal data may be transferred outside India except to a country the Central Government restricts, and we will follow any such restriction. Where personal data leaves the EEA, the UK, or Switzerland, transfers rely on European Commission Standard Contractual Clauses, the UK International Data Transfer Addendum where applicable, and each provider’s own approved transfer mechanism. Copies of the relevant clauses are available at privacy@shellorbit.com.

7. Security

Measures in place include:

• TLS for every connection to the source intake, the dashboard, and the API. Plain HTTP is not offered.
• Encryption at rest for stored events, object storage, queues, and backups, using managed keys.
• Least privilege access to production data, with administrative access logged.
• Secrets and signing keys stored only in AWS Systems Manager Parameter Store, encrypted with a dedicated key, rather than in configuration, source control, or anything sent to a browser. Keys are masked before a log line or error report is written.
• Signature checks on every source event before any rule reads it, unless you switch the check off for that source.
• Automatic dependency and platform patching, with alerting on failed jobs and error rates.

These include the safeguards Rule 6 of the Digital Personal Data Protection Rules 2025 lists: encryption and masking, access control, logging and review of access to personal data, backups so processing can continue after an incident, logs kept for one year, and security terms in our contracts with every subprocessor.

You can reduce the amount of personal data we hold on your behalf by sending only the events your rules need, by masking fields in the inspector, by sending identifiers rather than email addresses from your own app, and by deleting sources you no longer need.

Report a suspected vulnerability to security@shellorbit.com.

If a breach affects you. If a personal data breach affects your account data, we tell you without delay by email: what happened and when, the likely consequences for you, what we have done and are doing about it, what you can do to protect yourself, and who to contact. We also inform the Data Protection Board of India as the Digital Personal Data Protection Rules 2025 require, and any other regulator the law requires. For customer data, the data processing addendum applies: we tell the customer within 48 hours so they can tell the people concerned.

8. Cookies and browser storage

We use only what is strictly necessary for the service to work, so there is no cookie banner and nothing to accept or reject. There are no advertising, analytics, or cross site tracking cookies anywhere on shellorbit.com.

The marketing site sets no cookies of its own. We count page views from our own server logs, not from anything in your browser. Error reports to Sentry use no cookies. Cloudflare Turnstile on the sign up, sign in, emailed sign in, and password reset pages and the contact form may set short lived security cookies or temporary storage inside its own frame, which Cloudflare describes as strictly necessary to tell people from scripts; its Turnstile privacy addendum applies. Dodo Payments sets cookies during checkout on its own domain, governed by Dodo Payments’ privacy notice.

9. Your rights

Depending on where you live, you may have the right to access your data, correct it, delete it, restrict or object to processing, receive it in a portable form, and withdraw consent where consent was the basis. In the European Economic Area, the United Kingdom, and Switzerland these come from the GDPR and equivalent law. In California, the CCPA as amended by the CPRA gives rights to know, delete, correct, and to opt out of sale or sharing. We do not sell personal information and do not share it for cross context behavioural advertising, so there is nothing to opt out of.

In India, the Digital Personal Data Protection Act 2023 gives you the right to:

• Get a summary of the personal data we hold about you and how we process it, and the identity of everyone we have shared it with, which is the subprocessors page and the services you connected yourself.
• Have it corrected, completed, updated, or erased.
• Withdraw consent as easily as you gave it, with the effect described in section 3.
• Have a grievance answered by our Grievance Officer.
• Nominate someone to exercise these rights for you if you die or cannot act. Tell us who by email from the account address.

You can ask for this policy in English or in any language listed in the Eighth Schedule to the Constitution of India, at privacy@shellorbit.com.

Grievance Officer. In line with the Information Technology Act, 2000 and the Digital Personal Data Protection Act, 2023, our Grievance Officer is Manish Sharma, reachable at privacy@shellorbit.com. We acknowledge a grievance within 48 hours and resolve it within 30 days of receiving it.

To exercise a right, email privacy@shellorbit.com from the address on the account, and give your username or account email so we can find the record. We respond within 30 days, and within 45 days for California requests, and will tell you if we need longer; under the Digital Personal Data Protection Rules 2025 that is never more than 90 days. Account holders can export event data and configuration through the API at any time without asking, and can correct their name, email, and username in Settings, Profile.

If the data you want is event data belonging to a customer of one of our own customers, the customer is the controller. Send the request to them and we will assist them under the data processing addendum.

You can lodge a complaint with your supervisory authority. In India, once you have used our grievance process, you can complain to the Data Protection Board of India. We would rather you told us first at privacy@shellorbit.com so we can fix the problem.

10. Automated decision making

There is no profiling and no automated decision making with legal or significant effects. Automated systems do enforce plan limits, rate limits, and abuse thresholds, and any such action is reversible and reviewable by a person on request.

11. Children

ShellOrbit is only for people 18 and older. Sign up asks you to confirm it, and we do not knowingly hold account data about anyone under 18. Under India’s Digital Personal Data Protection Act 2023 anyone under 18 is a child whose data needs verifiable parental consent, which we do not collect, so if we learn an account holder is under 18 we close the account and delete its account data. If a child’s data reaches us inside a payload or a tripwire hit, it is customer data under your control and the data processing addendum applies.

12. Changes to this policy

We publish the effective date at the top of this page. For a material change we give at least 30 days notice by email to account holders before it takes effect. Superseded versions are available on request.

13. Contact

• Privacy and data rights: privacy@shellorbit.com
• Security: security@shellorbit.com
• Legal notices: legal@shellorbit.com

Operator identity and registered contact details are available on request at legal@shellorbit.com.