Energy Monitoring

Energy Monitoring for SOC Analysts

GOVERN Energy is the surveillance and anomaly detection layer of the GOVERN platform. From a SOC perspective, it works like network detection and response (NDR) for AI — but instead of watching packet flows, it watches inference patterns, behavioral coherence, and deliberation expenditure.

This page covers what Energy alerts look like, how to investigate them, and how to triage findings.

What Energy Monitors

Energy answers two questions that no log-based tool can answer:

Is there AI here that nobody authorized? Shadow AI — undeclared models, rogue inference servers, developer wrappers — is invisible to every other governance tool. Energy finds it using behavioral pattern analysis, not signatures.
Has an authorized AI silently stopped governing itself? A governed AI system that drops its deliberation activity has drifted from its constraints without generating any error, any log entry, or any observable output change. Energy detects this before it compounds.

L1 / L2 / L3 Detection Layers

Energy operates in three simultaneous detection layers. Each layer catches different threat surfaces.

L1 — Infrastructure Layer

What it watches: Processes, network traffic, and data access at the infrastructure level.

Detection methods:

eBPF process fingerprinting — runs at the Linux kernel level, identifies ML framework library loading patterns (PyTorch, TensorFlow, vLLM, ONNX Runtime, Llama.cpp, and others) without any agent installed on the monitored host.
Network flow analysis — identifies inference traffic by its shape: small prompt → latency gap → large streaming response. Catches AI calls made through HTTP clients, even when no ML library runs on the calling host.
Data access monitoring — watches for systematic data access patterns characteristic of AI inference: full-directory scans, range queries without filters, repeated dataset sampling.

SOC context: L1 alerts are the equivalent of finding an unauthorized service listening on a known port. When L1 fires, there is AI running in your infrastructure that nobody told GOVERN about.

Typical L1 alert:

SHADOW AI DETECTED
Host: 10.0.1.45
Runtime: vLLM 0.4.1
GPU Utilization: Active (L4 GPU, CUDA 12.3)
Network: Outbound connections to api.openai.com, api.anthropic.com
Status: NOT REGISTERED in GOVERN
Confidence: 0.93

L2 — Behavioral Layer

What it watches: The mathematical structure of AI output patterns from registered systems over time.

Detection methods:

Behavioral coherence scoring — measures how consistent a system’s output structure is relative to its established baseline. Coherence does not evaluate content — it measures the distribution of token patterns, response length distributions, and entropy signatures.
Semantic drift detection — detects when a system’s response clustering shifts relative to baseline. A customer support classifier that starts producing responses in a semantic cluster it never used before has drifted.
CuC (Coherence Under Constraint) scoring — measures whether a system’s outputs show the mathematical signature of operating under governance constraints. Systems under active governance show measurable deliberation overhead in their output structure. Systems that have dropped governance constraints show a distinctive CuC drop.

SOC context: L2 alerts are the AI equivalent of a behavior-based EDR alert — the system is still running, nothing crashed, but its behavioral pattern has changed in a way that indicates something is wrong.

Typical L2 alert:

DRIFT DETECTED
System: Hiring Decision Engine (sys_01HXXXXXXXXXXX)
Baseline CuC: 0.91 (established over 30-day window)
Current CuC: 0.72
Delta: -0.19 (19-point drop)
Window: 48 hours
Pattern: Deliberation overhead dropped; response latency decreased 23%
Recommended: Trigger Assess — compare against last passing assessment

L3 — Judgment Boundary Layer

What it watches: The 10 Sohtym signatures — mathematical patterns that appear at the boundary between governed and ungoverned AI behavior.

Detection methods:

Sohtym signature analysis — each of the 10 Sohtym signatures represents a distinct mathematical pattern that emerges when an AI system approaches or crosses a judgment boundary: the point at which it transitions from operating within its governance constraints to operating outside them.
Longitudinal coherence modeling — L3 builds a long-horizon model of each system’s deliberation expenditure over weeks and months, enabling detection of gradual drift that would not trigger a threshold-based alert.
Cross-system comparison — L3 compares behavioral signatures across all monitored systems in the organization to identify anomalous outliers.

SOC context: L3 alerts are the most sophisticated and highest-confidence signal in Energy. When L3 fires, the system has been observed long enough for a statistically reliable behavioral model to exist, and that model has identified a genuine anomaly.

Typical L3 alert:

JUDGMENT BOUNDARY CROSSING — L3
System: Credit Scoring Model (sys_01HXXXXXXXXXXX)
Sohtym Signatures: 3 of 10 active (threshold: 2)
  → Sig-4: Deliberation collapse pattern detected
  → Sig-7: Constraint evasion signature emerging
  → Sig-9: Output distribution diverging from governance baseline
Confidence: 0.87
Horizon: 21-day longitudinal analysis
Severity: HIGH

Shadow AI Detection Alerts

Shadow AI alerts fire when Energy detects AI activity from a system that is not registered in GOVERN.

What They Look Like

Shadow AI alerts appear in the Energy section of the Dashboard under Unregistered Activity. Each alert includes:

Host or endpoint — where the activity was detected
Detection method — L1 infrastructure (eBPF, network flow, data access) or behavioral pattern
Runtime identified — which ML framework is running
Confidence score — 0.0–1.0, based on the number and consistency of detection signals
First seen / Last seen — activity window
Data exposure risk — whether the system appears to be accessing sensitive data repositories

How to Investigate

Step 1 — Verify the detection. Review the detection signals. An eBPF fingerprint alone has high precision; network flow analysis alone has high recall. Multiple signals firing simultaneously is high confidence.

Step 2 — Identify the system. Use the host IP or container ID to find the responsible team. Check your CMDB, Kubernetes namespace, or cloud resource tags.

Step 3 — Determine authorization status. Was this system approved through IT security review? Is it a vendor-embedded AI you didn’t know about? Is it a developer’s local experiment that got pushed to a shared server?

Step 4 — Assess data exposure. What data does this system have access to? L1’s data access monitoring shows filesystem and database access patterns associated with the AI process. Determine if regulated data (PII, PHI, financial records) is within reach.

Step 5 — Remediate or register. Either:

Register the system in GOVERN (if authorized) and begin formal governance
Isolate and remove the system (if unauthorized)
Escalate to the system owner with a 24-hour response requirement

Step 6 — Document. Record the finding, investigation steps, and resolution in your ITSM system. Energy generates a Finding record automatically — link your ITSM ticket to the GOVERN finding ID.

Drift Monitoring Alerts

Drift alerts fire when a registered, authorized AI system’s behavior deviates from its established baseline.

What to Look For

Drift alerts include a delta score — the difference between the current CuC score and the established baseline. Use the delta to prioritize:

Delta	Severity	Priority
-0.05 to -0.10	MEDIUM	Monitor — may be normal variation
-0.10 to -0.20	HIGH	Investigate within 4 hours
> -0.20	CRITICAL	Escalate immediately

Behavioral Deviation Indicators

When investigating a drift alert, look for:

Response latency decrease — a governed system that stops deliberating gets faster. A sudden speed increase without a deployment event is a drift signal.
Token count decrease — deliberation uses tokens. If average response token count drops and no model update occurred, deliberation dropped.
Output cluster shift — the semantic topics the system addresses have shifted. Previously it handled only X; now it’s handling X and Y without explicit expansion of scope.
Policy hit rate drop — if the Policy Engine’s warn/monitor hits for this system suddenly drop to zero, the system may have stopped triggering policy evaluation entirely.

What to Do

Correlate with deployment events. Check if a model version change, configuration update, or infrastructure change preceded the drift. Check your change management records against the drift onset time.
Trigger an Assess. Run a full GOVERN assessment against the current version of the system. Compare the score and findings against the last passing assessment.
Review Probe telemetry. The Probe attached to this system has the most granular telemetry. Look for the specific inference calls where CuC began dropping.
Escalate to the system owner. Share the drift report. Ask for a change log.

CuC Score Interpretation

CuC (Coherence Under Constraint) measures whether an AI system’s outputs show the mathematical signature of operating under governance constraints.

Score Range	Interpretation	SOC Action
0.85–1.00	Fully governed — deliberation overhead consistent with baseline	No action
0.70–0.84	Mild drift — governance overhead slightly reduced	Log and monitor
0.50–0.69	Moderate drift — governance constraints weakening	Investigate within 4h
0.30–0.49	Significant drift — governance likely compromised	Escalate to AI governance team
0.00–0.29	Severe drift or ungoverned — governance constraints not functioning	Immediate escalation

The CuC score is not an output-level metric — it is a structural measurement of the deliberation pattern. A system can produce perfectly acceptable outputs while its CuC has collapsed. The score tells you about the internal governance machinery, not the surface behavior.

Triage Workflow for Energy Findings

Energy Alert Received
  │
  ├─ Shadow AI (Unregistered System)?
  │     │
  │     ├─ Confidence > 0.80 → Immediate investigation
  │     │     → Identify host, system, team
  │     │     → Assess data exposure
  │     │     → Register or isolate within 24h
  │     │
  │     └─ Confidence 0.50–0.80 → Log and validate
  │           → Cross-reference with IT asset inventory
  │           → If confirmed: escalate to full investigation
  │
  └─ Drift (Registered System)?
        │
        ├─ CuC delta > -0.20 (CRITICAL) → Escalate immediately
        │     → Notify AI governance lead
        │     → Trigger emergency Assess
        │     → Consider suspending system pending review
        │
        ├─ CuC delta -0.10 to -0.20 (HIGH) → Investigate within 4h
        │     → Review Probe telemetry
        │     → Check for deployment events
        │     → Trigger Assess
        │
        └─ CuC delta < -0.10 (MEDIUM) → Log and monitor
              → Add to watch list
              → Review again in 24h

Key Energy Dashboard Locations

View	Dashboard Path	What You See
Shadow AI inventory	Energy → Unregistered Systems	All detected unregistered AI, confidence scores, data exposure indicators
Drift monitoring	Energy → Drift Analysis	Per-system CuC trend, delta scores, L2/L3 signal breakdown
L3 signature status	Energy → Judgment Boundaries	Which Sohtym signatures are active per system
Energy feed	Energy → Live Feed	Real-time stream of all Energy events
System baseline	Energy → Baselines → [System]	Baseline CuC, historical trend, baseline confidence