unYOLO<br>Skip to content<br>Search ⌘K
YOLO safely with your agents
unYOLO is a framework for building credential brokers and proxies for services like<br>GitHub, Hugging Face, or Google Workspace. Your agent talks to the broker and never<br>holds the real credential.
unYOLO lets you keep fine-grained policies in a local file. No permission screens to<br>click through and no separate account to create for the agent. When the agent needs<br>more permissions, you can give it timed grants that expire on their own.
Get started
View source
YOU
AGENT
agent-a@workstation<br>$ gh-broker operation submit pull_request.createop_9c2f succeeded pull request #482 opened$ gh-broker operation submit pull_request.mergeop_1d55 pending policy requires operator approvalop_1d55 approved by operator, single useop_1d55 succeeded pull request #482 merged<br>‹ u unYOLO bot<br>unYOLO<br>Approval required<br>agent-a wants to merge #482 in acme/api .
Merging is not in this agent's policy.<br>09:41<br>Approve · 1 use<br>Deny<br>✓ Approved by you
1x
Install unYOLO<br>Run the guided installer on macOS or Linux.<br>$ curl -fsSL https://unyolo.io/install.sh | sh Copy
Installation options
Credential boundary
Agent tools often receive the same account-wide token a person would use. A mistaken<br>command can then reach every repository and operation covered by that token.
A broker keeps the provider token in another process. The agent receives a client<br>credential whose authority comes from policy, so an unauthorized force-push fails<br>before GitHub sees it.
Without a broker<br>You hand the token to the agent. It does the work you wanted, and the same token reaches<br>everything else in your account.
You give your GitHub token to the agent. It pushes the branch you wanted, and the same<br>token also reaches the default branch, the acme/api repository itself, and a separate<br>private repository.<br>token
YOU AGENT
agent-a/parser-fix branch
main default branch
acme/api repository
acme/secrets private repo With unYOLO<br>The broker holds the token. The agent asks for the same work, and the calls you never<br>authorized are refused.
You give your GitHub token to the broker. The agent sends requests to the broker, which<br>checks them against your scope.json, allows the same branch push and returns its result,<br>and refuses the other three.<br>token request result
scope.json
YOU AGENT BROKER
agent-a/parser-fix branch
main default branch
acme/api repository
acme/secrets private repo
Request path
Every broker uses the same request path. Only classification and execution depend on<br>the provider.
1 Client authentication The caller presents a named broker-client secret before the broker accepts a request.
2 Request classification The provider adapter identifies the client and operation together with its target attrs.
3 Policy evaluation The shared engine matches that tuple against the rules file.
4 Active grants An approved grant acts as an allow rule with an expiry and a use budget.
5 Approval request A requestable operation waits in the operator inbox and can also appear in Telegram.
6 Provider execution The broker performs the operation with the provider credential and returns only the result.
7 Audit entry The broker records the decision and matching rule IDs without including secrets.
Decision order, fixed regardless of rule order in the file<br>deny › active grant › allow › request › no_match
Deny wins over everything, including an approved grant, and a request that matches no<br>rule at all is refused.
Read the policy engine documentation
Policy file
A broker loads one JSON rules file at startup as its authorization source. You can read<br>it directly and review changes in a pull request. unYOLO does not infer permissions from<br>traffic.
Attrs provide the useful narrowing. The rule beside this text allows pushes to<br>refs/heads/agent-a/**. It leaves refs/heads/main uncovered, so a<br>push to the default branch is denied. Unknown fields, duplicate rule IDs, unsupported<br>operations, and invalid globs prevent the service from starting.
Full policy schema
allow
request
deny
"rules": [<br>"id": "agent-a-read-and-branch",<br>"effect": "allow",<br>"clients": ["agent-a"],<br>"operations": [<br>"contents.read",<br>"git.fetch",<br>"git.push.fast_forward"<br>],<br>"targets": [<br>{ "kind": "repo", "owner": "acme", "name": "api" }<br>],<br>"attrs": {<br>"refs": ["refs/heads/agent-a/**"]<br>"rules": [<br>"id": "request-force-push-to-main",<br>"effect": "request",<br>"clients": ["agent-a"],<br>"operations": ["git.push.force"],<br>"targets": [<br>{ "kind": "repo", "owner": "acme", "name": "api" }<br>],<br>"attrs": {<br>"refs": ["refs/heads/main"]<br>},<br>"grant_policy": {<br>"mode": "window",<br>"default_minutes": 5,<br>"max_minutes": 10,<br>"default_max_uses": 1,<br>"max_uses": 1<br>"rules": [<br>"id": "never-delete-refs",<br>"effect": "deny",<br>"clients": ["*"],<br>"operations": ["git.ref.delete"],<br>"targets": [{ "kind": "repo" }],<br>"description": "Deletion is never delegated, even under an approved grant."
Operator approval
Marking an operation request creates a durable approval record and keeps the<br>original...