Where GitHub falls short for company knowledge

Git already solved the agent loop

If you want an agent to change files safely, git is the best machinery ever built for it. Every change is a diff. Work happens on branches. History is reviewable, attributable, and revertible. A file-writing agent thrives in a git tree - that’s the loop coding agents are designed around.

So the obvious move is to put your company knowledge in a repo and point your agents at it. It works beautifully, right up to the moment a second kind of person needs access.

Access in git is all-or-nothing per repo

Git has no concept of “you can read this folder but not that one.” Permissions live at the repository boundary. If you can clone the repo, you have everything in it - including the full history of everything that was ever committed.

That leaves you two bad options for a company brain:

• One big repo: simple, but everyone with access sees compensation, the board deck, and every client’s confidential work.
• Many repos, one per sensitivity level: secure, but now your knowledge is shattered across a dozen repos, and the agent’s “tree” is whatever subset someone remembered to clone. Structure drifts. Context fragments. The thing that made git great - one coherent tree - is gone.

Sub-path permissions inside a single repo don’t exist, and read-filtering history is not something git can do. This isn’t a missing feature; it’s the data model.

”Hidden” is not the same as “absent”

Even setups that try to hide paths usually hide them client-side. The bytes still reached the machine. For a company brain holding genuinely sensitive material, that’s not a guarantee you can stand behind. What you need is for a forbidden folder to be absent from the clone and its history - never written to disk in the first place.

Keep the loop, fix the boundary

The answer isn’t to abandon git. It’s to keep git’s loop - real diffs, branches, push-based write-back - and move the access boundary from the repo to the folder, enforced by a server that authorizes every fetch and push.

That’s the missing middle between git and Drive, and it’s exactly what Monora is built to be.