GitDB vs GitHub Enterprise — what each is for

I keep getting some version of this question: "If GitHub Enterprise added agent audit logs in February, isn't that the same thing you're building?"

The shortest answer is that they're built for different actors.

GitHub has been built for human developers for over 15 years. Pull requests, issues, the review surface, the marketplace, the social graph — every interaction was designed around the way a person reads, writes, and collaborates on code. The Enterprise AI Controls work shipped this year adds agent-aware governance on top of that foundation. For their installed base, that's the correct move.

GitDB was built for AI agents from day one. The interface isn't a UI for humans; it's a query API for software that doesn't have hands. The audit log isn't recording "a session happened"; it's recording every line the agent read. The cost model isn't optimized for one developer cloning a repo and grepping locally; it's optimized for four agents working in parallel without re-reading what the others already have.

Both are correct designs for their actor. The rest of this post walks through where each one fits.

What GitHub Enterprise actually shipped in 2026

GitHub has been moving on the AI-controls front, and to their credit, the work is real. The relevant 2026 milestones:

February 2026 — Enterprise AI Controls and the Agent Control Plane went GA. Administrators now have a suite of governance features with deeper control and greater auditability around AI agent use. Audit logs include an actor_is_agent identifier and user fields, and a new agent_session.task event tracks when agent sessions start, finish, or fail.
June 2026 — Copilot moves to usage-based AI Credits billing. Each Copilot code review will be billed via AI Credits, with 1 AI credit = $0.01. The shift exists because agent costs have ballooned to the point where it's straining infrastructure — GitHub itself flagged this.

So GitHub Enterprise has agent identity, session auditing, and metered billing. That's a serious investment, and for most teams the answer to "can I let agents touch our codebase under enterprise governance" is now "yes, on GitHub Enterprise."

I want to be careful not to undersell that. The Enterprise AI Controls work is genuinely useful.

Where the two pieces sit differently

The substrate underneath is the part that doesn't change with the audit log. GitHub Enterprise — agent or human — still works through git clone. That has a specific architectural property worth naming: the audit log records that the clone happened, but it doesn't record which files inside the cloned repo the agent actually read.

When an agent calls git clone, the entire repository lands on the agent's disk. From that point forward, every file the agent reads is local — cat src/auth/middleware.rs is invisible to GitHub. The audit log knows the clone occurred. It doesn't know whether the agent then read 5 files or 500.

For human developers, this distinction usually doesn't matter. A developer who clones is presumed to be reading the codebase as their job. For agents, where access patterns become signals (the 500-files-in-60-seconds anomaly we wrote about is a concrete example), losing per-file visibility after the clone matters more.

The other shared property: the file is still the unit, not the function. GitHub's API returns files. When an agent asks for process_payment, it gets the file containing it (which it must read) and any callers (which require additional reads). The industry baseline of 60–80% of agent tokens going to finding things rather than answering questions is what falls out of this architecture, and it's why GitHub's own infrastructure is straining under agent workloads to the point of needing metered billing.

Where we fit differently

GitDB is built for the layer between the agents and the code. It's not trying to replace GitHub — your repositories can still live on GitHub Enterprise, and a lot of teams keep that setup. What GitDB changes is how the agents reach the code.

Three specific differences:

1. The interface is function-level, not file-level. An agent calls find_function("authenticate") or find_callers("process_payment") and gets back exactly what it asked for — line ranges, AST nodes, structured answers. The retrieval cost drops from full-file reads (~9,000 tokens) to targeted reads (~470 tokens), which we wrote up in detail in the cost post.

2. There is no git clone for agents. The code stays on the server. The agent's tools — read, write, find, commit — are all individual operations, each one logged with the agent's identity, the exact lines touched, and the timestamp. The audit log captures what was read, not just that a session occurred. The Air Canada and Levandowski class of incidents — where the question "do they still have the code?" doesn't have a verifiable answer — has a verifiable answer here.

3. Bulk-access patterns become live signals. When no human or agent ever needs a full-repo dump, any identity attempting one is anomalous. We've described the 500-files-in-60-seconds detection pattern elsewhere. This isn't a GitHub gap because GitHub needs clone to work — it's a different design choice for the agent-specific layer.

The other thing worth being specific about: we're not trying to be GitHub's UI. PR review, issue tracking, the social graph, the marketplace, code search for humans — GitHub is excellent at all of those, and we don't replicate them. GitDB sits as a programmatic layer that agents talk to, and engineers reach via VS Code extension or web reviewer for the day-to-day reads.

Where GitHub Enterprise is honestly the better fit

I want to be direct about this part:

You already use GitHub Enterprise heavily. Most enterprises do, and the cost of changing source-of-truth is real. The Enterprise AI Controls are good enough that "keep using GitHub, add agent controls" is a reasonable path.
Your developer workflow depends on GitHub's social and review surface. PR threads, code owners, branch protection rules, the GitHub UI — these are deep and well-built. We don't have a comparable surface.
Your team isn't running multi-agent workloads yet. If a single Copilot session is your AI usage, the file-level audit and Enterprise AI Controls are sufficient. The wedge we describe shows up when you have multiple agents working in parallel on the same codebase.
You need GitHub Marketplace integrations. Apps, actions, the integration ecosystem — that's GitHub's moat and one we don't have.

Where GitDB fits

Teams running multi-agent coding workflows (architect / coder / reviewer / tester swarms) where the 60–80% token waste on file-level retrieval is a budget problem worth solving.
Regulated environments where "every file the agent read" needs to be answerable in a single query, not reconstructed from clone events.
Codebases where the IP risk of departing engineers or compromised agent tokens is high enough that bulk-access detection is worth the architectural switch.

Honest caveats

GitHub is enormous, we're not. 100M+ developers, thousands of integrations, fifteen years of operational history. We're in private beta with a small customer base.
Some teams use both. GitDB sits between agents and a repository whose canonical home stays on GitHub Enterprise — the proxy mode we describe in the deployment post. That setup is genuinely the right answer for a lot of teams who aren't ready to move source-of-truth.
Our developer-facing surface is narrow. The VS Code extension and web reviewer cover the daily-read use case. They don't yet have GitHub's review depth, issue graph, or marketplace.

If you're running multi-agent coding in production and the budget or the audit math isn't working out on GitHub Enterprise alone, please reach out. I'd genuinely like to compare notes on the specific shape of your workload — and if GitHub Enterprise is the better fit for you, I'll tell you that.

— Danny