Files
keyhunter/LEGAL.md
salvacybersec 260e342f2f feat(05-02): add LEGAL.md, embed it, and wire keyhunter legal command
- Add LEGAL.md at repo root (109 lines) covering CFAA, Computer Misuse Act,
  EU Directive 2013/40/EU, responsible use, disclosure, and disclaimer.
- Mirror to pkg/legal/LEGAL.md for go:embed (Go cannot traverse parents).
- Add pkg/legal package exposing Text() for the embedded markdown.
- Add cmd/legal.go registering keyhunter legal subcommand to print it.
2026-04-05 15:46:11 +03:00

110 lines
5.0 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# KeyHunter — Legal Disclaimer for Active Key Verification
This document describes the legal considerations for using KeyHunter's active
verification feature (`keyhunter scan --verify` and related flags). Read it
carefully before enabling verification.
## Purpose
KeyHunter's verification feature makes outbound HTTP calls to third-party
provider APIs (OpenAI, Anthropic, Google, Cohere, and 100+ other LLM/AI
services) in order to determine whether an API key discovered during a scan is
currently live. Verification is **opt-in**: it runs only when you explicitly
pass `--verify`. Passive scanning (the default) never contacts a third party.
## What --verify Does
- Sends a single lightweight HTTP request per discovered key to that provider's
documented verify endpoint (for example, `GET /v1/models` for OpenAI-style
APIs).
- Uses only the HTTP methods and bodies documented in the provider's public
API reference.
- Does **not** modify, create, delete, or otherwise mutate any account or data
on the provider's side.
- Reads only the metadata the provider voluntarily returns in the response
(organization name, rate limit tier, available models).
- Masks keys in all logs and output by default; the raw key is never written
to disk unless you explicitly pass `--unmask`.
## Legal Considerations
Verifying an API key that you do not own or do not have explicit permission to
test may constitute unauthorized access under computer-crime statutes in many
jurisdictions, including but not limited to:
- **United States** — Computer Fraud and Abuse Act, 18 U.S.C. § 1030 (CFAA).
Unauthorized access to a "protected computer" (broadly interpreted to
include any internet-connected server) can result in civil and criminal
liability.
- **United Kingdom** — Computer Misuse Act 1990, sections 13. Unauthorized
access, unauthorized access with intent, and unauthorized acts with intent
to impair are all criminal offences.
- **European Union** — Directive 2013/40/EU on attacks against information
systems, transposed into national law by each member state.
- **Provider Terms of Service** — In addition to statutory law, every provider
imposes contractual terms that typically forbid using credentials you are
not authorized to use. Violations can result in account termination and
civil claims for damages.
Making an API call with a stolen or leaked key, **even a single request that
does nothing**, may legally qualify as "access without authorization" in these
frameworks.
## Responsible Use
You should only use `--verify` in the following scenarios:
- **Your own keys** — keys that belong to accounts you personally own and
operate.
- **Authorized engagements** — penetration tests, red-team exercises, or bug
bounty programs where the scope document **explicitly authorizes** active
verification of credentials belonging to the target.
- **Your own CI/CD pipelines** — scanning your own source code, your
organization's source code (with employer authorization), or container
images you are responsible for.
Do **not** run `--verify` against keys you found in random public
repositories, pastes, or leak dumps belonging to third parties without first
obtaining the owner's consent.
## Responsible Disclosure
If you discover a leaked API key that belongs to someone else:
1. Do **not** verify it, use it, or publish it.
2. Contact the key owner directly. Look for a `security.txt` file at
`https://<domain>/.well-known/security.txt`, a security contact on their
website, or an entry in a vulnerability disclosure platform.
3. Provide enough detail for them to rotate the key (where you found it, what
provider it targets, the masked prefix) without exposing the raw secret in
your disclosure channel.
4. Give the owner reasonable time to respond and rotate before any public
disclosure.
## Disclaimer
KeyHunter is provided "as is", without warranty of any kind, express or
implied, including but not limited to the warranties of merchantability,
fitness for a particular purpose, and non-infringement. The authors and
contributors of KeyHunter disclaim all liability for any damages, direct or
indirect, arising from the use or misuse of this tool. **You, the user, are
solely responsible** for ensuring that your use of KeyHunter complies with all
applicable laws, regulations, contracts, and terms of service in your
jurisdiction and the jurisdiction of any service you interact with.
## Consent Record
The first time you run `keyhunter scan --verify`, KeyHunter displays an
interactive consent prompt summarizing this disclaimer. You must type `yes`
(case-insensitive) to proceed. Your decision is persisted in the local SQLite
settings table under the key `verify.consent`. Granted consent is sticky
across runs; declined consent is not, so you will be re-prompted next time
(in case you change your mind or run in a different environment).
To review this document at any time, run:
keyhunter legal
To reset consent and force a re-prompt, clear the `verify.consent` setting
from your KeyHunter database.