Classify data, not tools. Most of what your developers touch daily falls in the moderate-to-low sensitivity range. That's where AI delivers the largest productivity gains with the lowest risk.
Part 02 mapped the regulatory boundaries. Now we need an architecture that matches AI tool tiers to data sensitivity, opening up AI where the data allows it while keeping the hardest boundaries around the data that demands them.
§ 01Three zones, three control postures
The reference architecture has three concentric zones, separated by firewalls with deep packet inspection at each boundary. The outermost zone is your general development environment. The middle zone is your secure development environment for utility-specific work. The innermost zone is your OT/CEII enclave, air-gapped, with no AI tooling at all. Each zone has a different posture for AI access, data flow, and audit.
Zone 1: OT / CEII enclave (red, air-gapped)
The air-gapped environment where your most sensitive data lives. SCADA/EMS systems, relay configurations, protection scheme settings, CEII-designated documents, grid topology models, BMS firmware, BESS operational control systems. No AI tools. No cloud connectivity. Authorized OT personnel only.
This zone doesn't change. If you already have a properly segmented OT environment (and if you're NERC CIP compliant, you do) Zone 1 is your existing architecture with an explicit "no AI tools" policy added to it.
Zone 2: Secure development (amber, AI-enabled with full controls)
This is where the productivity gains happen. Zone 2 is your AI-enabled development environment for work that touches utility-specific systems but doesn't involve CEII or direct OT access.
Claude Code points to a model endpoint running inside your cloud tenancy: Bedrock within your VPC, Azure AI Foundry within your tenant, Vertex AI within your GCP project. Code goes to the model, results come back, nothing leaves your cloud environment. Defense in depth adds layers around that core.
- Deny rules in Claude Code provide a first-pass filter against sensitive file patterns (*.ceii files, relay configurations, protection scheme exports, SCADA data exports). Best-effort controls, not hard security boundaries, which is why the layers below them matter.
- Pre-commit hooks scan every commit for CEII markers, internal IP ranges, substation identifiers, relay settings, and credential patterns before code reaches version control.
- DLP inspection at the zone boundary monitors all egress traffic for sensitive data patterns.
- Full audit logging of every AI interaction feeds into your SIEM pipeline, satisfying CIP-007 system event monitoring requirements.
- No direct network path to Zone 1. The firewall/DMZ between zones blocks lateral movement.
Zone 3: General development (green, AI-enabled with standard controls)
Non-sensitive application development with enterprise-tier AI tools under standard controls. Customer portals, mobile apps, billing system integrations, documentation, open-source work, vendor integrations. Junior developers build fluency with AI tooling here before moving to Zone 2.
§ 02The data classification matrix
The architecture only works if people know which data goes where.
| Data type | Examples | Zone |
|---|---|---|
| CEII / OT | Grid topology, relay settings, protection schemes, BMS firmware, SCADA configurations | Zone 1 (RED) |
| Utility-specific code | DERMS/ADMS integrations, OMS logic, MDM pipelines, BESS analytics, internal APIs | Zone 2 (AMBER) |
| Cybersecurity tooling | SIEM rules, NERC CIP evidence collectors, log parsers, compliance scripts | Zone 2 (AMBER) |
| Customer-facing apps | Web portals, mobile apps, payment processing, account management UI | Zone 3 (GREEN) |
| Open source / docs | Public repos, vendor integrations, internal documentation, marketing tooling | Zone 3 (GREEN) |
§ 02NERC CIP compliance mapping
Each zone satisfies specific NERC CIP requirements. The architecture is designed so a CIP audit can trace every data flow to a specific control.
- CIP-005 (Electronic Security Perimeters): The firewall/DMZ between zones is the explicit ESP boundary, with logged and inspected traffic.
- CIP-007 (System Security Management): AI interaction logs from Claude Code stream into the SIEM, satisfying event monitoring requirements for the dev environment.
- CIP-010 (Configuration Change Management): AI-assisted commits route through the same change management process as manual ones; pre-commit hooks enforce scanning.
- CIP-013 (Supply Chain Risk Management): Cloud provider for AI model hosting (Bedrock/Foundry/Vertex) is in your existing CIP-013 vendor inventory.
- CIP-003-9 (effective April 2026): Your AI acceptable use policy and access controls are documented and reviewed annually.
§ 04The boundary between Zone 2 and Zone 1
The DMZ between Zone 2 and Zone 1 is the most important security control in the architecture. It runs DLP inspection on every byte that tries to cross. The patterns it scans for include CEII markers, IP/subnet ranges that match your OT networks, SCADA-export file signatures, relay configuration formats, and credential patterns. Anything matching is blocked at the boundary and alerted to security operations.
This isn't theoretical defense. It's the same kind of egress filtering that financial services run on customer-data flows, applied to utility-specific patterns. The cost of building it is small compared to the cost of one CEII leak finding its way to a public AI training corpus.
§ 05Identity and access
A single identity provider (Okta, Azure AD, Ping) governs access to all three zones, with role-based controls and SSO/MFA across the board. Engineers move between Zone 2 and Zone 3 based on the project they're working on. Movement into Zone 1 requires elevated access, hardware tokens, and audit logging that flows directly to your security operations center.
§ 06What this isn't
This architecture isn't a prohibition on AI use; it's a structure for it. It isn't a one-size-fits-all blueprint; small utilities may collapse Zone 2 and Zone 3 into one zone with stronger DLP at the OT boundary, while larger utilities may add sub-zones within Zone 2 for different sensitivity classes. It isn't a static design; CIP standards evolve, AI capabilities change, and the architecture should be reviewed annually against both.
What it is: a defensible, auditable structure that lets your engineers use modern tools on the work where they help most, while keeping the air-gap intact around the work where they don't belong.
§ 07Next in the series
The architecture is designed. Part 04 walks through the 90-day execution plan: classification exercise, infrastructure build, pilot, scale.
— Adam · adam@sgridworks.com · Feb 2026