The Attribution Gap: Who's Accountable When AI Agents Handle CUI?

An AI agent processed a controlled document at a defense contractor last week. The agent had no identity on the network. No row in the access matrix. No confidence score on its output. No timestamped approval from the human whose initials sat in the SSP next to that control. The work happened. The artifact moved. Nobody who would later be asked about it could tell you which actor performed the action.

That is the attribution gap. And the standards bodies started naming it in May.

In late May, NSA’s Artificial Intelligence Security Center published security design considerations for the Model Context Protocol, the wiring underneath most agentic AI deployments. Days later, the Cloud Security Alliance ran a piece titled “The Attribution Gap,” arguing that every AI regulation leads back to identity and authorization. Industry analysts publishing through 2026 have framed agentic governance as a distinct discipline from data governance, and ISO 42001 is hardening into an audit regime that AI vendors are starting to take seriously. Standards bodies are codifying the question right now. CMMC, the framework actually governing how CUI gets handled in the Defense Industrial Base, was written before any of these agents existed.

That gap is the problem. It’s not theoretical. It’s already on contractors’ networks.

What the Standards Bodies Said in Late May

The convergence in late May matters because it isn’t one organization with a position. It’s three independent vantage points on agentic AI arriving at the same diagnosis.

CSA’s framing zeroes in on accountability. When a non-human actor takes an action on regulated data, who is the entity of record? The human operator who invoked the agent? The vendor whose model produced the output? The agent itself, which has no legal standing? CSA’s argument, directionally, is that the question hasn’t been answered by any framework that governs sensitive data today. Their piece reads as a flag, not a solution. That’s the right register. Nobody has the solution yet.

NSA’s MCP guidance comes at the same problem from the protocol layer. The Model Context Protocol is how AI agents discover and use tools. It’s also how they cross trust boundaries. NSA’s guidance, in plain reading, treats MCP servers as attack surface and trust delegators that need the same scrutiny as any privileged service account. That framing matters because it implies what most CMMC programs haven’t yet acknowledged. An MCP server reaching into a CUI environment is a privileged user that doesn’t show up in your AC family the way a human user does.

Industry analysts publishing in parallel have been the most operationally specific. The agentic governance work circulating through Q1 and Q2 of 2026 has pushed on identity, lineage, and decision logging as the missing primitives. You can’t govern an agent if you can’t tell which agent did what, on whose behalf, with what authority, to which record. Without those primitives, every other control compensating, monitoring, restricting collapses to vibes.

Three different starting points. One shared finding. The audit ecosystem hasn’t built the vocabulary for the actor that’s already on the network.

How CMMC Frameworks Answer the Question Today

Honestly? They don’t.

CMMC Level 2 inherits NIST 800-171 Rev 2. Rev 3 is in the queue but hasn’t displaced Rev 2 for the assessment population most contractors are sitting in. Both were drafted in a world where the entity touching CUI was a person, a service account configured by a person, or a system component configured by a person. The Access Control family at AC.L2-3.1.x assumes accounts you manage. The Audit and Accountability family at AU.L2-3.3.x assumes events you can trace back to a named human. The Personnel Security family at 3.9.x assumes people you can vet. The whole 110-requirement catalog presumes that the actor touching CUI has an identity that maps back to a human eventually, and that the chain of custody for any sensitive action terminates in a person who can be named in a finding.

An AI agent breaks that assumption in three specific places.

It breaks at IA.L2-3.5.1 (Identification) and IA.L2-3.5.2 (Authentication). The agent typically runs under a service account, an OAuth token, or a vendor-issued credential that wasn’t issued through your internal identity governance process. There’s no LDAP entry. No HR record. No annual review. The agent operates with effective privileges that the access matrix doesn’t see. The control objectives at 3.5.1 (identify users, processes acting on behalf of users, or devices) and 3.5.2 (authenticate those identities) get satisfied in form but not in fact: the identity exists, but it isn’t the identity of the actor that actually performed the action.

It breaks at AU.L2-3.3.1 (System Auditing) and AU.L2-3.3.2 (User Accountability). The events your SIEM captures show “service account X performed operation Y on resource Z.” What the log doesn’t capture is the prompt that drove the action, the model version, the confidence the system had in the output, or the human who authorized the chain. The artifact of the action exists. The decision lineage doesn’t. AU.L2-3.3.2 specifically requires ensuring actions can be uniquely traced to individual users — when the actor is an AI agent operating under a shared service account, that traceability collapses to the account, not the agent.

It breaks at AC.L2-3.1.1 (Authorized Access Control) and AC.L2-3.1.2 (Transaction & Function Control). Most agent deployments inherit the privileges of the human invoking them, or of the service account hosting them. Neither is the agent’s actual scope of action. An assistant scoped to “summarize a document” has the credential scope of “everything that account can read,” which on a contractor network is usually more than the assistant ever needed.

None of these are bugs in CMMC. They are gaps that exist because the framework was authored before the actor existed. The 800-171 Rev 2 catalog has no row for “non-human autonomous actor operating on CUI under delegated authority.” The 800-171A assessment guide doesn’t tell an assessor what evidence to ask for when one shows up. That’s the hole.

The Three Failure Modes

When an AI agent processes CUI without attribution architecture, the failure isn’t always loud. Most of the time it’s quiet, and it doesn’t surface until a C3PAO starts pulling the artifact trail.

The identity vacuum. The agent does work. The work goes into a controlled document or a system that handles CUI. The audit log shows the host account, not the agent. When the assessor asks “who performed this action and what was their authorization,” the answer is a service account name and a shrug. The contractor will struggle to demonstrate that the right authority did the right action, because the agent isn’t a row in their identity governance system. Mapping back to a human is theoretical. The control fails on evidence, not on intent.

The unsupervised approval. The agent generates output. The human “reviews” by clicking accept on a draft. There’s no record of what the human actually examined, no diff against the unedited generation, no confidence threshold above which the system required deeper review. From an assessor’s view, the human-in-the-loop is a checkbox in the policy, not an artifact in the evidence trail. Most contractors don’t realize how thin this is until they’re being asked to produce six months of approval records and they can produce the policy but not the receipts.

The scope creep. An agent given access to summarize one folder ends up with read scope across the share. A code-assistant given access to review one repo can index the whole code base. A document agent given a chat interface acquires the credential scope of every user who chats with it. Each individual permission grant looks reasonable in isolation. The aggregate is an agent operating with broader effective access to CUI than any human user on the network, and nothing in the SSP that says so.

Any one of these is recoverable. All three together, which is the normal state of an AI deployment that wasn’t designed with attribution in mind, produce an audit problem that won’t surface until Phase 2 enforcement bites. By then the cost of remediation is no longer architectural. It’s contractual.

What Identity-Bound AI Actually Looks Like

Standards will catch up. They always do. The question is whether contractors will be aligned to the architecture standards eventually require, or scrambling to retrofit after the assessor pulls the artifact and finds nothing.

What identity-bound AI looks like in practice isn’t mysterious. The shape has been visible for a while in adjacent regulated environments. There are five primitives.

Every agent has an identity. Not a shared service account. A discrete machine identity that maps to a specific deployment, scope, and sponsoring human. The identity is provisioned through the same identity governance that humans are. It shows up in access reviews. It expires.

Scope is enforced, not inherited. The agent’s effective access is the intersection of what the model can request and what the policy layer will release. If the agent asks for something outside scope, it doesn’t get it. The denial is logged. Inheritance-by-default from a host account is rejected design.

Confidence scores ride alongside every output. The model surfaces how certain it is, and the system routes by that signal. High confidence and low-stakes action moves with light-touch review. Low confidence or high-stakes action stops and asks. The threshold isn’t a UX preference. It’s a control objective.

Consequential actions require explicit human authorization. Not a passive accept. A named human, signing in at a known time, having seen what’s being approved, with the rationale captured. The system records that signature alongside the action it authorizes. The decision lineage is the evidence packet.

The audit log captures every step. The prompt, the agent, the model version, the data accessed, the action taken, the confidence, the human who reviewed and approved, the outcome. Not in a debug log nobody can read. In a structured audit record that a C3PAO can verify against the controls it satisfies.

That is what the P5 Human-in-the-Loop Assurance architecture looks like when you build it for compliance, not just for product polish. It’s also the architecture that the standards bodies are converging on this month. CSA is naming the gap. NSA is hardening the protocol layer. Industry analysts and emerging ISO frameworks are publishing the governance primitives. They are independently triangulating on the same answer because there isn’t another one that works.

The Contractor Checklist

For OSCs already running AI tools in CUI-adjacent workflows, the next 90 days are the right window to audit before the assessors get there.

Six questions for any AI vendor asking to be deployed against your CUI boundary.

One. Does the agent operate under a discrete machine identity that maps to a specific deployment and a specific human sponsor? Or does it inherit a shared service account that gives it more effective access than any human user on the network?

Two. Is the agent’s scope of action defined by policy, enforced at the request layer, with denials logged? Or does it inherit the credential scope of whatever host it runs on?

Three. Does the system surface a per-action confidence score, with routing rules based on that score? Or does the model output go straight to acceptance regardless of how confident the system actually was?

Four. Does every consequential action require an explicit, named human authorization captured in an artifact, or is “the user has the feature enabled” treated as standing approval?

Five. Does the audit log include the prompt, the model version, the data accessed, the confidence, the reviewer, and the outcome, structured so a C3PAO can verify it against an objective?

Six. Can the vendor produce a per-action evidence packet on demand for any sample the assessor selects? Without that, the assessor has nothing to validate against.

A vendor that can answer all six gets to the next round of due diligence. A vendor that hedges on more than one is selling a product that hasn’t been built for an environment where someone will eventually ask these questions out loud.

Where This Lands by Phase 2

The next eighteen months will determine whether CMMC accommodates the AI agents already handling CUI in DIB environments or whether contractors will find themselves out of scope of their own boundary because the framework didn’t keep pace.

Our read on this is direct. CMMC will accommodate. The 800-171 Rev 3 cycle, the 800-171A revision cycle, and the inevitable assessor interpretation memos will land somewhere close to what the standards bodies named in May. Identity-bound, scope-enforced, confidence-routed, human-authorized, fully logged. The vocabulary will tighten. The objectives will get specific. The architecture, by the time it’s required, will look a lot like the architecture P5 already describes.

Contractors who deploy AI without that architecture are not in a holding pattern. They are accruing an audit problem. The problem won’t show during Phase 1 because Phase 1 isn’t looking for it. It will show during Phase 2 the first time a C3PAO requests evidence of accountability for an action the system can’t attribute. That contractor’s choice at that point is to retrofit, withdraw, or fail. None of those are cheap.

Deep Fathom’s position on this is that the architecture matters now, not when the framework gets around to writing it down. We built the platform with confidence scores on every AI output, with identity-bound machine actors, with human authorization captured at each consequential step, with decision lineage logged in a form an assessor can read. Not because someone made us. Because the gap was visible, and the standards were going to close on it, and contractors who waited for the closure would be the ones explaining themselves later.

The agent on your boundary doesn’t care whether the framework named it yet. The assessor will.