How to let an AI agent use GitHub without giving it the keys

When a coding agent force-pushes a branch at 3 a.m., the problem usually isn't the model. It's the token.

The agent is running with the same account-wide credential a person would use, so one bad command can reach every repository and every operation covered by that login. UnYOLO, an open-source kit released this week, treats that as a structural problem rather than a prompting one. Its answer: a small local broker process holds the real GitHub, Hugging Face, or Google Workspace credential. The agent only holds a client credential whose authority comes from a human-readable JSON policy file. When the agent tries to do something the policy forbids, the request fails before the provider ever sees it.

That broker-and-policy split is the pattern. UnYOLO is one concrete open-source instance of it, and the mechanics in this kit give a clean view of what the pattern actually requires. The first requirement is a holder: the broker is the only process that ever holds the real provider token. The second is a version-controlled policy file. The third is a fixed decision order. The fourth is an audit log that records which rules fired without leaking secrets. Any team that builds its own agent auth layer will end up making a choice on each of those four.

The policy file is a single JSON document loaded at startup, and the project's own documentation is explicit that unYOLO does not infer permissions from traffic. Whatever is in the file is the authority. That makes the policy diff-able in a pull request, reviewable like code, and the kind of artifact a security team can audit without running the agent. It also means the source of truth is the same thing the human team wrote, not a learned behavior or a per-request negotiation.

The decision order is fixed regardless of how the rules are written in the file. Deny wins over everything, including an approved grant. Active grants, which are short-lived approvals the broker tracks with an expiry and a use budget, sit above the static allow rules. After grants, the policy's allow rules apply, then per-request handlers, and anything that doesn't match is refused. The "deny beats grant" rule is the part that actually changes the threat model. Even if an operator approves a one-shot merge, a deny rule in the policy still blocks the action.

Active grants are where the broker shows its hand on the operational side. They can be timed to expire on their own, the broker can route an approval request to an operator inbox and also to Telegram, and the example flow covers a pending merge and a single-use operator approval. The point isn't that the operator is in the loop on every action. It's that the policy decides when the operator has to be in the loop, and the audit log records which rules fired.

The audit log is the third leg. Every request produces an entry with the decision and the matching rule IDs, explicitly without secrets. A security reviewer can reconstruct what happened, which rule allowed it, and whether the policy held, without ever holding a token. The audit log is also why the JSON file is the right shape: it is the same artifact a reviewer reads and the same artifact the broker consults.

The limits of the evidence are worth naming. The mechanics, the seven-step request pipeline, and the decision order are all described on the project's own landing page; they are the vendor's claims, not an independent audit. The Hacker News thread surfaced this week had six points at hydration, so third-party signal is thin. There are no named production users in the source material, no security review, and no comparison against scoped tokens or vendor OAuth constraints under load. Any claim that the broker pattern beats scoped tokens in practice needs outside sourcing before it goes to print.

The meta-stake is what makes the pattern worth a reader's attention. As agents get more autonomous, the question of who holds the keys stops being a deployment detail and becomes the question that decides whether agentic software is safe to ship at all. Handing an agent a personal account-wide token is a current footgun, not a hypothetical one. A broker, a version-controlled policy file, and a deny-wins decision order is one responsible answer to that question. Whether teams adopt this kit, build their own, or wait for vendor OAuth layers to absorb the pattern, the structural problem is the same one, and unYOLO is the cleanest open example of how to think about it.

The team says a one-line installer is available for macOS and Linux.