Dev Tools & Infra
We're Handing Agents the Whole Keyring, the Missing Credential Broker
Published: 2026-07-03
The Problem
For a coding agent to push code or call an API today, someone hands it full human credentials, and one prompt injection or leaked debug log is all it takes for those keys to walk.
Why Now
Coding agents have become everyday tools on dev teams, yet the least-privilege, short-lived-token, audit-log standards we enforce for humans simply don't exist for agents.
Recommended Talent
Someone who knows infra engineers with secrets-management and IAM scars, developers who understand how agents invoke tools, and B2B sellers fluent in security-audit requirements.
The Problem
A Show HN tool called Ghbrk hit a nerve: a broker that lets AI agents run git and gh without ever touching SSH keys or API tokens. The tool matters less than the gap it exposes. Most teams running coding agents today hand the agent a shell where the SSH keys in the home directory, the tokens in environment variables, and a full-scope PAT are all in plain view. One prompt injection from a malicious webpage, one token echoed into a debug log, and the keys walk. For human employees, least privilege, short-lived tokens, and audit trails are table stakes, SOC 2 auditors ask about them on day one. For the newest “employee” on the team, we hand over the master keyring at onboarding and keep no record of which call leaked what.
Why Now
Coding agents have crossed from demo to daily driver, they commit, open PRs, and deploy. Each agent now demands a human’s worth of credentials, but security teams are still tooled for human accounts. Secrets managers store keys; they don’t watch what the process holding a key actually executes. That a single indie tool like Ghbrk draws front-page attention is itself the signal: this is the moment right before an individual workaround hardens into a standard infrastructure layer, the same window early container-orchestration tools climbed through. In the US market there’s a forcing function too, every vendor selling agents into the enterprise needs an answer for the security questionnaire, and today the honest answer is “the agent can read all our keys.” Whoever ships the default now owns the category before the practice ossifies.
How to Build It
Expose a broker socket to the agent instead of keys. The agent requests “push to this repo”; the broker evaluates policy, repo scope, branch, command allowlist, rate limits, pulls a short-lived credential from the vault only for requests that pass, executes on the agent’s behalf, and returns just the result. Not one byte of key material enters the agent’s context. Sensitive operations like force pushes or production-secret access escalate to a Slack approval, and every call lands in an audit log.
flowchart LR
A[AI agent] -->|command request| B[Credential broker]
B -->|policy check| P[Policy engine and audit log]
B -->|short-lived key| V[Credential vault]
B -->|executes on behalf| G[git, gh, APIs]
Enter narrow: a drop-in wrapper for one popular coding agent, installable in a single line. Then framework integrations, then enterprise IAM and existing vaults (HashiCorp Vault, cloud KMS). Charge per seat, with audit and compliance features as the upgrade tier, the SOC 2 answer is what the enterprise plan actually sells.
Success Criteria
First, zero friction: if install takes more than one line or the agent gets visibly slower, developers hand the keys back. Second, sane default policies, safe but not suffocating; a tool that blocks real work gets disabled by Friday. Third, becoming the default: the winner is whoever gets embedded into agent frameworks and CI ecosystems deeply enough that “agent credentials go through the broker” reads as convention, not product.
Related Content
Build this together
Find collaborators