Count the Keys First: Show HN's Heldkeys Inventories What Your AI Agent Can Reach

Start with a question that should make you uneasy: if the coding agent running on your machine right now were talked into running one shell command by a prompt injection, how much could it do in your name? Not whether it might write bad code, but how much it could spend, delete, or push.

Heldkeys, posted to Show HN on October 16, is built around that question. It is a read-only, Rust command-line tool that answers not "are there secrets committed in your code" but "right now, running as you, which credentials can an agent actually reach?" The repository was created on October 15 and is MIT-licensed. According to the author, the idea came from his own habit of running coding agents on his laptop every day, until he asked what one of them could use if a prompt injection talked it into running a command — and found no tool that answered it. Secret scanners look for secrets committed to a repository; he wanted to know what a process running as him could use right now.

It scans the agent's view, not the repository

That distinction is the whole design. Traditional secret scanning cares about static artifacts: did a key get committed to git, did it get pushed in a config file? Heldkeys cares about runtime inheritance: what environment did the agent inherit, which login sessions can it read, which mounts can it step into? The former asks whether you lost a key; the latter asks how many keys you left on the table within the agent's reach.

According to the repository README, local scanning covers a wide surface: tokens and API keys in environment variables; AWS, gcloud, and Azure CLI logins and kubeconfig; logins for AI tools including Codex, Claude Code, Gemini CLI, Copilot, and Hugging Face; login state left on disk by developer-platform CLIs such as Vault, Terraform, Vercel, Netlify, Fly.io, Supabase, Wrangler, Stripe, Doppler, Railway, and Kaggle; .npmrc, .pypirc, Cargo credentials, and Docker registry logins; .netrc, git credential helpers, and GitHub CLI logins; project .env files — including ones excluded by .gitignore, because an agent can read those too; even old .env copies kept by VS Code's Local History extension; and tokens stuffed into MCP server configs as environment variables, arguments, URLs, or headers. The README also notes, honestly, that on macOS Claude Code's login lives in the keychain, which Heldkeys never reads. That is a real capability boundary, and it matters.

The output design deserves a note too. By default it gives a summary meant to be read in seconds: how many credentials are reachable, how many of them are long-lived with write access, a "fix these first" list, notes on secrets appearing in several places, and next steps. The README's demo scan shows 13 credentials reachable, 7 of them long-lived with write access. Those are fake fixtures from the author's demo, not any real user's scan — but they illustrate the picture the tool wants you to see: on an ordinary development machine, the agent's permission list may be much longer than you assume.

The more valuable half lives in CI

If Heldkeys only scanned local machines, it would be a thorough inventory tool and not much more. What makes it timely in October is heldkeys ci and its analysis of GitHub Actions workflows.

The README states the CI problem bluntly: a workflow that runs an agent on an issue_comment trigger with contents: write lets anyone who can comment steer an agent that can push; a workflow that checks out a pull request's head and then starts an agent lets the fork's author decide which MCP servers and instruction files that agent loads — a pattern the README links to CVE-2026-47751. That CVE reference is the README's claim; this article has not independently verified its details, so treat it as a lead from the author rather than an established fact.

According to the README, heldkeys ci does two things. First, a runtime inventory inside the CI job: secrets in the environment, GITHUB_TOKEN, OIDC variables, the Actions runtime token, tokens left by checkout in .git/config, tokens in remote URLs and other repository git config, GitLab's CI_JOB_TOKEN, and whether the runner is self-hosted — in short, what that job itself can see. Second, static analysis of .github/workflows/*.yml, finding agent steps (official actions such as Claude Code Action, Codex Action, and Gemini CLI, plus CLIs invoked in run steps such as claude, codex, gemini, copilot, aider, opencode, and cursor-agent) and applying deterministic rules: is the agent on a trigger outsiders can fire, does it run after a checkout of the PR head, does the job hold write-all permissions or no permissions block at all, was it handed secrets beyond its model key, is the action pinned to a tag instead of a commit SHA, and is it allowed to run arbitrary shell commands while holding a write token? The rules also follow local reusable-workflow calls, because a called workflow really runs with the caller's triggers, permissions, and secrets — checking one file alone would miss that layer.

There is a commendable restraint in this design: the tool states plainly that it only looks at what AI agents can reach, and points users to zizmor for everything else in workflows, such as template injection, cache poisoning, and unpinned third-party actions in general. A tool that knows what it is not builds more trust than one that claims to be everything.

"Never prints secrets" is a test, not a slogan

A tool that inventories credentials must first not become a new leak. Heldkeys treats this as an engineering constraint rather than a promise: it never prints a secret, shows only fingerprints (a few leading and trailing characters) for token formats whose prefix is public, and gives no fingerprint at all for passwords and tokens of unknown shape. The README says a test runs every fixture secret through every output format and fails if any 10-character slice of a fixture appears anywhere. It sends no telemetry, checks for no updates, and files no crash reports; apart from files you name with --output or --write-baseline, it writes nothing to your machine. When scanning sandboxes or CI jobs, its external contact is minimal — connecting to a Docker socket without sending data, making a single 300-millisecond TCP connect with no payload to a cloud metadata endpoint, with an environment variable to turn network probing off.

That matters because the adoption barrier for this kind of tool is never feature count; it is whether you dare run it on a machine full of keys. An inventory tool that dumps secrets into logs is worse than no tool. Making "read-only, no telemetry, never prints" verifiable is the most mature part of this design.

The author's own first run is a useful baseline: on his own machine, it surfaced years of accumulated cruft — an old plaintext git credentials file, a token exported in his shell profile, SSH keys without a passphrase — and cleaning up took about twenty minutes. That figure is self-reported and unverified, but the underlying judgment is right: a first inventory usually finds forgotten login state, not exotic attack surface.

What it cannot guarantee deserves equal airtime

Three limits, so the tool is not used in the wrong place. First, it is a reachability inventory, not evidence of intrusion: it tells you what an agent could theoretically reach, not that any agent ever did, and not that your machine is compromised. Read it as a health check, not an alarm log.

Second, its view equals the view of the process running it. macOS keychain logins are explicitly out of reach; credentials an agent obtains through other channels — a browser session, another user identity, a cloud-hosted agent sandbox — are outside one local scan. The README's advice on posture is worth following: run it in the same terminal your agent uses, because that is the environment the agent actually inherits. A clean report from a clean environment proves nothing but self-comfort.

Third, a clean report does not mean safety. Heldkeys can show you keys in the wrong place, but it cannot govern keys you deliberately hand to the wrong agent, nor can it stop a model from being steered into harmful actions. After the inventory is clean, the real work begins: least-privilege tokens for agents, write operations split into separate jobs that never read untrusted text, actions pinned to commit SHAs — the very directions its CI "next steps" point to.

One more present-day note: as of this article's verification date, the repository README's current version also includes a heldkeys incident black-october command for checking indicators from several publicly reported October 2026 incidents and suggesting rotation. October has indeed been a busy month for credential security: this site previously covered the OpenCode Console API key incident (official statement October 17), and the Heldkeys README mentions indicators for LiteLLM, OVHcloud CLI, and other events. Those incidents are outside this article's verification scope; treat the incident command as an auxiliary check against public indicators, not as an authoritative source on the incidents themselves.

Three practical moves for vibe developers

First, put it on the day-one checklist, not the post-incident list. After installing, run it once in the terminal your agent normally uses, then turn it into a gate with --fail-on long-lived-write: fail the check while any long-lived, writable credential remains reachable. Set the bar at the "long-lived plus writable" combination first; demanding zero findings on day one is how tools get switched off.

Second, in CI, scan the workflows before adding other hardening. Add heldkeys ci to repositories with agent workflows and look at three questions first: can outsiders fire the trigger, does the agent run on a PR head checkout, and does the job hold more secrets than it needs? The README's fixes are concrete: give the agent only its model key, split steps needing other secrets into separate jobs, prefer OIDC over long-lived cloud keys, make agent jobs read-only, and pin actions to commit SHAs.

Third, rescan on a schedule, not once. Credentials regrow: a new CLI adds a login, a new MCP server adds a token, a new project adds a .env file. Only a routine local scan plus a routine CI check keep the inventory meaningful; otherwise the twenty-year-old problems you cleaned up will return under new tool names within months.

A closing judgment. Two kinds of tools are appearing side by side in October's agent-security conversation: one kind watches the code agents produce — such as the quiz hook covered previously on this site, which makes a developer prove they understood a diff before pushing; the other watches the keys agents hold, and Heldkeys belongs to the second kind. The first governs comprehension; the second governs blast radius — how much damage a loss of control can do. With agents increasingly able to call external systems directly and prompt injection still lacking a silver bullet, counting the blast radius first is the cheapest defensive posture and the hardest to dress up in marketing language. It will not make your agent safe, but it will let you see, before you decide what permissions to grant, exactly what you have already granted.