xGit: Git Without Keys. With Proof.

Replace SSH keys and tokens with identity-based access. Make every commit provable.

Git today depends on secrets. SSH keys, personal access tokens, CI tokens—all must be stored, rotated, and can be leaked. Even GitHub requires manual key management and rotation. In 2024, GitHub exposed SSH keys and had to rotate credentials across all customers.

xGit removes this entire category. Instead of "who has the key?", you get "who has the identity + permission?"

What xGit Provides

• Identity-native access: No SSH keys or tokens. Every action tied to a verifiable decentralized identifier (DID).
• Protocol-level policies: Rules enforced at the Git protocol level, not UI. "AI cannot merge without approval" becomes cryptographically enforceable.
• Provable history: Every commit, merge, and CI run has an unforgeable cryptographic proof. Rewriting history leaves evidence.
• Protected code distribution (advanced): For classified, regulated, or high-value codebases, session-gated access with XorIDA threshold sharing.

This white paper covers all four capabilities, with deep focus on protected code distribution—where contributors never clone the full repository and access expires cryptographically. For classified defense projects, proprietary trading algorithms, and regulated healthcare platforms, this solves problems GitHub can't.

Traditional Git vs xGit

Quick Example

Using xGit feels like Git—but with identity instead of keys:

# Traditional Git (requires SSH key or token)
git clone git@github.com:org/repo.git
git commit -m "feat: add feature"
git push origin main

# xGit (identity-based, no keys)
xgit clone did:web:org.example/repo
xgit commit --actor did:key:z6Mk... -m "feat: add feature"
xgit push origin main  # Verified by DID, not key

Or via the SDK:

import { xGitClient } from '@private.me/xgit'

const client = new xGitClient({
  identity: myDID,  // Your DID, not SSH key
  repo: 'did:web:org.example/repo'
})

await client.commit({
  message: 'feat: add feature',
  files: changedFiles,
  // Automatically signed with DID
  // Policy checks enforced at protocol level
  // Proof generated for audit trail
})

1. The Problem with Git (Credential Sprawl)

Git Depends on Secrets

Every Git operation—push, pull, clone—requires authentication. Today, this means:

• SSH keys stored in ~/.ssh/ on every developer machine
• Personal access tokens (PATs) stored in credential managers
• CI tokens stored in environment variables or secrets managers

These credentials must be:

• Generated manually
• Stored securely (often they're not)
• Rotated periodically (GitHub recommends quarterly, many orgs require 30-90 days)
• Revoked when employees leave
• Monitored for leaks (GitHub scans public repos for exposed tokens)

Result: Credential sprawl. Every developer has multiple keys across multiple machines. CI/CD systems have dozens of tokens. When something leaks—and it does—the blast radius is enormous. In 2024, GitHub had to rotate keys enterprise-wide after exposing SSH credentials.

Git's Architecture Assumes Free Copying

Beyond credentials, Git's architecture assumes code should be freely copyable. git clone gives you the entire repository history. Forks create independent copies. Once code is cloned, the original owner has zero control over what happens next.

This design works for open source. It fails catastrophically for:

• Classified defense projects — CMMC Level 3 requires cryptographic access control. Git provides none.
• Financial trading algorithms — Proprietary strategies worth billions. A single git clone by a departing engineer becomes corporate espionage.
• Healthcare platforms — HIPAA audit trails require knowing who accessed what code, when. Git logs can be rewritten.
• Legal discovery platforms — Attorney-client privilege extends to source code. Uncontrolled Git forks violate privilege.
• SaaS competitive advantages — Your differentiation is in the code. Contractors shouldn't walk away with it.

Existing solutions don't solve this:

• GitHub Enterprise private repos — Contributors still clone full source. Access control is coarse-grained.
• GitLab self-hosted — Same problem. Cloning gives permanent local copy.
• Perforce — Centralized, no offline work, painful workflows, expensive licenses.
• Code obfuscation — Slows development, breakable, doesn't prevent copying.
• DRM wrappers — Easily circumvented, breaks tooling, hated by developers.

The industry needs a solution that combines Git's developer experience with cryptographic access control. That's xGit.

2. How xGit Works (Identity + Proof Architecture)

Core: Identity-Based Access (No Keys)

xGit replaces SSH keys and tokens with decentralized identifiers (DIDs):

• Every developer has a DID — cryptographic identity like did:key:z6Mk...
• Every commit is signed by a DID — not by a key that can be copied
• Every access is authorized by DID + policy — not by "whoever has the token"

Result: Zero credential sprawl. No keys to rotate. No tokens to leak. Identity is unforgeable and tied to the person or AI agent, not a file on disk.

Protocol-Level Policy Enforcement

Traditional Git enforces rules at the UI level (GitHub branch protection, GitLab merge rules). These can be bypassed by anyone with local access or force-push privileges.

xGit enforces rules at the protocol level using cryptographic proofs:

• "AI cannot merge without human approval" — enforced by requiring 2-of-2 signatures (AI DID + human DID)
• "Only maintainers can push to main" — enforced by DID-based role verification before accepting push
• "All commits must pass CI" — enforced by requiring xProve verification proof attached to commit

These rules cannot be bypassed because they're enforced by the Git protocol itself, not a web UI that can be circumvented.

Provable Commits and History

Every action in xGit produces a cryptographic proof:

• Commits: Signed by DID with Ed25519, unforgeable
• Merges: Require K-of-N approvals, each approval is a proof
• CI runs: xProve generates zero-knowledge proofs that tests passed
• Access: Every file read is logged with DID + timestamp, tamper-evident

Result: Git history becomes provable, not just trusted. Auditors can verify "who did what when" cryptographically. Rewriting history leaves evidence.

Advanced: Protected Code Distribution (Session-Gated Access)

For classified, regulated, or high-value codebases, xGit adds session-gated code access: contributors authenticate with DIDs, receive time-limited sessions, and access code through XorIDA threshold reconstruction—not cloning.

Three-Share Distribution (2-of-3)

Every source file is split into three XorIDA shares:

• Share 1: Published to public registry (GitHub, npm, etc.). Visible to everyone. Useless alone.
• Share 2: Delivered to authenticated contributors via session-gated ACIs. Purged when session expires.
• Share 3: Held in encrypted vault by repository owner. Never distributed.

Reconstruction requires any 2 shares. Share 1 + Share 2 = working code. Share 1 alone = mathematically worthless noise. Share 2 without an active session = inaccessible.

DID-Based Authentication

Contributors authenticate using decentralized identifiers (did:key:z6Mk...), not username/password. Sessions are cryptographically bound to DIDs. Every file access, commit, and CI run is watermarked with the contributor's DID.

If code leaks, the DID watermark identifies the source. No deniability.

Zero-Knowledge CI/CD Verification

xGit's CI/CD runner executes tests inside session-gated environments. Two proof types:

• Tier 1 (Audit): HMAC-chained audit trail of every step execution. Verifiable without revealing test code.
• Tier 4 (Zero-Knowledge): Hash commitment proves tests passed without exposing test logic or output.

Repository owners verify CI results cryptographically. Contributors can't inspect or modify test code—they prove correctness without access.

Workflow Integration

xGit supports GitHub Actions-compatible YAML workflows. Developers work in familiar environments (VSCode, IntelliJ). PRs, issues, code review—all standard Git workflows. The difference: code never leaves the session-gated environment.

3. Real-World Use Cases

4. Core Features (Phase 1)

Phase 1 delivers the foundational xGit infrastructure (4 components complete, 8 in roadmap):

Phase 1 In Progress

• 1.5 Issue Tracking ACIs (NEXT) — DID-authenticated issue creation, assignment, commenting. Session-gated access to private issues.
• 1.6 Branch Protection — Policy enforcement: required reviews, CI status checks, signature verification.
• 1.7 Web UI Foundation — Browse reconstructed files, view workflow runs, inspect proofs. No cloning.
• 1.8 Pull Request Review — Diff viewing, inline comments, approval workflow. Reviewers see reconstructed code via sessions.
• 1.9 Issue Tracking UI — Web interface for issues, labels, milestones, assignments.
• 1.10 Commit Graph UI — Visualize DID-watermarked commit history, branch topology, merge points.
• 1.11 File Browser UI — Navigate repository structure, view files, inspect shares. Session-gated.
• 1.12 PR Review UI — Side-by-side diffs, threaded comments, approval buttons.

4.1. Production Readiness & Developer Experience

Session 68 (April 2026) delivered comprehensive UX improvements and production-ready infrastructure across 25 identified issues. All fixes deployed with 938/966 tests passing (97% pass rate).

Security & Authentication

API/ACI Interface

Operational Infrastructure

Documentation

ACI-Level UX Standardization

All 25 xgit UX improvements are being applied across all 95 PRIVATE.ME packages (aci-ux-standardization-plan.md). 5-phase rollout over 16 weeks with 4-engineer team:

• Phase 1: UX foundations and shared utilities package (@private.me/ux-helpers)
• Phase 2: Critical ACIs (Xlink, Xprove, Xwallet, Xfuse, Xstore, Xredact, Xpass, Auditlog)
• Phase 3: All 21 enterprise CLI servers (rate limiting, error messages, pagination, health checks, OpenAPI docs)
• Phase 4: Remaining 65 packages (documentation, test coverage 95%, configuration standardization)
• Phase 5: Cross-ACI integration testing and error propagation patterns

Goal: Consistently excellent developer experience across the entire PRIVATE.ME ACI ecosystem.

5. Development Roadmap

6. Performance Benchmarks

Tested on: Intel i7-12700K, 32GB RAM, NVMe SSD. Node.js v22.x. Ubuntu 22.04 LTS.

7. Security Model

Threat Model

xGit defends against:

• Unauthorized cloning — Traditional Git: anyone with read access can git clone. xGit: Share 1 alone is useless noise.
• Session hijacking — Sessions are DID-bound via Ed25519 signatures. Attacker needs private key (stored in hardware wallet or OS keychain).
• Replay attacks — Nonce store prevents session token reuse. One-time JWTs with jti claim.
• Share tampering — HMAC-SHA256 on every share. Reconstruction fails if HMAC invalid. XorIDA properties prevent forgery.
• Exfiltration via CI — CI runners validate session before execution. Zero-knowledge proofs hide test logic. Watermarking identifies leaks.
• Malicious contributors — DID watermarking on commits, file access, CI runs. Audit logs are tamper-evident (HMAC-chained). Leaked code traces back to DID.
• Time-of-check-to-time-of-use (TOCTOU) — Session validation happens atomically with file reconstruction. Share 2 delivery and access logging are transactional.

Cryptographic Primitives

• XorIDA threshold sharing — Information-theoretic security over GF(2). Share 1 alone reveals zero bits of plaintext.
• HMAC-SHA256 — Per-share integrity. Prevents tampering, forgery, bit flips.
• Ed25519 signatures — DID authentication, commit signing, audit log chaining. 128-bit security level.
• SHA-256 commitments — Zero-knowledge CI proofs. Binding, hiding properties prevent cheating.
• JWT (HS256) — Session tokens. Server-side HMAC key (256-bit). No client-side secret.

Trust Assumptions

• Repository owner is honest — Owner controls Share 3. Malicious owner can reconstruct files. xGit doesn't protect against insider threats from the owner.
• Session manager is trusted — Session issuance and revocation handled by server. Compromise of session manager = unauthorized access. Mitigation: HSM-backed session keys, 2FA for admins.
• Contributors protect DID keys — DID private keys stored in hardware wallets or OS keychains. Stolen key = impersonation. Mitigation: watermarking limits damage (leaks trace back to DID).
• Share 1 registry is available — If GitHub/npm goes down, reconstruction fails. Mitigation: mirror Share 1 to multiple registries.

Audit Trail Integrity

Every action generates a tamper-evident audit entry:

{
  "timestamp": 1735891234567,
  "action": "FILE_RECONSTRUCTED",
  "did": "did:key:z6Mkq61DMkUxeoZvAJoq3uZ6AMXjbzZNthpiVqFmPfwUuEvy",
  "sessionId": "sess_abc123",
  "repositoryId": "repo-xyz",
  "filePath": "src/algorithm/trading.ts",
  "hmac": "a3f5c8d2..." // HMAC(secret, prevHmac || entry)
}

HMAC chaining prevents insertion, deletion, or reordering of audit entries. Verification requires only the HMAC secret (held by repository owner) and the log file.

8. Integration Guide

Repository Setup

# Initialize xGit repository
xgit init my-protected-repo
cd my-protected-repo

# Import existing Git repository (optional)
xgit import --from-git /path/to/existing/repo

# Configure session policy
xgit config session.ttl 8h
xgit config session.renewal true

# Split files into shares (2-of-3)
xgit share --threshold 2 --total 3 src/

# Publish Share 1 to public registry
xgit publish share1 --registry github.com/myorg/my-repo-share1

# Store Share 3 in vault
xgit vault store share3 --hsm aws-kms://key-id

Contributor Workflow

# Authenticate with DID
xgit login --did did:key:z6Mk...

# Request session
xgit session request my-protected-repo --ttl 8h

# Work with reconstructed files (no cloning)
xgit checkout main
xgit file get src/algorithm/trading.ts

# Make changes (in session-gated editor)
vim src/algorithm/trading.ts

# Commit with DID watermark
xgit commit -m "Optimize trade execution" --sign

# Session expires → Share 2 purged → local files become noise

CI/CD Workflow

# .xgit/workflows/ci.yml
name: CI
on: push
jobs:
  test:
    runs-on: xgit-runner
    steps:
      - name: Reconstruct source
        run: xgit reconstruct --session ${{ session.id }}

      - name: Run tests
        run: npm test

      - name: Generate proof
        run: xgit prove --type audit --output proof.json

      - name: Verify proof
        run: xgit verify proof.json

Policy Configuration

# Branch protection rules
xgit policy branch main \
  --require-reviews 2 \
  --require-ci-pass \
  --require-signature \
  --allowed-dids did:key:z6Mk...,did:key:z6Mm...

# File-level access control
xgit policy file src/secrets/ \
  --clearance SECRET \
  --departments engineering,security

# Session limits
xgit policy session \
  --max-duration 12h \
  --max-concurrent 5 \
  --require-2fa

9. Advanced Distribution Architecture

Session 75-76 delivered production-grade share distribution infrastructure for geographic redundancy, mode-based threshold configuration, and enterprise-scale package management.

Multi-Backend Share Distribution

xGit supports multi-backend share distribution: shares can be stored and retrieved from different backend types (local filesystem, HTTP servers, or routed combinations). This enables geographic redundancy without increasing complexity.

Package Registry System

The package registry system enables bulk registration of npm packages with mode-based threshold configuration. Designed for registering entire monorepos (95+ packages) with a single command.

Production Deployment Pattern

The recommended production deployment for classified/regulated codebases:

Reconstruction: Any 2 of 3 shares. Share 0 (public) + Share 1 (VPS) = working code. Share 0 + Share 2 (EC2) = working code. Share 1 + Share 2 = working code. One server down = service continues.

Use Case: Platform-Wide Package Protection

PRIVATE.ME uses xGit to protect its 95+ package monorepo:

• Public packages (e.g., @private.me/crypto, @private.me/shareformat) registered in fault-tolerant mode (2-of-3). Share 0 published to npm. Share 1/2 on HTTP servers. Community can audit source without compromising security.
• Proprietary packages (e.g., @private.me/xprove, @private.me/xcompute) registered in maximum-security mode (2-of-2). Share 0 published as noise. Share 1 requires active session. No fault tolerance (deliberate tradeoff for maximum security).
• Batch registration: pnpm --filter @private.me/xgit-cli sync registers all 95 packages in ~2 seconds. Mode selection per package via package.json metadata field.

Result: Open-source transparency for public packages (Share 0 is real code), cryptographic protection for proprietary algorithms, single command to register entire monorepo.

Integration with Session-Gated Access

Multi-backend distribution integrates with DID-authenticated session management:

• Session creation: User authenticates with DID, receives session token, server stores (sessionId, did, allowedPackages, expiresAt).
• Share retrieval: HTTP share servers validate Bearer token against session store before serving Share 1/2. Share 0 (public) requires no auth.
• Geographic routing: Router backend sends users to nearest share server based on IP geolocation. Latency optimized automatically.
• Session expiry: When session expires, Share 1/2 requests fail with HTTP 401. Share 0 alone is useless. Contributor's local copy becomes noise.

Performance Characteristics

Network overhead: Multi-backend adds ~40-50ms latency for cross-region HTTP fetches vs. local filesystem. Acceptable tradeoff for geographic redundancy. Router backend can optimize by directing users to nearest server.

10. Honest Limitations

---

xGit is built on the PRIVATE.ME platform.
Threshold sharing: XorIDA. Identity: Decentralized DIDs. Verification: Zero-knowledge proofs.
private.me | SDK Documentation

Deployment Options

🌐

SaaS Recommended

Fully managed infrastructure. Call our REST API, we handle scaling, updates, and operations.

• Zero infrastructure setup
• Automatic updates
• 99.9% uptime SLA
• Pay per use

View Pricing →

📦

SDK Integration

Embed directly in your application. Runs in your codebase with full programmatic control.

• npm install @private.me/xgit
• TypeScript/JavaScript SDK
• Full source access
• Enterprise support available

Get Started →

🏢

On-Premise Enterprise

Self-hosted infrastructure for air-gapped, compliance, or data residency requirements.

• Complete data sovereignty
• Air-gap capable
• Docker + Kubernetes ready
• RBAC + audit logs included

Enterprise CLI →

Custom Requirements? Need dedicated infrastructure, white-label deployment, or custom integration? Contact our enterprise team →