# Gitfence

> Gitfence sits in front of GitHub and gives each person and AI agent exactly the part of a repository they're allowed to see and change, down to the folder or file, with plain git. Outside developers and the AI coding agents they run (Claude Code, Codex) can build features without seeing, cloning or copying the core code. The core team changes nothing; restricted people's pushes arrive as normal GitHub pull requests. Made by hoot.codes.

Try it: `git clone https://demo:demo@gitfence.dev/demo/shop.git` clones a public sample with core/ as types only and infra/ absent (read-only login). The demo with pushing is at https://gitfence.dev/demo.

Common questions:
- What is Gitfence? A git proxy in front of GitHub that gives each person and each AI coding agent a clone containing only the folders and files they are allowed, with four levels per path: No access, Types only, Can read, Can edit.
- Can GitHub restrict read access to one folder of a repository? No. GitHub repository roles apply to the whole repository; CODEOWNERS and rulesets control who can change or merge code, not who can read it. Gitfence adds per-folder read control in front of GitHub.
- How is Gitfence different from .cursorignore, Copilot content exclusion or Claude Code deny rules? Those run on the same machine as the agent, next to the full repository. Gitfence removes fenced files from the clone, so no command, tool or prompt on that machine can read them.
- Does Gitfence sandbox an agent or see its prompts? No. It limits what the agent's clone contains and records what was served. Use it together with the agent's own sandbox and permission settings.
- Who has to change how they work? Only restricted people and their agents, who clone through Gitfence. The core team keeps using GitHub directly.
- What can't it do? It can't take back code someone already cloned, it only covers access that goes through it, and it doesn't see prompts or anything done locally.
- Can it be self-hosted? Yes, on Enterprise: a compiled build in one container image, installed with docker compose, an offline signed license, no telemetry, customer-managed keys through HashiCorp Vault, and github.com or GitHub Enterprise Server 3.9+.
- Does it work on large monorepos? Yes. Tested on the full Kubernetes history (163,380 commits, 31,600 files): preparing a group's view takes 33 minutes once, a first clone about 7 minutes, then fetches take seconds and pushes about 3 seconds (2 vCPUs).

Key facts:
- Not an ignore file: fenced files are never sent to the machine, so no terminal command, tool or agent can read them. For comparison (vendor docs read on October 10, 2026): Cursor documents that the terminal and MCP server tools used by Agent cannot block access to code governed by .cursorignore; GitHub documents that Copilot content exclusion is not supported in Edit and Agent modes of Copilot Chat in VS Code and other editors (Copilot CLI respects it since September 2026).
- Access levels per folder or file, per group or person: No access (absent from every commit of their clone), Types only (the API without the implementation: TypeScript declarations, or Go and Python stubs that compile, with every value removed), Can read, Can edit.
- Works with plain git and any AI coding agent. Each clone gets an AGENTS.md / CLAUDE.md section describing the fence. An MCP server offers fence_status, check_paths, run_tests, request_access and pull request / issue tools.
- Fenced CI runs the real test suite on the full code in a sandbox with no network access and returns the verdict or redacted output. It runs today on self-hosted Gitfence; on the hosted service it is not self-serve and is set up per customer.
- Invitations can require NDA or document signatures before any code is reachable through git, MCP or CI.
- GitHub is the source of truth. Restricted people get a GitHub-like view built from their own copy: code browser, pull requests (conversation, checks, files changed with line comments) and shared issues. Reviews (including bots like CodeRabbit), checks and issues come back with hidden content redacted, and their replies and line comments post to the same GitHub thread.
- Pricing: Free (1 repo, you and your full-access team, unlimited AI agents for your team, no restricted people). Pro $29 per restricted person per month or $24 billed yearly, one-person minimum; full-access teammates free; unlimited AI agents for every person. One 14-day Pro trial, no card, starts with the first restricted person. Enterprise (contact us, no list price): SSO (SAML, OIDC) and SCIM, audit streaming, DPA, priority support, annual invoicing, Fenced CI, and a self-hosted option.
- Team workflow: temporary access (2 hours, 1 day, 1 week or until a date); access tied to a Linear or Jira ticket that ends when the ticket closes; Slack notifications with one-tap Approve/Deny; signed webhooks for Discord, Teams or a SIEM; exposure reports ("what could this person ever see"); audit export with retention. These integrations are tested offline against stand-in servers, not yet live with Slack, Linear or Jira.
- Every fenced pull request gets a Gitfence check that scans added lines for fingerprints of hidden code (an IP-leak check; a deterrent, not a proof).
- Exposure reports are an upper bound of what was served to a person or agent, not a log of prompts. Gitfence does not see prompts.
- Availability and billing: the core team works on GitHub directly, so a Gitfence outage does not affect them. A lapsed subscription never affects the core team; after a 14-day grace period restricted people are paused until it is renewed (5 days after an unpaid trial).
- Risk-based review: every pull request that comes through Gitfence gets a "Gitfence review" check and label. "Needs a human" when it touches sign-in and security, payments and billing, database migrations, CI/deploy/infrastructure, dependencies, permissions or secrets (admins can turn areas off and add their own); otherwise "Low risk". The summary lists what changed, risk areas, new dependencies with versions, the Fenced CI result and which agent made it. It is decided from changed paths and dependency files, not by a model, so risky logic in an ordinary-looking file is marked Low risk. The check passes when a person (not a bot, not the author) approves that exact version, and can be made required on GitHub.
- Agent seats: an agent can be limited below its owner (never above). Agent sign-ins end after 30 days by default, or when their pull request merges or closes, or their Linear/Jira ticket closes. A per-folder "No AI agents" flag applies to every agent. Every agent commit upstream ends with a Gitfence-Agent trailer only Gitfence can write.
- Secrets: secrets files (.env*, *.pem, *.key, SSH keys, *.tfvars, *.tfstate, cloud credential files and similar) are hidden from every restricted copy unless a rule names the exact file. Recognised credential values inside other files are replaced with a stand-in. Pushes from restricted people and from any AI agent that add a new secret are refused. Limits: values that only look like a hard-coded password are reported to admins but served as they are; binary files are not scanned.
- Leak tracing: each copy carries a marker in Gitfence-generated text only (the AGENTS.md / CLAUDE.md guide, generated declaration headers, secret stand-ins). Ordinary source carries none, and the marker can be deleted by someone who knows about it.
- Signed exposure receipts: per person or agent, plus a per-repository attestation listing files never served to any AI agent. Ed25519-signed JSON and PDF, share links that can be withdrawn, and a public verify page (https://gitfence.dev/verify). Built from the clones and fetches Gitfence recorded.
- One-paste setup: one prompt for Claude Code or Codex. Setup links work once and expire after 15 minutes. For admins, the agent plans access from a plain-language description and applies it only after the admin approves a preview; approving the GitHub App is the one step a person must do.
- Security: code encrypted at rest with a key Gitfence doesn't keep (held by the customer's credentials and recovery key; readable in server memory only while in use and up to ten minutes after; not zero-knowledge). Hosted in Germany by an EU company (HootCodes LTD, Sofia, Bulgaria); daily EU backups without source code; public status page at https://status.gitfence.dev.
- SSO and SCIM: SAML 2.0 and OpenID Connect with setup steps for Okta, Google Workspace and Microsoft Entra ID; Require SSO; SCIM provisioning with IdP group mapping and deprovisioning.
- Not built yet: a fenced GitHub mirror for cloud agents; self-serve Fenced CI on hosted; rules as code.
- Honest limits: cannot revoke what someone already saw; CI output redaction does not catch encoded output; messages of commits touching both hidden and visible files are kept; GitHub only (github.com, GitHub Enterprise Server when self-hosted); no SOC 2 or other certification yet (SOC 2 and an independent pentest are on the roadmap). Trust Center: /trust/.

## Product
- [Hire the developer. Keep the core.](https://gitfence.dev/): Bring in a contractor, agency or new hire without handing over your whole GitHub repo. They and their AI agent get only the folders the job needs.
- [Product tour: contractors in a Go monorepo](https://gitfence.dev/tour/): A guided tour of Gitfence: a contractor and their AI agent work on part of a Go monorepo, from day 1 to their last day, while the core stays out of their clone.
- [Pricing: pay only for restricted people](https://gitfence.dev/pricing/): Free for your own team and its AI agents. $29 per restricted person a month, with a 14-day free trial. Full-access teammates are always free.
- [Self-hosted Gitfence: your servers, your keys, no telemetry](https://gitfence.dev/self-hosted/): Run Gitfence on your own servers: a compiled build, installed with docker compose, offline license, no telemetry, your keys in Vault, GitHub Enterprise Server.
- [How Gitfence works: per-folder access for GitHub repos](https://gitfence.dev/how-it-works/): How Gitfence builds a filtered git history per person, validates every push, tests hidden code and opens normal GitHub PRs. Setup for admins and agents.
- [Security model, test results and known limits](https://gitfence.dev/security/): How Gitfence keeps hidden code and secrets out of clones, encrypts code with a key we don't keep, runs self-hosted with your keys, and where each one stops.
- [Signed exposure receipts: what did they see?](https://gitfence.dev/exposure-reports/): A signed receipt of what each contractor and AI agent was served from your repo. Anyone can verify it. An upper bound, not a prompt log.
- [Changelog: what's new in Gitfence](https://gitfence.dev/changelog/): Every Gitfence release: self-hosting, SSO and SCIM, encryption at rest, Go and Python types, large monorepos, Fenced CI, MCP for AI agents and the engine.

## Docs
- [Gitfence documentation for admins and security](https://gitfence.dev/docs/): Set up Gitfence, manage access and Types only, connect SSO and SCIM, review pull requests, self-host, size large monorepos and understand billing.
- [Getting started with Gitfence](https://gitfence.dev/docs/getting-started/): Set up Gitfence for your organization: create it, connect GitHub, add a repository, restrict folders and invite your first contractor.
- [Adding a contractor or a new hire](https://gitfence.dev/docs/add-a-contractor/): Invite a contractor or new hire, choose their access, require an NDA and set an end date. What they clone and how they start.
- [Access levels for people and AI agents](https://gitfence.dev/docs/access-levels/): The four Gitfence access levels, how rules combine, and what restricted people and AI agents can read, edit or never receive.
- [Types only for Go, Python and TypeScript](https://gitfence.dev/docs/types-only/): Give restricted people the API of a folder without its implementation: TypeScript declarations, Go and Python stubs that compile, values removed.
- [The access ladder: widen access with time](https://gitfence.dev/docs/access-ladder/): Give a new hire or contractor a ladder: their area first, more access after 30 and 90 days, and an end date, with each step approved by you.
- [Single sign-on with Okta, Google or Entra](https://gitfence.dev/docs/sso/): Set up SAML 2.0 or OpenID Connect for Okta, Google Workspace or Microsoft Entra ID, verify an email domain and turn on Require SSO.
- [SCIM provisioning from your identity provider](https://gitfence.dev/docs/scim/): Connect Okta or Microsoft Entra ID over SCIM, map IdP groups to access groups and see how deprovisioning and GitHub renames behave.
- [Encryption at rest and the recovery key](https://gitfence.dev/docs/encryption/): How Gitfence encrypts code at rest, what the recovery key opens, what locked means and what is not covered.
- [The signed release ledger](https://gitfence.dev/docs/release-ledger/): Gitfence's signed release ledger: what is public (signatures, digests, the hash chain) and the full release record Enterprise and self-hosted customers receive.
- [Offboarding and exit packs](https://gitfence.dev/docs/offboarding/): End a person's access, revoke tokens and agents, and download a signed exit pack with agreements, access history and exposure receipts.
- [AI agents and the Gitfence MCP server](https://gitfence.dev/docs/ai-agents-and-mcp/): Give Claude Code, Codex or Cursor an agent token and connect the MCP server. Scopes, tools, run_tests availability and the guide in every clone.
- [Code review for fenced pull requests](https://gitfence.dev/docs/code-review/): The Gitfence review check, risk areas, approvals and what restricted people see from reviews, checks and comments on GitHub.
- [Reviewing a pull request as a contractor](https://gitfence.dev/docs/reviewing-a-pull-request/): Review your team's pull requests in Gitfence: a diff from your own copy, line comments, reviews, and the REST API and MCP tools for AI agents.
- [What contractors see from CI](https://gitfence.dev/docs/ci-results/): Show contractors why CI failed without exposing hidden code: results, error locations, filtered logs, MCP and REST access, re-runs and audit records.
- [Working on pull requests as a contractor](https://gitfence.dev/docs/working-on-pull-requests/): Push your own branch, open a draft pull request, update it after review, and use Gitfence tools for commit ids, tags and large clones.
- [What syncs with GitHub](https://gitfence.dev/docs/github-sync/): What pull requests, issues, code, reviews, comments and reactions sync between GitHub and Gitfence, and what stays read-only.
- [Self-hosted Gitfence: install and operations guide](https://gitfence.dev/docs/self-hosting/): Install Gitfence on your servers with docker compose: sizing, your GitHub App, the offline license, encryption and Vault keys, Fenced CI, backups, upgrades.
- [Verify a Gitfence release](https://gitfence.dev/docs/verify-releases/): Verify a self-hosted Gitfence release with cosign: key fingerprint, signed image digest, provenance, SBOM, release files and the running executable.
- [Gitfence with GitHub Enterprise Server](https://gitfence.dev/docs/github-enterprise-server/): Run self-hosted Gitfence against GitHub Enterprise Server 3.9 or later: two settings and your own GitHub App on your server.
- [Performance on large monorepos, and sizing](https://gitfence.dev/docs/performance-and-sizing/): Measured on the full Kubernetes history (163,380 commits): one-time setup, clone, fetch and push times, memory, and the host and disk to plan for.
- [Billing: plans, seats and invoices](https://gitfence.dev/docs/billing/): Who counts as a restricted seat, how the 14-day Pro trial works, checkout, invoices, cancelling and what happens when a payment fails.

## Use cases
- [Who uses Gitfence: contractors, AI agents, new hires](https://gitfence.dev/for/): Partial access to GitHub repositories for contractors and agencies, AI coding agents, new hires, auditors and open-core teams. Pick your situation.
- [Give contractors part of a GitHub repo](https://gitfence.dev/for/contractors/): Give freelancers and agencies only the folders they need in a GitHub repo, behind an NDA, with plain git. Your core logic stays out of their clones.
- [Onboard developers without full codebase access](https://gitfence.dev/for/onboarding/): Give new developers their part of the codebase on day one, with types for the rest, and widen access with one click. No repo splitting, no re-clones.
- [Scoped repo access for audits and due diligence](https://gitfence.dev/for/open-core/): Give auditors, acquirers and partners a read-only, scoped view of a private GitHub repo behind an NDA, without copying code into a data room or a second repo.
- [Let Claude Code run free on your repo, safely](https://gitfence.dev/for/ai-agents/): Hand a task to Claude Code or Codex and walk away. Gitfence never sends the code you fence off, so no shell command, tool or prompt can reach it.

## Comparisons
- [Gitfence vs the alternatives: repos, submodules, CODEOWNERS](https://gitfence.dev/compare/): A fair comparison of ways to share part of a git repo: separate repos, submodules, CODEOWNERS, sparse checkout, Josh, Copybara, GitPermit and Gitfence.
- [Gitfence vs splitting a repo into separate repos](https://gitfence.dev/compare/split-repos/): Splitting a repo gives real per-repo permissions but breaks builds, history and atomic changes. A fair comparison with Gitfence's per-folder views.
- [Gitfence vs git submodules for restricting code](https://gitfence.dev/compare/git-submodules/): Git submodules can keep private code in a repo some people can't clone, but they pin versions and break builds for those people. How Gitfence compares, fairly.
- [Gitfence vs CODEOWNERS and branch protection](https://gitfence.dev/compare/codeowners-branch-protection/): CODEOWNERS, branch protection and push rulesets control who can change code, not who can read it. Use them with Gitfence; here's what each one covers.
- [Gitfence vs git sparse checkout for monorepos](https://gitfence.dev/compare/sparse-checkout/): Sparse checkout and partial clone make big monorepos fast, but they're client-side: the server still serves every file. How that differs from Gitfence's views.
- [Gitfence vs Josh and Copybara](https://gitfence.dev/compare/josh-copybara/): Josh and Copybara project or transform parts of a repository into other repositories. A fair look at how they compare with Gitfence's per-person views.
- [Gitfence vs GitPermit](https://gitfence.dev/compare/gitpermit/): GitPermit grants read access to subfolders or files of a GitHub repo. How it compares with Gitfence's read and write access, Types only and agent support.

## Articles
- [Can You Restrict Access to Folders in a GitHub Repo?](https://gitfence.dev/blog/restrict-access-to-folders-in-github-repository/): No, GitHub has no folder-level read permissions. Here's why, what GitHub does offer (CODEOWNERS, push rulesets), and the options that hide folders.
- [CODEOWNERS Is Not Access Control (What It Actually Does)](https://gitfence.dev/blog/codeowners-is-not-access-control/): GitHub CODEOWNERS requests reviews and can require approvals, but it doesn't stop anyone reading or cloning code. What it does, what it doesn't, and fixes.
- [Git Sparse Checkout vs Real Access Control](https://gitfence.dev/blog/git-sparse-checkout-vs-access-control/): Git sparse checkout hides files from your working tree, not your clone. What it does, how to bypass it in one command, and what restricts access.
- [How to Give Contractors Access to Part of a GitHub Repo](https://gitfence.dev/blog/give-contractors-access-to-part-of-github-repo/): GitHub grants access per repository, not per folder. Here are the real options for giving a contractor part of a repo, with commands and tradeoffs.
- [Least-Privilege Repo Access for Claude Code, Codex, Cursor](https://gitfence.dev/blog/least-privilege-repo-access-ai-coding-agents/): How to give Claude Code, Codex and Cursor least-privilege repository access with permission rules, sandboxes, scoped tokens and filtered clones.
- [Monorepo Permissions for Per-Team Access in One Repo](https://gitfence.dev/blog/monorepo-permissions-per-team-access/): Git and GitHub have no per-folder read permissions, so how do teams restrict access inside a monorepo? Options, tradeoffs and configs for per-team access.
- [NDAs for Developers Before Code Access (Practical Guide)](https://gitfence.dev/blog/nda-for-developers-before-code-access/): When and how to get an NDA signed before a developer or contractor sees your code, what to cover for AI tools, and how to gate access on it.
- [Onboarding New Developers Without Full Codebase Access](https://gitfence.dev/blog/onboard-new-developers-without-full-codebase-access/): How to onboard new hires with least-privilege codebase access so they ship in week one without a full clone. Options, tradeoffs and a day-one checklist.
- [Protecting Source Code from AI Agents and Contractors](https://gitfence.dev/blog/protect-source-code-from-ai-coding-agents/): How to protect source code when AI coding agents and contractors work in your repo, what ignore files and NDAs really do, and what limits access.