Governed git · Clone, pull and push with no GitHub credential on the machine

Setup

Three commands. Then git works as it always did.

Nothing about the developer's workflow changes except the remote URL. Clone, branch, commit, pull, push, rebase: all unchanged. The remote points at the broker instead of github.com, and a tiny credential helper answers git's password prompt with a short-lived token that proves which agent is calling.

terminal

# 1. register this machine as an agent (once)
npx @agentvalet/register

# 2. tell git to authenticate to the broker with the agent key
npx @agentvalet/register git-setup

# 3. use the broker as the remote
git clone https://api.agentvalet.ai/git/acme/ledger-service.git

Connect GitHub once in the dashboard. The credential is sealed in the vault. It is never written to the developer machine, its git config, or any log.

Grant the agent github:contents.read (clone, fetch, pull) and, if it may push, github:contents.write.

On that grant, open Restrict to repositories and list what this identity may reach: acme/ledger-service, or acme/* for everything under one owner. Anything not on the list is unreachable, for reads as well as writes.

Nothing to rotate when someone leaves. Revoke the agent and that machine cannot reach GitHub at all, mid-command if necessary. The GitHub credential itself never left the broker, so there is nothing on the laptop to chase.

Every push, in order

Same six gates as every other governed call.

A git operation is not a special case. It runs through the exact pipeline a Slack message or a Stripe refund runs through, with the real path recorded, so the rules you already wrote apply to source code too.

1. Who is calling

Git asks for credentials; the helper hands over a five-minute token signed by the agent's key. The broker verifies it against the public key it registered. No password, no PAT, nothing reusable.

2. Is the agent alive

Suspended or revoked agents stop here. So does a child identity whose parent has been revoked.

3. Is the scope granted

Fetch needs contents.read; push needs contents.write. Deny-by-default: no grant, no call.

4. Is the repository allowed

The owner and repo in the URL are matched against the grant's allow-list. A push to a personal repo does not fail because something detected exfiltration; it fails because the repo is not on the list and there is no other route to GitHub from that machine. Forks, transfers and gists are refused on a restricted grant for the same reason.

5. Do your policies agree

Org guardrails, the owner's policy, tags, external-reach controls: all evaluated. Any one saying no ends it, with the rule that decided recorded on the refusal.

6. Then, and only then, GitHub

The broker fetches the real credential from the vault, forwards the pack traffic, streams the reply back and drops the credential. One audit row: who, which repo, which branches, allowed or denied, and why.

What the log shows

Not "someone pushed". Which identity, which repo, which branches.

For a push, the broker reads git's command header (never the file contents) and records the refs that changed and how. An auditor can answer "who pushed to main on the ledger service last Tuesday" from the same log that holds every other agent action.

audit row · metadata.git

{
  "service": "receive-pack",
  "upstream_status": 200,
  "request_bytes": 48213,
  "refs": [ { "ref": "refs/heads/main", "op": "update" } ]
}

If the organisation connects GitHub as a GitHub App rather than a personal login, the token the broker uses upstream is minted for that one repository and that one permission level, for that one call. Even the upstream credential cannot wander.

The locked-down machine

"Governed" becomes "the only path" when there is no other one.

AgentValet governs what goes through it. The customers who want this most (regulated shops, agencies handling client code, anyone with an Intune-managed developer VM) pair it with a perimeter that leaves the broker as the single hole. The checklist is short.

No GitHub credential on the machine. No gh auth login, no PAT, no SSH key, no Git Credential Manager account.

Egress allow-list. Permit api.agentvalet.ai; deny github.com, api.github.com, *.githubusercontent.com. If git can reach GitHub directly the broker is decorative.

One agent per machine or developer, with a GitHub grant carrying the repository allow-list, and no other platform with an upload or send scope on that same agent. The grant set is the egress surface.

GitHub's own controls stay on. Enterprise Managed Users or SAML-enforced SSO, forking off, PAT creation restricted, an organisation IP allow-list that contains the broker's address.

What this does not do, and we will not claim it does. It does not stop a person who can read code from copying it another way; that is the device-management perimeter's job. It does not stop an AI assistant on the machine from sending source to its model provider; that needs its own decision. And an operation that requires a human approval cannot pause a running git push, so those are refused with a clear message rather than queued. The honest claim is: the only sanctioned path is the only path, and every use of it has a name on it.

Where it fits

The same broker, now in front of your source code.

Coding agents on a shared box

Claude Code, Cursor, Codex and the rest push through the same remote. A worker agent gets a smaller allow-list than the orchestrator that spawned it, and cannot widen it.

Contractors and agencies

Hand a contractor an agent scoped to one repository for the length of the engagement. When it ends, revoke the agent. No shared bot account, no key to collect back.

Regulated developer VMs

The DLP story finally has a clean answer for source control: no credential on the VM, one reachable set of repositories, an audit line per push with the branches named.

Your other tools, unchanged

The REST side of GitHub (issues, pull requests, file reads) has been governed all along. Git itself joining the same grant means one place to look and one plug to pull.

Reference, error table and limits: Governed git in the docs. Repository allow-lists are a Studio-and-up control; the passthrough itself is on every plan.