NERC CIP AI Compliance Checklist for Authenticated LLM Traffic

A control-room engineering diagram is visible in the prompt preview while the destination field points to a public model endpoint. That single screen determines if a registered entity's use of an external LLM in a workflow connected to BES Cyber System information or operations has a usable control record. The NERC CIP standards index sets the programme obligation, while CIP-003-9 Security Management Controls supplies the control or assessment method. A nerc cip AI compliance checklist should connect those requirements to the authenticated HTTP request before the payload reaches an LLM.

The safest AI route in a registered entity is the one the CIP evidence package can reconstruct without asking the model vendor for a favor.

TL;DR

• Scope every AI route that can touch regulated data or a financially relevant workflow, including the calling application and supplied identity, plus the model destination and bypass paths.
• Test authorization and information-flow policy with real requests, not screenshots of configuration pages. Use them to test event content, record integrity, historical retrieval and exception handling.
• Keep the boundary explicit. A gateway contributes to authenticated HTTP model traffic; BES categorization and physical security, recovery exercises and personnel training, plus patch management and the registered entity's compliance determination remain with their existing owners.
• Retain the policy version and decision beside the event so a reviewer can reproduce what happened at that point in time.

Check 1: freeze scope and ownership

Owner: the programme lead with the system owner.

Pass condition: the inventory names every application and agent that can send in-scope information to an LLM. Each row identifies the business purpose and authenticated principal type; model endpoint and data class; provider account and network route; control owner and known bypass. The scope decision cites NERC CIP standards index and records the rationale for inclusion or exclusion.

Evidence: approved inventory and route diagram; sample request and endpoint list; provider contract reference and a dated sign-off. The diagram should show the application and inspection point, with the model endpoint and audit store as separate boxes. This is where an opaque vendor feature gets marked as opaque rather than quietly counted as covered.

Check 2: test identity and request authorization

Owner: IAM with the AI platform owner.

Pass condition: an authorized user can reach the approved model route. Two negative tests confirm that an unauthorized role is denied and that a request with missing or expired identity context fails closed. The event must preserve the originating person or workload rather than only the shared provider credential. CIP-005-7 Electronic Security Perimeters provides the wider risk and control context for that test.

Evidence: identity schema and role mapping; policy version and three staged request results; timestamps and correlation identifiers joining upstream authentication to the outbound model call. The AI agent identity guide explains why a service account alone leaves a weak attribution trail.

Check 3: enforce the information boundary

Owner: the regulated data owner with security engineering.

Pass condition: the route blocks or redacts a staged sensitive field sent to a disallowed model endpoint and records a permitted equivalent on an approved route. The test uses synthetic content and names the expected outcome before execution.

Evidence: classification rule and route allowlist; permit event and denial or redaction event; reviewer and exception ticket. The relevant CIP set covers management in CIP-003 and electronic perimeters in CIP-005; system controls in CIP-007 and incident response in CIP-008; configuration changes in CIP-010 and information protection in CIP-011. A control description without its failed test belongs in design documentation, not in a completed checklist.

Check 4: prove the record is complete and protected

Owner: security operations with internal audit or compliance testing.

Pass condition: every staged permit or redact event appears in one frozen population. The same population contains every staged denial and processing error. Each row carries the supplied identity and timestamp; calling application and model destination; data classification and policy version; action and response disposition; plus a stable event identifier.

Evidence: population manifest and record schema; protected-store permissions and integrity-test output; plus the query used to reproduce the export. The tamper-evident audit log guide covers the custody mechanics behind this check.

Check 5: test retrieval and exception handling

Owner: records management with the incident or audit lead.

Pass condition: a reviewer selects an event from the oldest available period and the team returns the original row and its integrity result, plus the linked policy and exception disposition. A second exercise traces an unapproved destination attempt through triage and closure.

Evidence: timed retrieval result and archive restoration step if one exists; exception register and investigation notes; plus closure approval. The LLM audit log retention guide separates configured retention from evidence that old records can actually be recovered.

Check 6: record boundaries and compensating controls

Owner: the system owner with enterprise architecture.

Pass condition: the file lists direct browser traffic and local model execution; unmanaged devices and compromised sessions; plus vendor-embedded inference that never crosses the governed route. Each excluded path has a named compensating control and owner.

Evidence: boundary register and endpoint control references; network control references and vendor assurance evidence; plus a residual-risk approval. Bes categorization and physical security, recovery exercises and personnel training, plus patch management and the registered entity's compliance determination remain outside the request gateway's control. Marking those limits makes the checklist defensible.

DeepInspect

DeepInspect operates between authenticated users or agents and HTTP-based LLM endpoints. For routed traffic it evaluates the identity and policy context supplied by the application, then classifies the request. It permits or redacts the request and can deny it. It inspects the response and writes a per-decision record.

That record supports the checklist's authorization and information-flow tests, plus its population and integrity tests, followed by retrieval. It cannot govern calls that bypass the route or create upstream identity. It also cannot perform BES categorization and physical security, recovery exercises and personnel training, plus patch management and the registered entity's compliance determination. Book a technical deep dive at deepinspect.ai.