Skip to main content

    FORGE · MANAGED GITHUB ENTERPRISE

    Managed GitHub Enterprise. Inside your trust boundary. Hardened, governed, Reign-ready.

    GitHub Enterprise Server or GitHub Enterprise Cloud deployed inside the customer's authorization boundary. Forge runs the substrate. Reign governs Copilot, Cursor, Claude Code, Cortex, and the rest of the coding-agent fleet at the call layer. Continuous assurance of every read and every write.

    ProofSOC 2 Type II·HIPAA-eligible·FedRAMP-aligned·AWS Advanced Tier·FINOS AIGF aligned
    DEPLOYMENT OPTIONS

    Three deployment shapes. One operating posture.

    GitHub Enterprise Server in Customer Cloud

    Your AWS, Azure, or GCP account. Your VPC. Forge operates the substrate; you own the infrastructure. The default posture for regulated banks and capital markets firms standardizing on a single hyperscaler.

    GitHub Enterprise Cloud, Forge-hardened

    For organizations that prefer the GHEC product surface but require operator-grade hardening. Forge-managed identity boundary, network policy, and audit-trail wiring; Reign on the AI coding tool layer. Same shared-responsibility model as Server in Customer Cloud.

    GitHub Enterprise Server in air-gapped sovereign deployment

    Defense, classified, sovereign-national programs. FIPS 140-2 Level 3. ITAR, NIST 800-171, and CMMC alignment. No outbound calls to github.com. The substrate lives entirely inside the customer's authorization boundary.

    THE HARDENING SHEET

    What Forge applies on day one.

    Twelve named controls. Each is policy-as-code, not manual configuration. Five of the twelve are below. The full deliverable, with regulator framework mapping, deployment topology diagrams, and sample policy-as-code excerpts, lives in the gated hardening sheet PDF.

    • 01SAML or OIDC identity boundary, bound to customer IdP.
    • 02IP allow-list at the platform edge and the runner edge.
    • 03Runners isolated per environment. Short-lived tokens. No long-lived registration.
    • 04Audit log streamed to the customer's SIEM and to the Reign Audit Ledger (CAVR).
    • 05AI coding tools governed through the Reign AI Gateway.

    Plus seven more covering code scanning, branch protection, approved-model registry, data classification, egress controls, backup and DR, quarterly operating partner hardening review.

    REIGN-READY · AI CODING TOOL LAYER

    The AI coding tools. Governed at the call layer.

    Copilot, Cursor, Claude Code, Cortex are productivity multipliers. They are also the largest emerging side-channel for source code and secrets exposure. Reign governs them as first-class call-layer subjects.

    • Every AI coding tool call routed through the Reign AI Gateway. Identity-bound. Content-classified. Policy-enforced before the LLM sees the code.
    • Tamper-evident audit trail of every coding-agent decision in the Reign Audit Ledger (CAVR).
    • Approved-model registry mapped to the customer's AI governance posture (SR 26-2, EU AI Act, FDA PCCP, FINOS AIGF where applicable).
    SHARED RESPONSIBILITY

    What we run, what you run. Scoped to GitHub.

    Forge Automated

    Decisions Forge closes inside the GitHub Enterprise substrate without human intervention.

    • Operate GitHub Enterprise Server or GitHub Enterprise Cloud inside the customer's authorization boundary.
    • Enforce the customer-bound IdP (SAML, OIDC, SCIM) at the platform edge.
    • Run Actions runners isolated per environment, short-lived OIDC tokens, no long-lived secrets.
    • Stream the GitHub audit log to the customer's SIEM and to the Reign Audit Ledger (CAVR).
    • Patch the substrate and runner fleet on a continuous-remediation SLA.

    Customer Authored

    Decisions the customer owns. The customer is the author, not just the approver.

    • Own repositories, intellectual property, code review policy, and branch protection rules.
    • Author the catalog of AI coding tools sanctioned (Copilot, Cursor, Claude Code, Cortex).
    • Approve evaluators the operating partner team authored during the on-ramp phase against the customer's AI inventory.
    • Sign off on examination snapshots (Assurance Pack outputs) before delivery to the regulator.
    • Approve new agentic tool integrations and policy exceptions surfaced by the evaluator fleet.

    Operating Partner Engagement

    Decisions where iTmethods operating partners run the work. Authoring on-ramp plus continuous-remediation SLA.

    • Stand up the initial hardening configuration on the GitHub Enterprise substrate.
    • Author the first 10 to 15 evaluators against the customer's GitHub surface (Copilot use, repository access patterns, secret exposure, Actions workflow drift).
    • Operate the continuous-remediation SLA on findings the evaluator fleet emits.
    • Lead quarterly posture reviews with the customer's Chief Risk Officer, CISO, audit committee, and Independent Assurance function.
    • Train the customer's audit and MRM teams to author their own evaluators.
    REIGN TIER ALIGNMENT

    Which Reign tier do customers typically enroll into?

    Most regulated GitHub on Forge customers also enroll in Reign Assurance or Reign Continuous. The coding-agent governance is delivered by Reign at the call layer. The hardening and operations are delivered by Forge. The same operating partner team runs both.

    FAQ

    Five questions before the scoping call.

    How is pricing structured?
    Services-as-software, bundled inside the Reign tier the customer enrolls into. Reign Assurance or Reign Continuous is the typical envelope; the GitHub Enterprise on Forge engagement is delivered by the same FDE pod that runs the rest of the Reign posture. No per-seat surcharge on top of the tier.
    How do you migrate from GitHub.com to GitHub Enterprise on Forge?
    FSAI Assess scopes the migration as a 4 to 6 week engagement. Inventory of repositories, secrets, Actions runners, and GHAS configuration; gap analysis against the customer's regulatory surface; a phased cut-over plan with continuous-assurance posture going live on day one of the new substrate.
    What does the GitHub Actions self-hosted runner topology look like?
    Runners isolated per environment, scoped to short-lived OIDC tokens, no long-lived secrets. Each runner has its own egress controls and audit trail. Reign AI Gateway sits between any AI coding tool the workflow calls and the LLM. The runner is the unit of isolation, not the repository.
    How is Copilot governance handled?
    Every Copilot call routed through the Reign AI Gateway. Identity bound to your IdP, content classified before the model sees it, repository data-classification labels propagated to Reign for policy enforcement. Tamper-evident audit trail in the Audit Ledger (CAVR). Approved-model registry maps to your AI governance posture (SR 26-2, EU AI Act, FDA PCCP, FINOS AIGF where applicable).
    What changes if GitHub the vendor has a security incident?
    Your code stays in your trust boundary. Authorization to your repositories is independent of GitHub's vendor-side posture. iTmethods leads the patch cadence inside your environment, runs the customer-side impact analysis, and delivers an Assurance Pack snapshot your audit committee can present.

    Talk to Forge engineering.

    Scope a hardened GitHub Enterprise deployment inside your trust boundary. Server, Cloud-hardened, or air-gapped. Reign-ready for the AI coding tool fleet.

    Download the GitHub on Forge hardening sheet.

    The full 12-control policy-as-code reference, organized by audit framework. Drops into the FSAI Assess scoping conversation.