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.
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. The full deliverable lives in the gated hardening sheet PDF; this is the public preview.
- 01SAML or OIDC identity boundary, bound to the customer's IdP. No vendor-side IdP path.
- 02IP allow-list at the platform edge and at the GitHub Actions runner edge.
- 03GitHub Actions runners isolated per environment, scoped to short-lived OIDC tokens, no long-lived secrets.
- 04Advanced Security (GHAS) enabled by default. Code scanning, secret scanning, dependency review.
- 05Branch protection rules enforced via policy-as-code, not manual configuration.
- 06Audit log streamed to the customer's SIEM and to the Reign Audit Ledger (CAVR).
- 07Copilot, Cursor, Claude Code, and Cortex governed through the Reign AI Gateway at the call layer.
- 08Approved-model registry for any LLM the coding agents call.
- 09Repository data-classification labels propagated to Reign for policy enforcement.
- 10Egress controls. Private Link or Private Endpoint to AWS, Azure, and GCP services.
- 11Backup and DR posture documented and audit-grade.
- 12Quarterly hardening review by the FDE pod. Continuous-remediation SLA on findings (P0 within 7 days, P1 within 21 days, P2 within 60 days).
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 FDE pod 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.
FDE Intervention
Decisions where iTmethods Forward Deployed Engineers 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 CRO, 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 FDE pod 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.
Talk to Forge engineeringDownload 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.
Get the hardening sheet