Which Keys Is Your Agent Holding?

Developer Hugo Moreau released heldkeys, an open-source CLI that reports which credentials an AI coding agent can reach from a laptop, sandbox or CI job, scanning environment variables, AWS, gcloud, Azure and kubeconfig logins, git credential files, GitHub CLI, npm, PyPI, cargo and Docker registry tokens, passphrase-less SSH keys, Codex and Claude Code logins, project .env files and MCP config tokens for Claude, Cursor and VS Code. The tool is read-only, makes no network calls and finishes in under a second, ranking credentials by lifetime and write access, and adds a `heldkeys preflight` pass/fail gate for sandbox entrypoints plus a `heldkeys ci` mode and GitHub Action that flag agent steps on untrusted triggers holding secrets or write permissions. Moreau said running it on his own laptop surfaced an old plaintext git credentials file, a token exported in his shell profile and SSH keys without a passphrase.

I built heldkeys https://github.com/hugomn/heldkeys , an open-source CLI that shows which credentials an AI agent can reach from where it runs: your laptop, a sandbox or a CI job. A coding agent in your terminal runs as you, so it can use your cloud logins, your git and package tokens, the .env files in every repo you cloned and the API keys sitting in your MCP configs. That is fine until a prompt injection in an issue, a web page or a README talks it into running a command. Secret scanners tell you what was committed to a repo. heldkeys tells you what a process running as you could use right now. Get started brew install hugomn/tap/heldkeys heldkeys Run it in the same terminal your agent uses. It is read-only, makes no network calls and finishes in well under a second. Here is what it prints on a test machine built from the fake credentials in the repo: The report fits on one screen. It starts with the credentials to fix first, ranked by how long each one keeps working and whether it can change things, because a long-lived token with write access is a much bigger risk than a short read-only session. Below that you get where the rest live, secrets that show up in several places, and concrete next steps. heldkeys --details lists everything, and --format json , markdown or sarif feed other tools. It looks where credentials actually live: environment variables, AWS, gcloud, Azure and kubeconfig logins, git credential files and helpers, the GitHub CLI, npm, PyPI, cargo and Docker registry tokens, SSH keys without a passphrase, AI tool logins like Codex and Claude Code, project .env files including old copies in editor history , and tokens in the MCP configs of Claude, Cursor, VS Code and others. As a gate in a sandbox If your agents run in a container, the same binary checks what the sandbox exposes from the inside, like a mounted Docker socket, a Kubernetes service account token or a reachable cloud metadata endpoint. heldkeys preflight turns that into a pass or fail check, so you can put it in front of the agent in the entrypoint: COPY --chmod=0755 heldkeys /usr/local/bin/heldkeys ENTRYPOINT "/bin/sh", "-c", "heldkeys preflight --fail-on long-lived-write && exec \"$@\"", "heldkeys-gate" CMD "your-agent", "--its-flags" When the sandbox holds a credential it shouldn’t, the container refuses to start and tells you why: The Linux binaries are static, so this works in any image, distroless included. You can also check a container that is already running with heldkeys scan --docker <container or --kube <pod . In CI I think the newest risk is in GitHub Actions. Teams are adding agents to workflows that react to issue comments and pull requests, and some of them hand the agent a write token or repository secrets while it reads text anyone on the internet can write. heldkeys ci reads your workflow files and flags that combination: agent steps on untrusted triggers with secrets or write permissions, agents working inside a checkout of an outside pull request, unpinned agent actions and unrestricted shell access. Run inside a job, it also lists what that job can reach. The easiest way to run it is the GitHub Action: jobs: heldkeys: runs-on: ubuntu-latest permissions: contents: read steps: - uses: actions/checkout@v7 with: persist-credentials: false - uses: hugomn/heldkeys@v0 On a workflow that runs Claude Code on issue comments, with a write token, cloud keys and a checkout of the pull request, it looks like this: For workflow security in general, zizmor https://github.com/zizmorcore/zizmor already does a great job, so heldkeys only has rules for agent steps. What it found on my machine I ran it on my own laptop first, and it found the things that pile up over the years: an old plaintext git credentials file, a token exported in my shell profile and SSH keys without a passphrase. I would not have listed any of them if you had asked me, and every agent I started could use them. Cleaning up took about twenty minutes. Git now uses the system keychain, the package token loads only inside the projects that need it, and the keys have passphrases. Why you can trust it with your secrets A tool that reads every credential on your machine has to earn that. Values only ever show up as short fingerprints like ghp …021 , and a test runs every fixture through every output format and fails if any part of a fake secret leaks. There is no telemetry and no update check, it never calls the providers behind your credentials, and it writes nothing to your machine. The threat model https://github.com/hugomn/heldkeys/blob/main/docs/threat-model.md covers what it defends against and what it can’t see, like browser sessions, secrets that only live inside the OS keychain, and git history, where gitleaks and TruffleHog are the right tools. If you run it, I’d love to hear what it found and which credential locations it should learn next. Issues and pull requests are welcome on GitHub https://github.com/hugomn/heldkeys .