Legba AdversarySignal over noise

Find the API keysleaking from your surface.

Secrets leak across frontend bundles, public repos, exposed .env files, and open storage. Adversary finds them and validates which are real and reachable. You get evidence and severity in minutes, not a scanner dump.

Book a live run See what you get back

Validated, not pattern-matched
Evidence per finding
Human review intact

Where secrets
leak.

A key does not have to be stolen to be exposed. It just has to be reachable. These are the places Adversary looks first.

01Detail →

Frontend bundles

Keys hard-coded into JavaScript ship to every visitor. View source, read the token. Adversary parses your live bundles and pulls the strings that look like credentials.

02Detail →

Exposed .env files

A misconfigured server serves .env, .env.local, or a config dump straight to the public. One request returns database URLs, signing keys, and provider tokens.

Public repositories

Secrets committed to a public repo, or a fork, stay readable in history long after the file is deleted. Adversary checks the code paths attached to your domains.

04Detail →

Exposed .git directories

A deployed .git folder lets anyone reconstruct your source, then mine it for keys. Adversary flags the directory and confirms it is reachable.

05Detail →

Misconfigured storage

Public buckets and open object storage hold backups, dumps, and config files. Adversary finds the open bucket and confirms which objects are readable.

06Detail →

Dangling subdomains

An abandoned subdomain pointing at a deprovisioned host can be claimed by an attacker, then used to phish tokens or serve trusted-origin requests.

Full library → Browse every exposure type in the Adversary exposure library.

Discover, then
validate.

Any scanner can flag a string that looks like a key. Confirming it is live and reachable is the part that matters. Adversary does both.

Map the surface

Adversary enumerates your domains, subdomains, hosts, repositories, and storage. It builds the full external footprint, including the assets you forgot you owned.

Find candidate secrets

It reads live bundles, exposed files, and reachable paths, then extracts strings that match known key formats. This is the candidate set, not the verdict.

Validate what is real

Adversary probes each candidate to confirm it is live, reachable, and tied to your surface. A revoked key is noise. A working key is a finding.

Capture evidence

Every validated leak is returned with its source, the request that proved it, severity, and a remediation step. You see why it matters and what to fix.

What you
get back.

A scanner gives you a list. Adversary gives you a decision. Each line is a leak you can confirm and fix.

Validated findings only. Each leak is confirmed live and reachable, not just pattern-matched.
Evidence per finding: the source location and the request that proved exposure.
Severity and reachability, so you triage the working key before the dead one.
Remediation guidance written for the engineer who has to rotate the key.
A client-ready report, assembled in minutes, not a raw scanner dump.
Human review intact. A senior reviewer interprets and signs off before it ships.

Background → Read why exposed secrets and API keys matter more in the AI era, or see the full Adversary attack surface product.

Questions about
leaked secrets.

What does the exposed API keys scanner actually check?

Adversary maps your external surface, then reads the places secrets leak: frontend JavaScript bundles, exposed .env and config files, public repositories, exposed .git directories, and misconfigured storage. It extracts strings that match known key formats, then validates which ones are live and reachable. You get the confirmed leaks, not a wall of pattern matches.

How is this different from a regular secret scanner?

Most scanners pattern-match and dump every hit, including revoked keys and false positives. Adversary validates. It probes each candidate to confirm it is real, live, and tied to your surface, then returns it with evidence and severity. The result is signal over noise: working keys you can act on, not a backlog of maybes.

Does Adversary validate the keys it finds?

Yes. Validation is the point. A revoked or rotated key is treated as noise. A reachable, working key is treated as a finding and returned with the request that proved it, its severity, and a remediation step. You spend your time on the exposures that are actually exploitable.

How fast is a run?

Discovery, validation, and report assembly complete in minutes for a typical external surface. You get a client-ready report with evidence and severity, not a multi-week engagement. Larger or deeper surfaces take longer, but the first pass is fast by design.

Is there a human in the loop?

Yes. Adversary automates the first-pass discovery, validation, and report assembly. A senior reviewer still interprets the findings, confirms severity, and signs off before the report ships. The automation clears the busywork. It does not replace expert judgment.

Can I run it against a domain I do not own?

No. Adversary is built for assessing your own external surface or a client surface you are authorized to test. Authorization is a prerequisite. Book a live run and we confirm scope before anything is probed.

Go deeper

More of what Adversary finds and validates.

Exposed API keys are one finding type. Adversary maps the whole external surface and confirms which exposures are real. Start with the specific leak paths below.

Exposure01