Leaks & Secrets

API keys, authentication tokens, database credentials, infrastructure secrets and service keys left in a public Git repo, an open cloud bucket, a .env file or an accessible config, or spat out by an overly talkative endpoint. In short: anything that looks like an exploitable credential sitting on an asset tied to your domain. Detection is automated and follows what an attacker looks for first; it does not replace the human verification of a pentest, which is a separate offering.

We start from your root domain and pull up your surface (subdomains, IPs, services, cloud storage) without you having to provide access. Public repos and code leaks tied to your perimeter are then combed for secrets sitting in the code, the commit history and files versioned by mistake. The scope stays under your control: we unroll from the domains you declare, no reckless attribution to repos that aren't yours.

Yes. Public S3 buckets, Azure Blob Storage, open GCP Storage, exposed storage instances. Dedicated modules check storage ACLs and flag endpoints vulnerable to SSRF, which can be used to reach cloud metadata. If a bucket is reachable from the Internet and tied to your domain, it surfaces in the inventory along with what it lets leak: public files, secrets, configs.

No. The secret's value is masked before it is written to the database, by default. The platform keeps the fact that a key leaked, its type and its location, not the exploitable secret itself. You have enough to act (revoke, rotate the key, close the bucket) and enough to hand to an auditor, without a dump of our database replaying the leak. Detecting a secret without re-trapping it by copying it is the baseline behaviour, not an option.

Those tools scan a repo you point them at, often your own, internally. They only see what you give them. Here, we answer the question before that: what leaked on your external surface, where you aren't looking? We start from a single domain, discover the public repos, buckets and exposed files nobody inventoried, and continuously monitor what appears. The two are complementary: the internal scanner goes deep on the known repo, EASM finds the exposed leak you didn't know about.

On a High or Critical finding from a verified domain, you can ask an autonomous AI agent to try to confirm the secret is actually exploitable, within strict guardrails (20 steps, 300 seconds, 150,000 tokens per finding) and an ephemeral sandbox with filtered network egress. If it proves it, the finding moves to confirmed with a stored proof, secrets masked. It is AI, not a human pentester, and it is quota-limited: 2 validations a month on Discovery, 30 on Pro, 100 on Business, unlimited on Enterprise. We don't promise zero false positives; thorough human verification is our pentests, a separate offering.

You schedule periodic scans (cron) and trigger on-demand ones from the interface or the API. On every pass, you get the delta: new secret that appeared, bucket flipped to public, config file newly accessible, finding resolved. Volumes depend on the plan: 10 scans a month on Discovery, 100 on Pro, unlimited on Business and Enterprise. You track your usage in real time.

Article 21 of NIS2 mandates risk management that includes asset mapping and continuous monitoring of the exposed surface, secrets and shadow IT included. Leak detection contributes directly: a live inventory of the secrets and assets that leak, an alert on the first change, PDF and CSV reports exportable for your auditors. To be clear: it doesn't cover all of NIS2 on its own (governance, incident response, supply chain remain on you). It addresses the knowing and controlling what you expose part.