---
title: "The Missing Layer in the Enterprise Stack"
author: "Morgan Allen"
datePublished: "2026-07-10"
canonical: "https://contextcontinuitylayer.org/articles/the-missing-layer-in-the-enterprise-stack"
---

# The Missing Layer in the Enterprise Stack

## Why AI Governance Needs a Propagation Control Plane

**By Morgan Allen, Context Layer Systems, Inc.**

## Why This Gap Matters Now

Enterprise AI deployment is accelerating faster than the governance infrastructure underneath it. Agentic systems are already delegating tasks, passing context across service boundaries, and writing references to sensitive subjects into downstream stores. The controls enterprises have built so far answer who may access a system. They do not answer what happens after context propagates.

### Key Takeaways

- Identity and SSO establish access. They do not maintain continuity of what contextual references traveled downstream after access was granted.
- A KMS can destroy a key. It cannot tell you which systems received encrypted references tied to a subject, or whether every holder acknowledged revocation.
- Erasure is the payoff. Propagation-aware governance is the infrastructure that makes erasure enforceable rather than aspirational.

The urgency is not theoretical. Only about one-third of organizations have governance maturity adequate for the agents they are already deploying, according to McKinsey's State of AI trust in 2026, which surveyed roughly 500 organizations between December 2025 and January 2026. Deloitte puts the share at 21 percent, from a survey of 3,235 IT and business leaders across 24 countries fielded August to September 2025. Article 50 transparency obligations and GPAI enforcement powers apply from August 2, 2026, with Annex III high-risk obligations following on December 2, 2027 under the Digital Omnibus on AI. The window for intentional architecture is closing, and enterprises that do not design their accountability model will have one designed for them by auditors and regulators instead.

## Where the Enterprise Stack Breaks

Enterprise governance architecture has clear layers at the top and bottom, but a critical gap in between. Identity and SSO sit upstream, establishing authentication, delegated authorization, and session scope. Applications, agents, and downstream processors sit at the bottom, consuming context and acting on it. The layer that should connect them — a propagation registry that tracks where contextual references travel after access is granted — does not exist as a standard enterprise primitive.

Identity systems confirm authorization at the boundary. An SSO token establishes that a user or agent may act. It does not record which downstream services later received a reference to that subject, under which key version, or under which consent state was active at the time of write. Once context crosses the identity boundary, its lifecycle is untracked.

Downstream applications treat revocation and deletion as local concerns. When a deletion request arrives, each system handles it independently: clearing a row, expiring a cache, flagging a record. There is no shared registry that knows the full scope of propagation, so "deletion" becomes a coordination exercise across systems that may not all respond, may not all confirm, and may not all be known to the requesting party.

### The Stack Responsibility Map

| Layer | What it governs | What it does not govern |
| --- | --- | --- |
| Identity / SSO (upstream) | Authentication, delegated access, session scope | Post-access propagation of contextual references |
| Propagation Registry (missing middle) | Where references traveled, key-version lineage, consent state, revocation travel | Application-layer execution logic |
| Applications / Agents (downstream) | Local data handling, task execution | Cross-system revocation coordination, erasure attestation |

The missing middle layer is a propagation registry. Its job is to record at write time which systems, agents, or stores received a reference to a given subject, along with the key version active at that moment, the consent state that authorized the write, and the policy context governing the reference. With that record in place, revocation is no longer a broadcast problem. It becomes a directed, attestable operation across a known set of holders.

> The real risk: Without a propagation registry, enterprises cannot answer the two questions regulators and auditors will ask first — where did this context go, and can you prove it was revoked everywhere it landed?

## OAuth Solved Access. It Never Solved Aftermath.

OAuth and OIDC represent the closest architectural precedent for what a propagation control plane could look like, and the sharpest illustration of where that precedent stops. They standardized delegated authorization at internet scale, giving the industry a shared control plane for a precise question: who may access which resource, under which scopes, for how long. That standardization held together distributed application ecosystems for over a decade and remains the foundation of enterprise identity federation today.

> "OAuth answered who may access. It never answered what happens to what they accessed."

The omission was defensible in a world of discrete application sessions. A user authenticates, an application acts, the session expires. The blast radius of any one access event was bounded. Revocation meant revoking the token. The token's downstream effects were assumed to be contained within the application that held it.

Multi-agent AI systems break that assumption entirely. An agent that receives delegated context may pass a reference to a sub-agent, write a summary to a vector store, cache a subject identifier in a retrieval index, and trigger a downstream workflow, all within a single task execution. The original token may expire while five downstream systems still hold live references to the subject it authorized.

### What OAuth Left Unresolved

1. **Post-access propagation** — Where did the authorized context travel after the initial grant?
2. **Consent lineage** — Was the consent state that authorized the original access still valid when downstream systems received references?
3. **Revocation scope** — When authorization is revoked, which downstream holders need to be notified, and how is acknowledgment verified?
4. **Erasure attestation** — Can the enterprise prove that every system that received a reference has since rendered it inaccessible?

OAuth was not designed to answer any of these questions, and the industry treated that silence as an acceptable gap for over a decade. It is no longer acceptable when the authorized entity is an autonomous agent operating across organizational boundaries at machine speed.

## What the Missing Layer Actually Does

A propagation registry is not a logging system. Logs record what happened. A propagation registry records what was distributed and maintains the state needed to coordinate what happens next. The distinction matters because observability alone does not produce enforceable governance. A log that tells you a reference propagated to twelve systems is useful. A registry that carries revocation state to those twelve systems and tracks acknowledgment is the actual control plane.

### Required Capabilities of a Propagation Registry

1. **Write-time lineage recording** — Every time a contextual subject reference is written to a downstream system, the registry records the recipient, the key version active at write time, the consent state authorizing the write, and the policy context governing the reference.
2. **Traveling revocation state** — Revocation is not a cleanup job triggered after the fact. It is a property that travels with the token or reference, so downstream systems evaluate current authority rather than rely on periodic reconciliation.
3. **Holder awareness** — The registry maintains a current map of which systems hold live references to a given subject, so revocation and erasure workflows can be directed rather than broadcast.
4. **Acknowledgment tracking** — Revocation is not complete until holders confirm. The registry tracks which downstream systems have acknowledged, which have not, and surfaces that state for audit.
5. **Cryptographic erasure coordination** — When a subject reference is retired, the registry coordinates key destruction across the relevant key versions, ensuring that references held downstream become cryptographically inaccessible rather than merely flagged for deletion.

### How Context Flows Through the Registry

| Stage | Event | Registry action |
| --- | --- | --- |
| Write | Agent writes subject reference to downstream store | Records recipient, key version, consent state, timestamp |
| Propagation | Downstream system passes reference to another agent | Extends lineage record to new recipient |
| Revocation | Consent withdrawn or subject deletion requested | Pushes revocation state to all known holders |
| Acknowledgment | Holder confirms revocation or erasure | Registry updates holder status; audit record sealed |
| Attestation | Auditor or regulator requests proof | Registry produces lineage + revocation + acknowledgment log |

The outcome is not merely better visibility into where context traveled. It is designed as a system intended to enforce the claim "this subject reference has been revoked and rendered inaccessible across all holders," and produce a verifiable record to prove it. That is what transforms erasure from a best-effort file operation into an enforceable infrastructure property.

## Why This Is Not a KMS Wrapper

The architecture is designed for a KMS to handle cryptographic erasure through a well-defined mechanism: destroy the key, render any data encrypted under it unrecoverable. NIST defines cryptographic erasure as a purge sanitization technique that works exactly this way, and the mechanism is sound. The problem is not the mechanism. The problem is that key destruction is scoped to the key manager's own authority surface, not to the full population of downstream systems that received references encrypted under that key.

A KMS knows about keys. It does not know about propagation. When a key is destroyed, the KMS has no record of which downstream systems received references encrypted under that key version, which of those systems have since re-encrypted or cached the plaintext, which holders were notified, or whether any of them acknowledged. The destruction event is complete inside the KMS. Its effects on the broader system are entirely unverified.

### KMS vs. Propagation Registry: What Each Actually Governs

| Capability | KMS | Propagation Registry |
| --- | --- | --- |
| Key creation and rotation | Yes | Tracks key version at write time |
| Key destruction / cryptographic erasure | Yes | Coordinates destruction across holders |
| Record of which systems received a reference | No | Core function |
| Consent and policy state at write time | No | Recorded at write time |
| Revocation state propagation to holders | No | Traveling property of the token |
| Holder acknowledgment tracking | No | Required for audit closure |
| Erasure attestation across all recipients | No | Produced as verifiable output |

The key is one primitive inside the control plane, not the control plane itself. A propagation registry uses key-version lineage as one of its recorded dimensions, and it coordinates with the KMS to execute cryptographic erasure when a revocation workflow completes. But it cannot delegate its core function to the KMS, because the KMS has no model of the downstream systems that received context in the first place.

The practical consequence: an enterprise that relies solely on KMS-based erasure can prove that a key was destroyed. It cannot prove that every system holding a reference under that key was identified, notified, and confirmed inaccessible. That gap is exactly what auditors and regulators will probe when enforcement pressure intensifies under the EU AI Act and equivalent frameworks.

## Why Regulators and Auditors Will Force This Question

The regulatory timeline is no longer abstract. The EU AI Act is phasing in obligations across a compressed window, and the enforcement surface it creates maps directly onto the propagation problem.

### Key Regulatory Dates

| Date | Obligation |
| --- | --- |
| February 2, 2025 | Unacceptable-risk AI practices became legally binding |
| August 2, 2025 | Governance obligations for General-Purpose AI models began |
| August 2, 2026 | Article 50 transparency obligations apply from August 2, 2026. GPAI obligations applied from August 2, 2025, with the Commission's enforcement powers over GPAI beginning August 2, 2026. |
| December 2, 2026 | Article 50(2) for legacy systems; new prohibited practices |
| December 2, 2027 | Annex III standalone high-risk AI system obligations (Digital Omnibus on AI) |
| August 2, 2028 | Annex I embedded high-risk AI obligations |

The Act requires enterprises to document how AI systems act on sensitive data, maintain audit trails for high-risk decisions, and demonstrate that human oversight mechanisms are operational. None of those requirements can be satisfied by an architecture that treats deletion and revocation as application-layer coordination tasks.

### Audit-Readiness Checklist

- Can you enumerate every system that received a contextual reference to a given subject?
- Can you produce the key version and consent state active at the time each reference was written?
- Can you show that revocation was pushed to every holder, not broadcast and forgotten?
- Can you demonstrate that each holder acknowledged revocation or erasure?
- Can you produce a verifiable attestation record for the full lifecycle of a subject reference?

> As Deloitte's 2026 enterprise AI research puts it directly: "Organizations that have not explicitly designed their AI accountability model by end-2026 risk having it designed for them via audits, regulators, or visible failures." The propagation registry is not a future-proofing exercise. It is the architectural prerequisite for answering these questions at all.

## What This Means for Enterprise Architecture Decisions Now

The practical question for platform and infrastructure teams is not whether to adopt a propagation registry eventually. It is whether current governance architecture can answer the propagation question at all, and if not, how long that gap can be sustained before it becomes a compliance liability.

The strategic test is straightforward: governance that lives in downstream applications is governance that cannot be coordinated. Every application that handles revocation independently is a system that may handle it differently, partially, or not at all. Elevating revocation and erasure into a shared control plane between identity and execution is not an architectural preference. It is the only design that makes those properties enforceable across the full scope of propagation.

### Decision Framework for AI Governance Architecture

- **Access governance** — Do you know who can access each AI system and under what scopes? If not, start here with identity and IAM.
- **Propagation governance** — Do you know where contextual subject references travel after access is granted? If not, this is the missing layer.
- **Revocation governance** — Does revocation travel with the reference, or does it depend on downstream systems to poll for updates? Polling-based revocation is coordination debt.
- **Erasure attestation** — Can you produce a verifiable record that every holder of a reference has rendered it inaccessible? If not, cryptographic erasure is incomplete as a governance mechanism.
- **Lineage auditability** — Can you reconstruct the full propagation path of a subject reference, including key version and consent state at each write event? If not, audit readiness is not achievable.

Emerging infrastructure efforts, including [Secure, Tokenized, Auditable, Context Continuity with Revocation & Erasure Proof (STACCR™)](/staccr), are beginning to operationalize this control plane. [CCL](/whitepaper) defines the open architectural standard. [STACCR™](/staccr) is the reference implementation of CCL, designed to record propagation lineage, carry revocation state with contextual tokens, and produce cryptographic attestation of erasure across distributed holders. STACCR is pre-GA. That is the missing layer: not a privacy tool, not a KMS wrapper, not an IAM extension, but infrastructure designed to make revocation and erasure enforceable properties of the enterprise stack.

> The bottom line: access control is a solved problem. What propagates after access, and what happens to it when consent changes, is not. The control plane for that question is the next necessary layer in enterprise AI architecture.

The [STACCR™](/staccr) sandbox runs a real AES-256-GCM key destruction sequence in your browser, and walks through the propagation lineage, revocation state, and erasure attestation model the platform is architected to deliver.

## Citation

**[The Missing Layer in the Enterprise Stack](https://contextcontinuitylayer.org/articles/the-missing-layer-in-the-enterprise-stack)**

- Author: Morgan Allen
- Organization: Context Layer Systems, Inc.
- Published: 2026-07-10
- Canonical: https://contextcontinuitylayer.org/articles/the-missing-layer-in-the-enterprise-stack