Keyreach: Deterministic, Read-Only API Key Capability Mapping For Bug Bounty And Incident Response + Video

Introduction

When an API key leaks, the immediate industry reflex is to rotate it, panic briefly, and move on — without ever understanding the actual blast radius. Security teams routinely ask “what can this key actually do?” but answering that question requires chaining together provider-specific tools, ad-hoc `curl` recipes, and manual report writing. keyreach, an open-source tool released by Vaibhav Vanage, collapses this workflow into a single deterministic command: paste any exposed key and receive a full capability map, computed severity score, and a disclosure-ready report. Built on a foundation of zero AI/LLM runtime dependencies, read-only-by-default probing, and deterministic rule-based execution, keyreach represents a principled departure from the trend of injecting machine learning into security tooling. It is designed for bug bounty hunters, pentesters, red teams, and blue teams performing exposure triage — anyone who needs to answer the blast-radius question with evidence they can defend in a report.

Learning Objectives & Secrets

Objective 1: Master API Key Capability Enumeration — Learn how to use keyreach to identify the provider of any leaked key across 32 supported providers in 9 categories (cloud, AI, payment, communications, email, dev platforms, databases, monitoring, and generic). The tool detects, validates, enumerates, scores, and reports in a single pipeline.
Objective 2 Secret Tip: Leverage the `–aggressive` Flag for Deeper AWS Reconnaissance — By default, keyreach performs quiet enumeration to avoid triggering alerting systems. However, for AWS keys, the `–aggressive` flag enables a wider cross-service sweep. Use this during authorized penetration tests to uncover IAM permissions across S3, EC2, Lambda, and other services, but be aware that a sweep “looks like reconnaissance to whoever is watching the account”.
Objective 3 Secret Tip: Use Batch Mode to Keep Keys Out of Shell History — When processing multiple keys, pipe them via stdin using cat keys.txt | keyreach -f -. This keeps sensitive credentials out of your shell history and prevents them from being captured in log files. The same principle applies when using `–json` output with jq: `keyreach KEY –json | jq` ensures stdout contains only the report while stderr captures banners and warnings.

You Should Know

1. Installation and Core Pipeline

keyreach requires Python 3.11+ and has minimal dependencies: httpx, pydantic, typer, rich, Jinja2, and `PyYAML` — with zero AI/LLM SDKs in any dependency group. A CI check (ai_ban) fails any build that introduces an AI/LLM dependency or model endpoint.

Installation options:

 Recommended: isolated installation via pipx
pipx install keyreach

Or install into an existing Python environment
pip install keyreach

From source (for development or latest features)
git clone https://github.com/Phantom-IN/keyreach.git
cd keyreach
pipx install -e .

The five-stage pipeline:

Detect — Deterministic pattern and entropy rules identify the provider
Validate — The cheapest read-only liveness and identity call
Enumerate — Read-only probes map which services, scopes, and resources the key reaches
Score — A pure, rule-based function turns confirmed capabilities into a severity band plus rationale
Report — Terminal, JSON, Markdown, or self-contained HTML output with masked key, evidence, impact, and remediation

Basic usage:

 Single key analysis
keyreach AIza...  Google API key example

Generate Markdown report
keyreach KEY --report md -o out.md

Generate self-contained HTML report (opens from disk, no network required)
keyreach KEY --report html -o out.html

JSON output for machine processing
keyreach KEY --json

Batch processing from a file
keyreach -f keys.txt

Batch from stdin (keeps keys out of shell history)
cat keys.txt | keyreach -f -

2. Understanding Severity Scoring and Evidence

keyreach’s severity model is what sets it apart from providers that assign static risk labels. Severity is computed from confirmed capabilities, not from provider name. The tool never guesses — if a rule can’t decide a capability, it reports unknown.

For example, a Stripe `sk_live_` key rates as Critical while a `sk_test_` key does not, because Stripe documents that sandbox payments are not processed. A GitHub token holding the `repo` scope is reported as write access to private source code — read from the `X-OAuth-Scopes` header GitHub documents, not from a write operation keyreach performed. The same token’s organization capability stays as read, because `repo` grants nothing there.

What the evidence looks like (abridged Markdown report for a GitHub token):

 Exposed github API key reaches GitHub Repositories and 4 other services
Severity: CRITICAL — Anyone holding this key can change data or move money.

<table>
<thead>
<tr>
  <th>Field</th>
  <th>Value</th>
</tr>
</thead>
<tbody>
<tr>
  <td>Provider</td>
  <td> `github` (devtools)</td>
</tr>
<tr>
  <td>Key</td>
  <td> `ghp_AAA` </td>
</tr>
<tr>
  <td>Status</td>
  <td>valid</td>
</tr>
<tr>
  <td>Account</td>
  <td>northwind-ops</td>
</tr>
<tr>
  <td>scopes</td>
  <td>read:org, repo, user</td>
</tr>
</tbody>
</table>

Why this severity
- Write or admin access to a service holding private data: GitHub Repositories (write)
- Reaches 5 distinct services, so the exposure is the project rather than a single API

Evidence
 GitHub Repositories — write
GET https://api.github.com/user/repos?per_page=1&visibility=private -> 200, private repositories: 1 listed

Reproduce (read-only):
curl -s -H 'Authorization: Bearer <key>' \
'https://api.github.com/user/repos?per_page=1&visibility=private'

Key insight: The evidence counts, never quotes — it proves the key listed a private repository without putting the repository’s name in a bug bounty report. And the `write` was never performed — it comes from documented scope headers, not from a destructive action.

3. Provider Coverage and Credential Formats

keyreach supports 32 providers across 9 categories. Here are the credential formats and what each live key can reach:

| Provider | Credential Format | Capabilities Enumerated |

|-|-||

Two-part credentials (AWS, Twilio, Razorpay, PayPal, Zoom) are passed colon-joined:

keyreach 'AKIA...:'  AWS (secret can be empty for detection only)
keyreach 'AC<32 hex>:'  Twilio
keyreach 'rzp_live_...:'  Razorpay
keyreach 'CLIENT_ID:CLIENT_SECRET' --provider paypal
keyreach 'ACCOUNT_ID:CLIENT_ID:CLIENT_SECRET' --provider zoom

Providers that require `–provider` flag (cannot be auto-detected due to opaque credential formats): PayPal, Discord, Zoom, Mailgun, Postmark, Bitbucket, npm, MongoDB, Redis, Datadog, Sentry.

4. Exit Codes and CI/CD Integration

keyreach provides fixed, documented exit codes safe for CI gating:

| Code | Meaning |

|||

| `0` | Ran cleanly; nothing reached the `–fail-on` threshold |
| `2` | A finding at or above `–fail-on` threshold |
| `1` | Something went wrong — bad flag, unreadable file, unknown provider |

CI gating example:

 Fail the build if severity >= high
keyreach KEY --fail-on high

In a CI pipeline
if keyreach "$LEAKED_KEY" --fail-on high --quiet; then
echo "No high-severity findings"
else
echo "CRITICAL: Key with high-severity capabilities detected!"
exit 1
fi

A malformed command line exits 1, so a typo in a CI config can never be mistaken for a Critical key.

Advanced Usage: Forcing Providers, Controlling Enumeration, and Self-Contained Reports

Force provider (skip detection):

keyreach KEY --provider google
keyreach KEY --provider aws

Skip enumeration (validity + identity only):

keyreach KEY --1o-enumerate

Pace probes to avoid rate limits:

keyreach KEY --delay 500ms

Show full key in output (off by default):

keyreach KEY --unmask

Self-contained HTML reports — Every style rule is inlined; no external stylesheet, font, script, or image is required. The report opens correctly from disk with no network available and carries the same ten sections as the Markdown report in the same order. It refuses --file/stdin because a single HTML document cannot honestly represent several findings at once; use `–report md` or `–json` for batch processing.

The “No AI” Constraint: Why It Matters for Security

keyreach contains zero AI or LLM calls and zero AI/LLM SDK dependencies, anywhere. This is a hard architectural constraint for three reasons:

Security — keyreach handles live secrets. Sending a key to an external model would itself be a credential leak.
Reproducibility — The same key against the same provider state must always produce the same capability map, severity, and report. A finding you can’t reproduce is a finding you can’t report.
Auditability — Every verdict traces to a concrete rule and a concrete API response, so both you and the team receiving your report can verify exactly why the tool said what it said.

The tool doesn’t think — it just runs rules. As the author notes, “I had the AI do the thinking about the rules instead.” The result is a tool that is boring, deterministic, and auditable — exactly what security incident response demands.

7. Legal and Ethical Use

keyreach is built for authorized use only — keys you own or are explicitly authorized to test (bounty scope or engagement). Validating a key generates authentication traffic and log entries on the target service. Testing credentials without authorization may be illegal in your jurisdiction, regardless of how the key was exposed. keyreach is read-only by design and ships no exploitation features, but the responsibility for authorization rests entirely with the user.

What Undercode Say

Key Takeaway 1: Determinism beats “AI-powered” hype in security tooling. In an industry racing to inject LLMs into everything, keyreach deliberately excludes AI at runtime. Every verdict is traceable to a concrete rule and API response — no black boxes, no hallucinations, no secrets exfiltrated to third-party models. This is the right architectural choice for tools that handle live credentials. The `ai_ban` CI check that fails any build introducing an AI dependency is a model worth emulating across the security tooling ecosystem.
Key Takeaway 2: The blast-radius question is finally answerable in one command. Before keyreach, answering “what can this key do?” meant chaining provider-specific tools, maintaining curl snippets, and handwriting reports. keyreach collapses this into a deterministic pipeline: detect → validate → enumerate → score → report. The severity is derived from confirmed capabilities with visible rationale — the rationale itself becomes the bounty argument. For bug bounty hunters, this transforms a leaked key from a vague finding into a quantified, reportable vulnerability with reproduction steps and evidence.

Analysis: keyreach addresses a critical gap in the API security workflow. Most teams treat leaked keys as binary: valid or invalid. But the real question is the blast radius — what data, what services, what permissions? keyreach provides the answer with auditability that stands up to triager scrutiny. The tool’s principled constraints (no AI, read-only, deterministic) are not limitations but features that make it suitable for high-stakes environments. The phased roadmap — Phase 0 (R0.1–R0.9), Phase 1 (R1.1–R1.6), Phase 2 (R2.1–R2.10) completed, Phase 3 (ecosystem integration) next — demonstrates disciplined, build-in-public development. The drift canary that re-verifies detection rules against vendor documentation addresses the reality that credential formats change — a problem that breaks most static pattern-matching tools over time. For blue teams, keyreach offers a way to quantify exposure during incident response. For red teams, it provides reconnaissance data without triggering destructive alerts. For bug bounty hunters, it turns a key into a ready-to-submit report.

Prediction

+1 keyreach will accelerate the professionalization of API key disclosure reporting. Bug bounty programs will increasingly expect hunters to provide capability maps and severity rationales rather than raw keys. The tool’s disclosure-ready reports set a new baseline for submission quality.
+1 The “no AI” architectural pattern will gain traction in security tools that handle sensitive data. As organizations recognize the compliance and security risks of sending credentials to LLM APIs, deterministic rule-based tools will see renewed interest.
-1 Adversaries will adapt by monitoring for keyreach-like enumeration traffic. The `–aggressive` flag’s AWS sweep, in particular, resembles reconnaissance activity and may trigger detection in mature cloud environments. Teams should use it judiciously and within authorized scopes.
+1 The provider plugin architecture (with declarative `.yml` files for simple providers) lowers the barrier to contribution. As the community adds support for more providers, keyreach’s coverage will expand — and the drift canary will keep detection rules current as vendor documentation evolves.
-1 Organizations that rely solely on keyreach for API key risk assessment may develop a false sense of security. The tool deliberately under-reports where vendors don’t document access models — it never confirms that an AI key can run inference or spend, and it never sends an SMS to confirm toll fraud potential. keyreach is a scoping tool, not a comprehensive security audit platform.

▶️ Related Video (82% Match):

https://www.youtube.com/watch?v=3KMUnLdlOSE

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: https://lnkd.in/p/eiGPYvd7 – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Listen to this Post