Evan Fischell Consulting
Phase 1 kickoff briefing  ·  Confidential
Prepared for Evergreen  ·  September 10, 2026

Phase 1 deep dive — current landscape and access

Prepared for: Evergreen
Prepared by: Evan Fischell Consulting
Date: September 10, 2026

This briefing supports Phase 1 of the project scope: governed agentic engineering and CI/CD. It does not change the Statement of Work, fees, or authorization terms.

We cannot inventory Evergreen's live Azure, Fabric, or GitHub estate until the access below is granted. This document describes what exists in the market today and what Evergreen needs to provide so that work can start.

Access we need

Phase 1 cannot evaluate brokers, stand up a harness, or implement CI/CD against Evergreen's environment without a place to build and a way to see what already exists.

Need Why What we will not do
Azure subscription, or a resource group in one, with full admin inside that boundary Create identity, networking, Key Vault, and the Phase 1 services. An existing development subscription is preferred if one exists. We will not take subscription-wide Owner if a dedicated resource group with Owner is enough. We will not change production resources without Evergreen approval.
A service principal with Reader (or equivalent) across the resources that already exist Inventory subscriptions, resource groups, networking, Fabric capacities, and identity so recommendations match the real estate. This identity is read only. It is not used to create, change, or delete resources.
GitHub organization admin on an existing org, or a new org where EFC can be an admin Create repositories, branch protection, Actions environments, and federated Azure credentials. We will not require admin of Evergreen's whole GitHub Enterprise if a dedicated organization can be created under it.

A dedicated development subscription with Owner for a named EFC identity is the cleanest form of the first item. If subscription-wide Owner is not possible, Owner on a dedicated resource group, plus the ability to create app registrations or user-assigned managed identities for GitHub OIDC, is the workable alternative.

The read-only principal should see what exists today, not only the new Phase 1 group: networking, existing data platforms, Fabric if present, and identity. Without that view, Phase 2 platform recommendations would be guesses.

flowchart TB subgraph EvergreenIT["Evergreen grants"] Sub["Azure subscription or dedicated RG with admin"] Reader["Read-only service principal"] Org["GitHub org admin or a new org"] end subgraph Phase1["Phase 1 work"] Inventory["Inventory what already exists"] Build["Build identity, network, and CI/CD"] Recommend["Recommend broker, harness, and delivery"] end Reader --> Inventory Sub --> Build Org --> Build Inventory --> Recommend Build --> Recommend

What AI contracts exist today

A contract here is the commercial and administrative product a team actually buys: seats, identity, data-handling terms, and whether the coding harness is included. It is not a model name.

Phase 1 will evaluate Azure Foundry, OpenAI, Anthropic, and Google as token brokers, and Claude Code, Codex, or Antigravity as the coding harness. The table below is the market as of 10 September 2026. Plan names and list prices change; confirm them at procurement.

Product Who it is for Coding harness Team administration Data and compliance notes
Claude Team Small and mid-size teams, minimum two members, up to 150 seats Claude Code is included on Standard and Premium seats, sharing the seat's usage pool Central billing, SSO, domain capture, JIT provisioning, role-based permissions, spend caps Anthropic states Team, Enterprise, and API traffic is not used to train models. HIPAA-ready configuration is an Enterprise feature, not Team.
Claude Enterprise Organizations that need audit, SCIM, retention, and usage-based billing Claude Code and Cowork included with the Enterprise seat Everything in Team, plus SCIM, audit logs, compliance and analytics APIs, customer-managed keys, US-only inference, IP allowlisting Seat fee covers access only; all tokens bill at API rates. Eligible orgs can enable a HIPAA-ready configuration and accept a BAA in organization settings.
ChatGPT Business Company-owned workspace without a full Enterprise negotiation Codex is included for Business workspaces Workspace billing, SAML SSO, seat controls. Premium seats exist for heavier ChatGPT / Codex users OpenAI states it does not train on Business workspace data by default. A Business seat does not move processing into Azure.
ChatGPT Enterprise Organizations that need advanced audit, retention, or dedicated support Codex included Enterprise admin, SSO/SCIM, stronger logging and retention Separate from Azure OpenAI / Microsoft Foundry token contracts.
GitHub Copilot Business / Enterprise Teams already on GitHub who want editor and agent assistance under org policy Copilot agents in the GitHub/VS Code surface. GPT-5.3-Codex is the current default base model for Business and Enterprise Org policy, audit, content exclusions, usage controls. Enterprise adds managed MCP allow/deny lists Business and Enterprise terms exclude training on that data; consumer Copilot plans are different.
Microsoft Foundry (Azure) Token broker inside Evergreen's Azure tenant Models from OpenAI, Anthropic, and others can be consumed through Azure, depending on the catalog Evergreen enables Azure RBAC, Private Link, selected networks, Key Vault, Cost Management Processing stays on Azure's contract and Evergreen's tenant controls. This is the path if data handling must remain in Azure.
Google Gemini / Antigravity Teams standardized on Google Cloud or Gemini Antigravity is a harness candidate in the Statement of Work; Gemini Code Assist is the Google Cloud coding product Google Cloud IAM and organization policy Confirm the exact SKU, data region, and training terms during Phase 1.

Claude Code Team is real and is the right Anthropic starting point to evaluate. It is not a separate SKU from Claude Team: Claude Code ships with Team Standard and Premium seats. Enterprise is the step up when Evergreen needs HIPAA-ready configuration, SCIM, audit logs, IP allowlisting, or uncapped usage billed at API rates.

Do not mix consumer plans with team plans. Claude Pro/Max and ChatGPT Plus/Pro are personal subscriptions. They do not provide SSO, central offboarding, or company data terms. Phase 1 should not put the pilot on personal seats.

Technical detail: published list prices and billing shape, 10 September 2026

These are vendor list prices for US customers, excluding tax. They are not a quote and not a change to EFC professional fees. Confirm at purchase.

Anthropic Claude Team (Team plan): Standard seats USD 20 per member per month billed annually, or USD 25 billed monthly. Premium seats USD 100 annually or USD 125 monthly. Minimum two members. Standard seats include about 1.25× Pro usage per session; Premium about 6.25× Pro. Usage limits are per member. Organizations can buy extra usage credits after the included pool. Above 150 seats, Anthropic directs teams to Enterprise.

Anthropic Claude Enterprise (Enterprise plan): a single Enterprise seat, billed annually. The seat is access only; Chat, Claude Code, and Cowork tokens bill at API rates. Self-serve minimum 20 seats; sales-assisted minimum 50. HIPAA-ready configuration is available on both purchase paths. US-only inference, when enabled, bills listed models at 1.1× API rates.

OpenAI ChatGPT Business / Enterprise (business pricing): Business is the team workspace; Enterprise is the negotiated admin tier. Codex is included for Business and Enterprise. OpenAI added Premium Business seats on 24 August 2026 for heavier ChatGPT, Work, and Codex use. Confirm the live seat price on OpenAI's page before purchase. Azure OpenAI / Foundry tokens are a separate Azure meter.

GitHub Copilot: organization plans are Copilot Business and Copilot Enterprise, with centralized policy and a pooled credit meter. GitHub made GPT-5.3-Codex the default base model for those plans on 17 May 2026. Treat third-party seat-price roundups as unverified until GitHub's live pricing page is captured at procurement.

Phase 1 compares these on permitted use, data handling, identity, and cost against expected pilot volume. The recommendation comes after that comparison, not from this briefing.

What version control and CI/CD exist today

The Statement of Work commits to implement CI/CD in GitHub Actions or Azure DevOps. Both are Microsoft products. Both are current. The choice is which control plane Evergreen already has, or is willing to run.

Control plane Source control Pipelines Strength for this engagement
GitHub (Team, Enterprise Cloud, or Enterprise Cloud with data residency) GitHub repositories GitHub Actions Native to coding harnesses, pull-request review, environment protection, and OIDC into Azure. Fastest path for a new engineering org.
Azure DevOps Azure Repos (or pipelines against GitHub) Azure Pipelines Stronger when Evergreen already lives in Boards, Repos, Test Plans, and classic release gates. Still fully supported.
Microsoft Fabric Git integration GitHub or Azure DevOps connected to a Fabric workspace Fabric deployment pipelines, plus fabric-cicd / Fabric CLI from GitHub Actions or Azure Pipelines This is Phase 2/3 delivery for reports and semantic models, not the Phase 1 application CI/CD. It still has to be designed now if GitHub gets an IP allow list.

Microsoft is not retiring Azure DevOps. In August 2026 it opened Enterprise Live Migrations in public preview: move Azure Repos to GitHub Enterprise Cloud with data residency (ghe.com), keep Azure Boards, and rewire Azure Pipelines onto the migrated GitHub repo. That is the coexistence path if Evergreen already has Azure DevOps.

What Phase 1 will actually stand up, on whichever platform Evergreen selects:

  1. Isolated branches for parallel work.
  2. Automated tests and review gates on the current commit.
  3. Protected environments for production, with a named approver.
  4. Short-lived federated credentials into Azure (OIDC), not long-lived secrets in the pipeline.
  5. Build once, promote the same artifact, and verify the live revision.
  6. A documented rollback to the previous artifact.

GitHub-hosted runners are the default. If Evergreen later places Azure or Fabric resources on private networks, the pipeline needs runners that can reach those networks: GitHub-hosted larger runners with static IPs, Azure private networking for hosted runners, or self-hosted runners inside the VNet.

Technical detail: identity from the pipeline into Azure

Microsoft documents OpenID Connect from GitHub Actions to Azure. The pipeline requests a short-lived GitHub OIDC token (id-token: write) and exchanges it for Azure credentials via a federated identity on an app registration or user-assigned managed identity.

That is why GitHub org admin and Azure identity-create rights both appear in the access list. Without them, Phase 1 would fall back to storing a client secret in GitHub, which we will not recommend.

Pin third-party Actions to reviewed commit SHAs. Separate the plan identity from the apply identity for infrastructure. Do not give untrusted pull-request workflows production credentials.

What networking controls exist today

"Enterprise" here means the controls Azure, Fabric, and GitHub actually ship, not a guess at Evergreen's current configuration. The read-only service principal is how we learn which of these are already on.

Azure

Control What it does Phase 1 relevance
Virtual network and subnets The private network boundary for services that need one Default home for private endpoints and, later, private data-plane services
Network security groups Allow/deny at subnet or NIC Least-privilege inbound/outbound for anything we deploy
Private Endpoint / Azure Private Link Service gets a private IP; public inbound can be disabled Preferred pattern for Key Vault, storage, Foundry, and data services
Service tags and the published Azure IP ranges Identify Microsoft services in NSG and firewall rules Needed when a firewall must allow Azure without allowing the internet
Foundry inbound isolation Foundry public access Disabled with a private endpoint, or Selected networks Required if the token broker is Foundry and Evergreen wants the broker off the public internet
Key Vault + managed identity Secrets never sit in GitHub or in agent config files Non-negotiable for Phase 1

Foundry can also be virtual-network injected. Egress then needs an explicit allow list of Microsoft identity and Foundry FQDNs or service tags. Hosted Foundry agents on projects created after 25 June 2026 can use a private Azure Container Registry.

Microsoft Fabric

Fabric is a SaaS data plane. Its network controls are tenant-wide or per workspace, not a VNet you own for the whole product.

Control Scope What it does
Azure Private Link for Fabric Tenant Private backbone path into Fabric. Pair with Block public Internet access to refuse public clients.
Workspace-level private links One workspace Restrict a sensitive workspace without locking the whole tenant.
Workspace IP firewall One workspace Allow listed public IPs alongside or instead of private links.
Managed private endpoints Outbound from Fabric Fabric Spark/pipelines reach an Azure or on-premises source over Private Link, with Evergreen approval of the endpoint.
Outbound access protection Workspace workloads Limit where Fabric compute is allowed to go.

Enabling tenant-level Private Link and blocking public access has wide side effects (which Fabric items still work, which URLs the browser still needs, admin-portal behavior). Do not turn it on as a Phase 1 experiment. Record whether Evergreen already uses it, because it changes how CI/CD and Git integration must connect.

GitHub IP allow lists cannot use Azure service tags. Fabric Git integration originates from regional Microsoft IPs that change. If Evergreen enables a GitHub IP allow list and later connects Fabric to that org, the allow list has to track Fabric's published IPs. That is a known operational gap, not a reason to skip GitHub; it is a reason to design the allow list before Fabric Git is turned on.

GitHub (Enterprise Cloud)

IP allow lists, SAML/OIDC enterprise login, and Enterprise Managed Users are GitHub Enterprise Cloud features. A free or Team organization does not get an IP allow list.

Control What it does Watch-outs
Organization or enterprise IP allow list Restricts web, API, Git, PAT, SSH, and Actions GITHUB_TOKEN access to listed CIDRs Does not cover anonymous public traffic. GitHub Actions then needs self-hosted or larger hosted runners with static IPs (or the Azure subnet used for private hosted runners). GitHub Codespaces for that org is disabled.
SAML SSO / OIDC enterprise login / EMU Company identity is the only login Decide this before inviting a pilot team onto personal GitHub accounts.
Environment protection rules Named reviewers, wait timers, restricted secrets This is the production approval gate Phase 1 will use.
Copilot managed MCP allow/deny lists Enterprise owners control which MCP servers Copilot may run Relevant once a harness is chosen; fail-closed if the policy file is malformed.
OIDC federation to Azure Short-lived deploy credentials Requires org/repo admin to create the trust and Azure rights to create the federated identity.

If Evergreen already has GitHub Enterprise, org admin on a dedicated org under that enterprise is enough. If there is no org, creating one — Enterprise trial or a new org that can later move under Enterprise — unblocks Phase 1. Personal repositories are not an acceptable control plane.

Technical detail: recommended Phase 1 network posture

Until the read-only inventory is done, treat this as the default we will propose, not as a claim about Evergreen's current network:

  • Dedicated resource group (or subscription) for Phase 1.
  • Public internet only where a service must be reached by developers (for example GitHub.com). Everything else private-endpoint first.
  • Foundry, if selected, on selected networks or Private Link rather than fully public.
  • GitHub-hosted runners for the first CI/CD, with an explicit later path to static-IP or VNet-attached runners if private data-plane access is required.
  • Do not enable a GitHub IP allow list until we know how Fabric Git, GitHub Actions, and EFC operators will connect.
  • No PHI in Phase 1. Network isolation of the token broker is still worth doing; it is not a substitute for a BAA or for keeping PHI out of the pilot.

How this maps to the month of Phase 1

Week focus Depends on
Inventory Azure / Fabric / GitHub with the read-only principal; confirm whether a dev subscription already exists Reader SP + GitHub visibility
Compare brokers and harnesses against Evergreen's identity, data-handling, and cost constraints; recommend one Access to admin on the chosen vendor tenant, or a decision to create one
Implement CI/CD, environments, OIDC, and the supported workstation/harness setup Azure admin boundary + GitHub org admin
Train the pilot team and demonstrate the delivery loop Named pilot users on company accounts

Done still looks like the Statement of Work: a governed agentic engineering workflow and CI/CD foundation, with the team ready to use them.

Open questions this access will answer

These are unknown until the read-only principal and GitHub access land. They are the first week's work, not blockers to granting the access.

Sources

Vendor pages reviewed 10 September 2026. Confirm at procurement; capabilities move.