CIFM v1.3 Through v1.5: Following AI Into the Dark

From May 17 through early June 2026, the Converged Infrastructure Forensics Model went through three successive revisions — v1.3RC, v1.4RC, and v1.5RC — each one adding a layer of investigative capability in direct response to what AI is actually doing inside enterprise environments today.

This article walks through that arc. Not as a changelog, but as a story about where the forensic gap actually lives — and how CIFM moved to close it.

What CIFM Is, and What It Was Missing

CIFM is a practitioner framework for reconstructing adversary activity across converged infrastructure ecosystems: cloud, OT, IoT, telecom, and the identity systems that bind them together. The core insight of CIFM is that modern incidents don't happen on a single host. They happen across trust boundaries, identity systems, and control planes that traditional forensic methodologies were never designed to span.

Through v1.2.1RC, CIFM had addressed cloud forensics, identity-centric investigation, distributed telemetry correlation, ephemeral workload handling, and the Unified Evidence Manifest (UEM) as a normalized evidence structure. What it hadn't yet addressed was the specific investigative challenge that AI introduces — not AI as an analyst tool, but AI as an actor inside the environment under investigation.

That changed in May 2026.

v1.3RC: CIFM Enters the AI Incident Domain

Published: 17 May 2026

The first question any forensic framework has to answer when AI enters the picture is: what does the scope of an AI-driven incident actually look like?

The answer is more complicated than it sounds. When an AI agent causes, contributes to, or mediates a security incident, the investigator confronts a set of problems that don't map cleanly onto traditional IR:

• The AI system may have taken thousands of actions at machine speed, each of which needs to be reconstructable from external telemetry rather than process memory.
• The model itself is opaque. You cannot forensically image a commercial AI provider. Provider-opacity is a structural constraint, not a collection failure.
• Human-in-the-loop (HITL) constraints — the mechanisms that are supposed to require human authorization before consequential actions — may have been bypassed, misconfigured, or simply never implemented.
• Legal and executive teams need handoff-ready summaries that clearly distinguish what the AI did from what was done to or through it.

v1.3RC addressed all of this through Appendix B: Applying CIFM to AI-Driven Operational Incidents.

Appendix B extends the UEM with AI-specific evidence fields, walks investigators through a structured GTG-1002 application for AI-orchestrated activity, and establishes a phased workflow that ends at a defensible narrative — one that accounts explicitly for what provider opacity prevents you from asserting. The HITL constraints section is particularly direct: no AI-generated hypothesis enters the investigative record without validation against primary evidence. That constraint is non-negotiable.

v1.3RC established that CIFM could be applied to AI-linked incidents. What it didn't yet address was the telemetry infrastructure those investigations depend on.

v1.4RC: Building the Eyes to See AI Agents

Published: 19 May 2026

Two days after v1.3RC, the next question surfaced: if you're going to reconstruct what an AI agent did, what telemetry sources actually exist to reconstruct it from?

This is where v1.4RC's contribution lives. Section 9.3.2 — Operational Observability and AI-Agent Telemetry — is not an academic taxonomy. It is an investigator's answer to a practical problem: AI agents are active infrastructure components that generate their own evidence signature, and that signature is fragmented, inconsistently logged, and often not treated as forensic material at collection time.

Section 9.3.2 formalizes what AI-agent telemetry looks like in practice: tool invocation logs, execution boundary context, API call sequences, authentication events, and workflow action records. It addresses collector pipelines — the systems that need to be in place before an incident for AI-agent activity to be reconstructable afterward. And it treats timestamp and sequence integrity as first-class concerns, because an AI agent can produce a high-volume action stream where the ordering of events is as evidentiary as the events themselves.

Section 9.3.2 also reinforced a principle that v1.3RC introduced implicitly: if the telemetry wasn't collected, the reconstruction isn't possible. Forensic-by-design — building collection capability into AI infrastructure at deployment time, not after an incident — is not a nice-to-have. For AI-agent environments, it is the prerequisite for any investigation that will hold up.

With v1.3 and v1.4 in place, CIFM could address AI-driven incidents and the telemetry infrastructure to support them. There was still a harder problem waiting.

v1.5RC: The Shadow Environment Problem

Published: June 2026

The AI that v1.3 and v1.4 address is AI that someone provisioned, governed, and — at least in principle — built telemetry for.

That is not most of the AI in your environment.

Most AI in enterprise environments today arrived through individual user decisions: a SaaS tool with an OAuth grant, a browser-based coding assistant connected to a code repository, an automation platform that a developer stood up and then left the organization, an AI integration that appeared in a workflow one sprint and was never formally reviewed. These systems are not in the asset inventory. They may have non-human identities with broad, undocumented scope. Their data flows are invisible to forensic readiness planning. And when something goes wrong — or when an adversary finds them before the organization does — there is nothing to collect from, because no one knew to plan for it.

This is the shadow environment problem, and v1.5RC is CIFM's response.

v1.5RC adds Design Principle 8.8 (Shadow Environment Awareness) and the full Section 9.3.3 family, which addresses five interconnected dimensions of the problem:

Shadow Systems and Shadow IT — the infrastructure that exists outside formal governance review, including AI tool deployments that accumulated as unexamined API connections and data flows.

Shadow AI — specifically: AI integrations that were never provisioned through formal review, deployed through individual user action, and are invisible to telemetry collection planning. The investigative standard is not governance maturity. The standard is investigative visibility. An organization that cannot inventory its AI integrations cannot scope its forensic collection.

Reconstruction Debt — the investigative liability that accrues when ungoverned systems, orphaned automation, shadow AI integrations, and undocumented non-human identities operate without forensic readiness. A scheduled script, API chain, service account, OAuth grant, or AI integration that persists without logging, ownership assignment, access review, or collection planning is a future evidence gap. That gap is not created at incident time. It is created at deployment time, and it compounds.

Non-Human Identity, Ownership Gaps, and Blast Radius Drift — NHI (service accounts, API tokens, OAuth grants, automation credentials) are first-class forensic objects under CIFM. v1.5RC formalizes what happens when NHI ownership is unclear, when scope has drifted since authorization, and when a compromised NHI can propagate across multiple integrated systems. This section — 9.3.3.4 — was specifically cited by external reviewers as flowing correctly within the model.

Investigative Archaeology of Ungoverned Access — Section 9.3.3.5 addresses the practical reconstruction problem: how do you investigate infrastructure that was never documented? The approach draws on surrounding control-plane telemetry, cross-reference of adjacent systems, OAuth grant registries, and identity provider logs to reconstruct the access pattern of a system that left no explicit evidence of its own existence.

v1.5RC also adds a shadow-environment anti-pattern to Section 12 (do not assume that absence of evidence about ungoverned infrastructure is evidence of benign activity) and a corresponding forensic readiness element to Section 13: organizations must maintain a current NHI inventory, an OAuth and API grant registry, and a lightweight intake process for surfacing AI tool integrations before they accumulate as ungoverned attack surface.

The shadow environment framework and archaeological investigative model that informed Section 9.3.3 are attributed to Professor Charlie Niemi of the University of Tulsa. The five investigative questions in Section 9.3.3.5 are adapted from Niemi's 2026 paper, Only the Shadow Knows, and translated into CIFM investigative language with his knowledge and permission.

What the Arc Means

Three revisions in thirty days is not a development sprint. It is a framework tracking a problem in real time.

v1.3RC asked: can CIFM be applied to AI-driven incidents? The answer was yes, with structure.

v1.4RC asked: what does the investigator need to see AI agent activity? The answer was a telemetry and observability discipline that has to be built before the incident, not during it.

v1.5RC asked the hardest question: what about the AI that no one is watching? The answer is that ungoverned AI infrastructure is an investigative liability that compounds from the moment of deployment, and that forensic readiness in modern environments requires treating shadow systems, Shadow AI, and non-human identity as first-class concerns — not edge cases.

The feedback on v1.5RC was notable not because reviewers challenged the framework, but because they began asking how to teach it. Frameworks spend their early life defending their existence. Mature frameworks spend their time figuring out how people will use them. CIFM is at that threshold.

The full framework, including all three revisions, is available at the CIFM GitHub repository. The next planned phase of work will focus on operationalization: practitioner worksheets, a minimum viable training lab, and Forensic-by-Design implementation guidance for organizations beginning to build CIFM capability.

The framework has been pressure-tested. Now we operationalize it.

If the next phase of cybersecurity is going to be defined by AI-assisted infrastructure, then the next phase of forensics must be prepared to reconstruct it.

The full whitepaper can be found on my personal GitHub repository. Comments may be sent to me directly on LinkedIn.