Enterprise AI governance is supposed to prevent failures. Block sensitive data from reaching the model. Redact personally identifiable information before it enters the context window. Strip anything that looks like it violates a policy. The logic is intuitive: if the model never sees the dangerous content, the dangerous output never happens.

The logic is also wrong.

A growing body of research shows that blanket filtering, syntactic redaction, and coarse-grained governance controls do not simply reduce risk. They reshape the information landscape the model operates on, creating gaps, distortions, and absences that the model then fills with confident, fluent, and often wrong completions. The governance tool becomes the proximate cause of the hallucination.

## The Mechanism: What Happens When You Remove Fragments

Large language models are probabilistic sequence predictors. They generate the next token based on everything in their context window. When a governance layer silently removes fragments from that window, the model has no signal that anything is missing. It does not pause. It does not flag uncertainty. It continues generating text as though the context it sees is complete.

The [DataFilter](https://arxiv.org/html/2510.19207v1) study on prompt-injection defense documented this phenomenon directly. Early versions of the filter deleted suspected injections from the input, and the model responded by hallucinating completions for the missing content rather than faithfully working with what remained. Simple syntactic rules, such as "delete all imperative sentences," removed benign, task-relevant instructions alongside the threats. The filter corrupted the very context the model needed to respond accurately.

This is not an edge case. It is the default behavior. Security taxonomies for LLM agents, including OWASP's GenAI prompt injection guidance, emphasize that controls which silently alter or truncate prompts cause models to produce authoritative yet incorrect outputs. The model treats the altered prompt as ground truth because it has no channel to know data was blocked.

## The Scale of the Problem

The over-filtering problem is not subtle. Amazon's [FalseReject](https://www.amazon.science/blog/falsereject-reducing-overcautiousness-in-llms-through-reasoning-aware-safety-evaluation) study found that state-of-the-art LLMs decline to answer 25 to 50 percent of safe prompts due to over-cautious safety training and filters. These are not borderline cases. They are legitimate, benign requests that the model refuses or mishandles because naïve rules cannot distinguish dangerous content from content that merely resembles it.

Scale that pattern to an enterprise context window assembled from dozens of fragments across multiple systems. A governance tool applies a blanket rule: redact all content mentioning a specific customer name, or block everything below a classification confidence threshold, or strip any fragment that references a regulated data category. Some of those fragments contained the precise information the model needed to answer correctly. The model does not know they existed. It fills the void.

The result is a hallucination that looks more authoritative than a typical confabulation, because it is surrounded by real, unredacted content. The user sees a coherent answer built on genuine fragments, with fabricated material woven seamlessly into the gaps. This is harder to detect than a hallucination produced from a completely empty context, because most of the answer is correct.

## The False Trade-off Between Safety and Accuracy

Research on fairness, privacy, and utility trade-offs in language models consistently finds that generic privacy-enhancing transformations reduce performance on downstream tasks when they do not distinguish sensitive from non-sensitive tokens, or relevant from irrelevant content. One systematic study varied privacy and debiasing techniques and found that improvements along safety dimensions came with measurable drops in language modeling quality and downstream task accuracy.

But the trade-off is not inherent. It is a design failure.

More recent work on parameter-efficient fine-tuning shows that carefully designed methods targeting memorization of specific sensitive tokens can maintain or improve utility while mitigating privacy risk. The [PRvL](https://arxiv.org/abs/2508.05545) study on LLM-based redaction evaluated different strategies and found that methods reasoning about underlying semantics preserved more task-relevant content at similar or better privacy levels than naïve masking. The trade-off disappears when the filtering is context-aware.

[LogSieve](https://arxiv.org/html/2601.20148v1), a task-aware log reduction system, demonstrated that semantics-preserving filtering maintained average cosine similarity of 0.93 and GPTScore of 0.93 compared to full, unfiltered context. [Entropic Context Shaping](https://arxiv.org/abs/2601.11585) achieved a 71.83 percent relative improvement in F1 score over TF-IDF-based filtering by selecting context turns based on their measured information-theoretic utility rather than surface-level keyword matching. Both systems show the same conclusion: meaning-aware filtering preserves answer quality in ways that naïve filtering cannot.

<br>

<div align="center">
<img src="BlogImagesWhenGovCausesHallucinations_Filtering.png" alt="Filtering Precision vs. Answer Quality" />
<br><br>
<em>The safety vs. accuracy trade-off is a design failure. Context-aware filtering equals or outperforms while preserving quality.</em>
<br><br>
<table style="border-collapse: collapse; font-size: 0.9em;">
  <thead>
    <tr>
      <th style="text-align: left; padding: 6px 12px; border-bottom: 2px solid #ccc;">Source</th>
      <th style="text-align: left; padding: 6px 12px; border-bottom: 2px solid #ccc;">Finding</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td style="padding: 6px 12px; color: green;">&#9679; <a href="https://arxiv.org/html/2601.20148v1"><strong>LogSieve</strong> (2026)</a></td>
      <td style="padding: 6px 12px;">Cosine similarity 0.93, GPTScore 0.93 vs full context</td>
    </tr>
    <tr>
      <td style="padding: 6px 12px; color: green;">&#9679; <a href="https://arxiv.org/abs/2508.05545"><strong>PRvL</strong> (2025)</a></td>
      <td style="padding: 6px 12px;">Semantic redaction preserved more task-relevant content at equal privacy levels</td>
    </tr>
    <tr>
      <td style="padding: 6px 12px; color: green;">&#9679; <a href="https://arxiv.org/abs/2601.11585"><strong>Entropic Context Shaping</strong> (2025)</a></td>
      <td style="padding: 6px 12px;">71.83% F1 improvement over TF-IDF-based filtering</td>
    </tr>
    <tr>
      <td style="padding: 6px 12px; color: green;">&#9679; <a href="https://arxiv.org/html/2510.19418v1"><strong>ML Fine-Grained Access Control</strong> (2025)</a></td>
      <td style="padding: 6px 12px;">Selective protection of sensitive regions, non-sensitive content intact</td>
    </tr>
    <tr>
      <td style="padding: 6px 12px; color: red;">&#9679; <a href="https://arxiv.org/html/2510.19207v1"><strong>DataFilter</strong> (2025)</a></td>
      <td style="padding: 6px 12px;">Naive deletion caused hallucinated completions and dropped task-relevant content</td>
    </tr>
    <tr>
      <td style="padding: 6px 12px; color: red;">&#9679; <a href="https://www.amazon.science/blog/falsereject-reducing-overcautiousness-in-llms-through-reasoning-aware-safety-evaluation"><strong>Amazon FalseReject</strong> (2024)</a></td>
      <td style="padding: 6px 12px;">25-50% of safe prompts declined by over-cautious filters</td>
    </tr>
  </tbody>
</table>
</div>

<br>

## The Compounding Problem: Authorized Junk

Over-blocking is only half of the failure mode. The other half is under-blocking.

Coarse governance rules evaluate fragments on a single dimension: is this user authorized to see this content? A fragment that passes the authorization check enters the context window regardless of whether it is relevant, current, or useful. This creates what amounts to authorized noise: content that is permissioned but meaningless for the task at hand.

An AI system filling its context window with authorized but irrelevant fragments produces worse answers than a system with a smaller, curated context. Boilerplate paragraphs, outdated templates, duplicated content from fourteen different sources, compliance language copied across hundreds of documents. All of it authorized. None of it helpful. All of it competing for the model's attention with the fragments that actually matter.

The [ML-Assisted Fine-Grained Access Control](https://arxiv.org/html/2510.19418v1) research makes this point from the opposite direction. By implementing selective protection of sensitive regions rather than blanket redaction, and by using surrounding context to distinguish a generic date from a birthdate or a common name from a customer identifier, the system keeps non-sensitive content intact and usable. The contrast with naïve file-level or blanket redaction is stark: semantic-aware protection preserves the information the model needs while restricting only what genuinely requires restriction.

## The Cure Creates the Disease

The pattern is consistent across the research. Governance tools designed to make AI safer instead create two simultaneous failure modes:

**Over-blocking removes fragments the model needs.** The model fills the gaps with hallucinated content that looks credible because it sits alongside real data. Users cannot tell which parts of the answer are grounded and which are fabricated, because the governance layer did its work invisibly.

**Under-blocking admits fragments the model does not need.** Authorized junk dilutes the context window, pushing the model's attention toward irrelevant content and away from the fragments that would have produced a correct answer.

Both failures stem from the same root cause: governance rules that operate at the wrong level of granularity. Document-level blocking, pattern-based redaction, and binary allow-or-deny decisions cannot handle a context window assembled from fragments that each require different treatment. One fragment in a context window may be sensitive, stale, and irrelevant. The fragment next to it may be current, authoritative, and essential. A blanket rule treats them identically.

<br>

<div align="center">
<img src="BlogImagesWhenGovCausesHallucinations_2Modes.png" alt="Two Failure Modes of Coarse Governance" />
<br><br>
<em>Over-blocking and under-blocking are not opposites. They are simultaneous outputs of the same coarse governance rule, and both increase risk.</em>
</div>

<br>

## What Precision Control Requires

The alternative is governance that operates at the fragment level, evaluating each piece of content on multiple dimensions before it enters the context window.

Is this fragment current, or has the source been superseded? Where did it originate, and is that source authoritative for this question? Is this user authorized to see this content for this specific purpose? Does this fragment conflict with other fragments already in the context window? And critically: is this fragment relevant enough to earn its place in a finite context window, or is it authorized noise?

These are not questions a blanket filter can answer. They require identity at the content level, not the document level. They require lineage that tracks fragments across systems, not access control lists that operate on file paths. They require continuous evaluation, because the answer to "is this current?" changes every time the source updates.

The research is clear that this is achievable. Context-aware filtering preserves utility. Semantic-aware redaction maintains privacy without destroying meaning. The technology exists to build governance that makes AI both safer and more accurate, rather than forcing a false choice between the two.

The question is whether enterprise governance architectures will evolve to operate at the level where AI actually works, or whether they will continue applying document-era rules to a fragment-era problem, creating the very failures they were designed to prevent.

Naïve AI guardrails don't just fail to prevent bad outputs. They actively create the conditions for worse ones.

When Your Governance Tool Causes the Hallucination

If you've spent any time building RAG pipelines, deploying agents, or scaling AI beyond a proof of concept, you've heard the mantra: garbage in, garbage out. It's true as far as it goes. But it doesn't go far enough, and the gap between that truism and production reality is where most enterprise AI projects stall or fail.

The deeper problems lie in how data becomes context, that is, how fragments of data are retrieved, assembled, and presented to a model at inference time. The industry is converging on terms like "context engineering," but the conversations are riddled with assumptions that were reasonable for BI dashboards and SQL queries, and are flatly wrong for retrieval augmented generation and agentic workflows.

Here are ten of the most persistent misconceptions we've been running into.

## 1. "Clean data in, clean answers out."  🛀🏻

Traditional data quality, including deduplication, schema validation, or freshness monitoring at the source, is necessary but not sufficient. A chunk of text can originate from a perfectly maintained system of record and still produce a wrong answer because it was retrieved out of temporal context, combined with a conflicting fragment from another source, or served to a user who shouldn't see it for a given purpose. The failure mode isn't dirty data. It's clean data assembled into dirty context.

## 2. "The source of a chunk holds the ground truth."  📜

Lineage is valuable, but knowing the proximate source of a chunk — the document or table it was ingested from — doesn't tell you much when the same content exists in dozens of places. Enterprise data is duplicated at staggering rates from copying, pasting, and oversharing; studies consistently show over 95% duplication at the chunk level across large document stores. Your "source" is likely just one of many copies, and the one you indexed may not be the authoritative version. Tracing a chunk to a single document gives you a breadcrumb, not the truth. Ground truth requires understanding which copy is canonical and whether the canonical version has changed since ingestion.

## 3. "A document label applies to every chunk in that document."  🏷️

A classifier operating on a full document sees headings, structure, surrounding paragraphs, and metadata. A classifier operating on a chunk sees a few sentences stripped of all of that. Sensitivity labels, topic categories, and compliance tags that are accurate for a full document frequently become wrong or meaningless when applied to the individual fragments a RAG system retrieves. If your governance depends on labels assigned at the document level, it's operating on a different unit of analysis than your AI system.

## 4. "The meaning of a chunk lives inside the chunk."  🌴

The vast majority of chunks are not capable of identifying themselves. A sentence like "the policy covers preexisting conditions after a 12 month waiting period" could come from a current benefits guide, a superseded version, an email summarizing a proposal that was never adopted, or a competitor analysis. Which business context applies, whether the statement is current and authoritative, in short its _meaning_, exists in the relationships surrounding that chunk, not in the bytes that comprise it. Only a small fraction of enterprise data carries enough internal markers to identify themselves without external context.

![](/images/blog/Content_Context_Overlap.png)

## 5. "Context metadata travels with the data."  🚂

It almost never does. Which user or tenant the data belongs to, what project it relates to, what classification or handling rules apply — this information typically lives in external databases, identity systems, or systems of record that are architecturally separate from the storage and retrieval infrastructure. When a chunk moves from a document store into a vector database, or from one agent's context window into another's, the metadata that gives it meaning is usually left behind. The chunk arrives naked.

## 6. "The most commonly used data is the most important"  🍀

Legal disclaimers, standard headers, template language, and boilerplate are one of the most common sources of noise in RAG systems. But you cannot identify them by examining a single document, because boilerplate looks identical to meaningful content in isolation. Its defining characteristic is that it appears identically across many documents. Detecting it requires analysis across documents: comparing chunks across the corpus to find the ones that repeat without variation. Without that corpus level view, your retrieval pipeline treats template language with the same weight as substantive content. Consider standard indemnification clauses in a multi-tenant SaaS platform: every customer's contract contains the same boilerplate terms. You can't decide that Tenant A shouldn't see a clause just because it also appears in Tenant B's contract, but you also can't treat it as uniquely meaningful to either.

## 7. "RAG chunks maintain clean source boundaries."  🧱

Chunking algorithms split text on token counts, sentence boundaries, or semantic similarity, none of which respect document boundaries. When documents from multiple sources are ingested into the same index, chunks that straddle or interleave content from different origins are common. A single chunk might contain a sentence from a regulatory filing and a sentence from an internal summary of that filing, with no marker indicating where one ends and the other begins. Boundary contamination is the norm, not the exception. And the problem compounds: a single chunk can blend multiple sources, while a single retrieval result set assembles chunks from many sources. Provenance must be tracked at both levels, per chunk and per response, and today, most systems track neither.

## 8. "Access control follows the data."  🎛️

In most enterprise architectures, access control policies are tied to the APIs and applications that serve the data, not to the data itself. When a user queries an application, the application enforces permissions. But when an AI agent retrieves fragments from a vector store populated by a batch ingestion pipeline with its own service account, the original access policies are nowhere in the retrieval path. The data has moved; the policy stayed behind. This is why "the RAG respects our ACLs" is almost always aspirational rather than factual.

## 9. "Relevance means the content matches the question."  ⚠️

Semantic similarity measures whether a chunk's content is topically related to a query. But relevance for a user's actual decision can lie entirely outside the content. Consider a feature that existed in version 1 of a product and was removed in version 2. A user asking "does the product support X?" needs to know about the absence of that feature, but there's no chunk in the V2 documentation that says "X was removed." The relevant information is a contextual relationship that doesn't exist as retrievable content. Relevance, in practice, is often about what's missing, what changed, or what was superseded — none of which vector similarity can detect. This is why standard retrieval metrics like recall@k and MRR, which measure whether the "right" chunk appeared in the top results, systematically overstate retrieval quality in production: they score against content that exists, not content that should exist but doesn't.

## 10. "You can define all the context you need in advance."  ⏱️

This is a natural assumption for anyone who has built data pipelines: if we just tag everything correctly at ingestion time, the right context will be available at query time. But you often cannot know which contextual attributes matter until you see the question. A user asking about a product feature needs version history. A user asking about a compliance obligation needs jurisdictional scope. A user asking about a customer needs entitlement status. And when new regulations take effect (as they regularly do) previously ingested data may need contextual dimensions that didn't exist in the schema when it was tagged. The context that makes a chunk trustworthy depends on the question, and no static metadata schema can anticipate every dimension of trust that a live query will require.

***

## What These Misconceptions Have in Common

Every one of these misconceptions stems from the same root cause: treating AI's relationship with data as if it were the same as a human's or a traditional application's. Humans read documents from beginning to end and bring institutional knowledge. SQL queries hit known schemas with predictable joins. AI systems do neither. They assemble transient context from data fragments (sentences, charts, byte sequences, etc.) at runtime in response to open ended inputs, and they do it without the judgment or background knowledge that made the old assumptions safe.

Solving this requires a new layer of infrastructure because governance frameworks define policy but can't enforce it at retrieval time, and security tools control access to resources but can't track what happens to the data inside them once an AI fragments and recombines it. What some are beginning to call AI data control operates at the fragment level, at inference time, with awareness of freshness, provenance, authorization, and conflict between sources. 

Better prompts can't fix this because prompts operate on whatever context the retrieval pipeline already assembled and they can't evaluate what they never saw. Smarter rerankers can't fix it because they optimize for semantic relevance, not for whether the content is current, authorized, or in conflict with another source. It's an architectural gap that sits between existing data governance frameworks and the AI systems that consume their data.

The organizations that close this gap first won't just have more reliable AI. They'll have AI they can actually trust in production.

Most of what makes a chunk trustworthy lives outside the chunk. Here's why.

Ten Misconceptions About Context in AI Systems

Context graphs are emerging as a foundational layer for enterprise AI. They promise something enterprises desperately need: traceability, governance, and confidence as AI systems reason over increasingly complex and distributed data environments.

The vision is compelling. Context graphs can capture the relationships between data, decisions, and outcomes providing the explanatory backbone that makes AI systems trustworthy and auditable.

But as enterprises begin building context graphs in practice, a critical architectural question emerges: **How should context graphs model the difference between how data exists and how data is used?**

This question matters more than it might first appear. The answer determines whether context graphs become true governance infrastructure or remain sophisticated logging systems.

## The Challenge: Data Existence and Data Use Follow Different Rhythms

Enterprise data does not behave uniformly. This is not an AI-specific observation, it is an inevitable property of how information is stored, evolves, moves, and is acted upon.

Consider what happens to a compliance policy document in a typical enterprise:

- It is created, versioned, and stored in a document management system
- It is copied into a data warehouse for analytics
- Portions are extracted and embedded into a vector database
- Those embeddings are retrieved during an AI agent's reasoning process
- The agent synthesizes a response that cites the policy

At each stage, the document's *existence* and its *use* follow different rhythms. The document might sit unchanged for months (existence), then be accessed dozens of times in a single day (use). A new version might be published (existence), but cached embeddings still reflect the old version during retrieval (use).

**Context graphs must capture both dimensions to support AI governance.**

This leads to a fundamental distinction that should shape how context graphs are architected:

- **Static context** describes how data exists at rest over time
- **Dynamic context** describes how data is accessed, moved, and used

These are not competing models. They are complementary dimensions that must be reconciled for context graphs to fulfill their promise.

![Figure 1](/images/blog/EnterpriseDataLifecycleArchitecture_Figure1_small.png "Figure 1")
Figure 1: Static and dynamic context connect data as it's recorded to how it's used.

## Static Context: How Data Exists

Static context tracks data as it exists across enterprise systems over time.

This includes databases, data warehouses, object stores, documents, tickets, reports, and configuration files. Static context evolves through:

- Versioning and updates
- Ownership and stewardship changes
- Retention policy applications
- Classification and tagging updates
- Schema evolution
- Duplication and synchronization across systems

Static context answers questions like:

- What was the authoritative version of this data at a given point in time?
- Who owned it then?
- What policies were bound to it while it was stored?
- How many copies exist, and where?

Static context is essential for understanding data lineage and establishing authoritative sources. But it is incomplete on its own.

## Dynamic Context: How Data Is Used

Dynamic context tracks how data is accessed, transformed, and used in real time.

This includes API calls, database queries, file exports, data joins, embedding generation, retrieval operations, prompt construction, tool invocations, and agent execution traces. Dynamic context is shaped by:

- Identity and authorization at access time
- Purpose and intent declarations
- Routing and orchestration decisions
- Filtering, ranking, and selection logic
- Transformation and aggregation operations
- Redaction and policy enforcement

Dynamic context answers questions like:

- Who accessed the data and for what declared purpose?
- What transformations occurred between storage and use?
- Which specific content was selected, merged, or excluded?
- How did the AI system construct its reasoning from source materials?

Dynamic context captures decision *construction*, not just decision *outcome*.

## Why Both Dimensions Matter for Governance

The most important governance questions live at the boundary between static and dynamic context.

Consider these scenarios:

**Stale data in use**: A policy document was updated last week (static context), but the vector embeddings used by an AI agent still reflect the previous version (dynamic context). The agent's response cites outdated guidance. This is meaning drift in action: the bytes haven't changed, but the world has, and the fragment's significance has shifted without any signal reaching the retrieval layer.

**Scope drift**: Data was collected and stored for one purpose (static context), but is now being used in a different context, perhaps by an AI agent serving a different business unit (dynamic context).

**Duplication without propagation**: A correction was made to the authoritative source (static context), but derivative copies in downstream systems were never updated, and those copies are what the AI system retrieves (dynamic context). Semantic drift compounds here: the corrected version and the stale version are no longer equivalent, but the retrieval system treats them as if they are.

**Permission changes**: A user's access was revoked (static context), but cached or copied data remains accessible through indirect paths (dynamic context).

In each case, examining either dimension in isolation would miss the governance violation. Static context shows compliant data; dynamic context shows compliant access patterns. Only by reconciling both can the system detect that the *relationship* between them has broken down.

**Context graphs that collapse these dimensions into a single snapshot cannot answer the questions enterprises actually need to ask.** When the world changes, governance must change with it, and only a graph that models both dimensions can keep pace.

## From Explanation to Control

This framing of static and dynamic context parallels [Animesh Koratana's](https://www.linkedin.com/pulse/how-build-context-graph-animesh-koratana-6abve/) recent distinction between a "state clock" and an "event clock" in his writing on context graphs, a signal that the industry is converging on this architectural requirement.

When context graphs model both dimensions, they unlock capabilities beyond explanation:

- **Real-time policy enforcement**: Detect and prevent governance violations as data is used, not after harm occurs
- **Accurate audit trails**: Reconstruct not just what happened, but *how* decisions were constructed from source materials
- **Adaptive controls**: Respond to changes in either dimension without relying on brittle assumptions
- **Drift detection**: Identify when the relationship between authoritative sources and operational copies has diverged, catching semantic drift before it reaches a user

This is the difference between a context graph that *explains* decisions and one that *makes* them.

## Caber's Approach: Fragment-Level Identity Across Both Dimensions

Caber was designed around this dual-dimension reality from the start.

The key architectural insight is that **reconciling static and dynamic context requires a common unit of identity that persists across both dimensions**.

Traditional approaches track data at the file, record, or document level. But AI systems don't consume documents, they consume *fragments*. A paragraph from a policy. A row from a database. A chunk retrieved from a vector store. A snippet included in a prompt.

Caber assigns deterministic identity at the fragment level, content as small as a sentence or a database row. These fragments become the **building blocks** that connect data across all three states:

- **At rest**: Caber tracks which fragments exist in which systems, their versions, ownership, and policy bindings (static context)
- **In motion**: Caber observes fragments as they move between systems, copied, transformed, embedded, cached (bridging static to dynamic context)
- **In use**: Caber captures which specific fragments are retrieved, selected, and synthesized during AI operations (dynamic context)

Because the same fragment identity persists across all three states, Caber can deterministically answer:

- **Who** accessed which data
- **What** specific content and versions were involved
- **Why** particular fragments were selected over alternatives
- **When** context changed due to movement or transformation
- **Where** data originated and how it propagated
- **How** the decision was constructed, step by step

This is not probabilistic reconstruction or post-hoc inference. It is deterministic capture at the level AI systems actually operate.

## Conclusion

Context graphs represent a genuine architectural advance for enterprise AI governance. They offer the potential to make AI systems explainable, auditable, and controllable in ways that traditional logging and monitoring cannot achieve.

But realizing this potential requires acknowledging a fundamental truth: **data existence and data use are different dimensions that must both be modeled**.

Static context captures how data lives across enterprise systems. Dynamic context captures how that data is accessed and transformed in practice. Governance questions, the ones that actually matter, live at the intersection of these dimensions. And because meaning drifts over time, because the relationship between a fragment and the world it describes can change without the bytes themselves changing, governance that only examines one dimension at one point in time will always be incomplete.

By modeling static context and dynamic context explicitly, and by binding them through persistent fragment-level identity, context graphs can support AI governance: not just explaining what happened, but controlling what happens next.

When context integrity is preserved across both dimensions, enterprises gain what they have been missing: visibility, control, and confidence in how AI decisions are constructed.

---

*Caber provides fragment-level data identity for AI governance, tracking and controlling data at the sentence and chunk level across all states.*


Why AI governance breaks without binding static and dynamic context across how decisions are built

Context Graphs for Governance

Retrieval Augmented Generation (RAG) has become essential for enterprise AI applications to make proprietary data available for responding to user queries. Optimizing RAG's accuracy and precision ensures relevant application responses while maintaining data security and privacy. However, these objectives often conflict. Current methods for enforcing permissions on RAG vector databases can degrade results or leak data to unauthorized users due to the need to divide enterprise data into chunks for GenAI applications.

## AI's Chunked View of Data
Businesses typically handle data as files, documents, videos, or database tables, units of information we can name, organize, and manage. Metadata, such as creation time, size, creator, and applicable policies, links to these data units when stored.
However, GenAI applications don't view data this way. They break down large, complex sources into smaller, semantically meaningful segments or chunks. LLMs train on chunks, vector databases store vectors created from chunks, AI applications consume data in chunks, and APIs called by AI agents move data in chunks.

<div class="w-3/4 mx-auto py-4" align="center">
    <img src="/images/blog/rag_permissions_0.png" alt="Same data chunks in different Apple 10Q statements" onclick="window.open(this.src, '_blank');">
</div>
<p class="caption" align="center">
    Common paragraphs or chunks (blue) and unique chunks (orange) mixed in two Apple 10Q statements. Denying access to all chunks from the Q2 2024 statement in a vector database would also deny users access to much of the data in the Q2 2023 statement as well.
</p>

It seems intuitive that document-level attributes should apply to their chunks. Many AI vendors reinforce this idea. However, this assumption is fundamentally flawed and can lead to inaccurate AI responses, biased results, and compromised data security.

## Data Redundancy from Chunking
Through our experience with <a href="https://www.f5.com/pdf/products/big-ip-wan-optimization-manager-ds.pdf" target="_blank" rel="noopener noreferrer">WAN optimization</a>, over 90% of data chunks flowing through enterprise networks are redundant. In storage systems holding enterprise data, 50%-90% of <a href="https://www.snia.org/sites/default/files/Understanding_Data_Deduplication_Ratios-20080718.pdf" target="_blank" rel="noopener noreferrer">storage blocks are duplicates</a> .

As documents are shared, edited, and converted across platforms, identical paragraphs or images often appear in multiple versions. These redundancies accumulate as authors merge comments from various drafts, circulate files, and manage revisions.

<div class="w-3/4 mx-auto py-4" align="center">
      <img src="/images/blog/rag_permissions_1.png" alt="Duplicate data biases AI" onclick="window.open(this.src, '_blank');">
</div>
<p class="caption" align="center">
      <span>AI researchers at Google and University of Pennsylvania recorded the number of duplicate chunks seen across 348 million web documents. The number of chunks appearing only once have Group Size = 1. Eighty-five thousand chunks appeared 6-10 times. The length of chunks are not represented in this graph. Source: <a href="https://arxiv.org/abs/2107.06499" target="_blank" rel="noopener noreferrer">https://arxiv.org/abs/2107.06499</a></span>
</p>

## Unintended Consequences
When enterprise documents are ingested into an LLM training set or RAG vector database, identical chunks are stored only once. Identical binary sequences generate identical vectors, which vector databases use for data lookup.

However, metadata can differ significantly between documents containing the same chunks. When two such documents are ingested, the first chunk gets metadata from the first document, which the second ingestion overwrites with the second document's metadata. This can lead to problems including poor AI performance, data leakage, and biases in responses.

In multi-tenant environments, this metadata overwrite problem is especially dangerous. A multi-tenant AI system that shares retrieval infrastructure across customers may use one customer's data to answer another customer's question, not because of a failure in architectural isolation at the storage layer, but because at inference time, fragments are recombined from shared retrieval paths. Tenant boundaries that hold at the index or namespace level break down when identical chunks from different tenants collapse into a single vector with a single set of metadata. The breach surfaces through intermediaries, not logs, making it difficult to detect or audit.

<div class="w-3/4 mx-auto py-4" align="center">
    <img src="/images/blog/rag_permissions_2.png" alt="Graph of data chunk relationships across Apple 10Q statements" onclick="window.open(this.src, '_blank');">
</div>
<p class="caption" align="center">
    Using content-defined chunking, data in seven Apple 10Q statements (pink and blue dots) common sets of chunks (in red) can be mapped to the statements they are found in. Pink dots represent the entirety of data in each statement as would be seen by data governance systems that do not take chunking into account.
</p>

### Poor AI Performance and Data Leakage
Consider a document with metadata allowing public access and another with metadata restricting access to Amy. If a common chunk exists in both, the second document's restrictive permissions might overwrite the first's open-access metadata. Bob, who should access the first document, might be denied access, while Amy could see both documents' data.

This issue, if unchecked, diminishes RAG search precision despite improvements from graph-based RAG, cascading retrieval, and other methods. Without a monitoring system, users might receive incomplete responses or unintentionally access sensitive data like coworker salaries.

### Ethical Issues and Biases
As chunk sizes increase, sub-sequences within chunks become a concern. Paragraph-length chunks may contain common sentences appearing in multiple chunks. Research from <a href="https://arxiv.org/abs/2107.06499" target="_blank" rel="noopener noreferrer">Google and University of Pennsylvania</a> shows duplicate data in LLM training sets can introduce biases and errors in responses. Repetition in prompts has been shown to <a href="https://shelf.io/blog/10-ways-duplicate-content-can-cause-errors-in-rag-systems" target="_blank" rel="noopener noreferrer">cause errors</a> in RAG systems.

Where limits exist on the number of chunks retrieved from RAG, a user query with a high similarity score to chunks containing the same sentence, may preclude other chunks relevant to the query to be dropped thus reducing response accuracy.

### Lineage That Traces One Copy Is Fiction

The duplication problem has a direct consequence for data lineage. When the same chunk appears across fourteen documents, any lineage system that traces that chunk to a single source is telling you one thread of a story with fourteen chapters. Traditional lineage tools were built for a world where data moved in whole documents from one system to another. In that world, tracking a document's path from creation to storage to use was feasible. But when AI systems decompose documents into chunks, and those chunks exist in dozens of places with different metadata, ownership, and policy bindings, single-source lineage becomes fiction. It gives the appearance of traceability while hiding the full picture of where a fragment has been and what policies should govern it.

Honest lineage requires knowing every location a chunk appears, every set of metadata it carries, and every conflict between those metadata sets. Without that complete view, governance decisions are based on an incomplete record, and the confidence they project is unearned.

## Conclusion
The rise of agentic AI, where autonomous AI agents collaborate and take intertwined actions, adds new layers of complexity to enterprise AI systems. These agents depend on dynamically retrieved and processed data, making robust data governance essential. As agents interact, risks like data mismanagement, bias, and leakage increase, elevating data governance from a best practice to a critical necessity.

Traditional data governance systems designed for documents, files, and tables (data at rest) are incompatible with how AI processes data. GenAI applications break data into "chunks," stripping away context and metadata needed for effective policy enforcement. To control enterprise data use in these complex AI ecosystems, governance must operate at the chunk level, addressing the unique challenges of fragmented, duplicated, and recombined data.

This means every fragment entering an AI context window must be evaluated against four questions before inference occurs:

1. **Is it current?** Has the source been superseded, updated, or retracted since this chunk was embedded?
2. **What is its provenance?** Where did this chunk originate, where else does it appear, and which source is authoritative?
3. **Is it authorized?** Does the requesting user have permission to access this specific fragment, given the union of all its metadata across every location it appears?
4. **Does it conflict?** Do the metadata, policies, or classifications from different sources of this chunk contradict each other, and if so, how should that conflict be resolved?

Without answering these four questions at the chunk level, enterprises face degraded AI precision, reduced reliability, and potential data breaches, risks amplified by agentic AI's interconnected nature and by the tenant isolation failures that duplication-driven metadata overwrites create in multi-tenant deployments.


Duplication of data across documents causes unseen biases in Retrieval Augmented Generation

How Duplicate Data Kills Your RAG

*This is Part 3 of a series on MCP security. [Part 1: AI Velocity Nobody Can Secure](https://caber.com/blog/2b38f4f3-f657-4441-abac-a9fdbd668b30) examines why MCP adoption is outpacing every governance framework built to contain it. [Part 2: Old Vulnerabilities are New Again](https://caber.com/blog/554b9fd9-08cf-42e8-b51f-c8f44b52f4fc) shows why the same vulnerabilities that plagued APIs are recurring in MCP at compressed timelines.*

---

Enterprises still govern access as if endpoints and servers define risk. Now agent and MCP firewalls have just joined the security stack, adding yet another layer to the long progression of resource level controls.
In the API era it was safe to assume an application's URL or method could be linked to the data it returned. But in the world of MCP and AI agents, *data*, not resources or code, define the unit of agent action. There is no correlation between the endpoint and the data it returns.

Access control that stops at the endpoint is now an illusion of safety. The real challenge is not stopping access to resources, it is understanding and controlling how data is *used*.

---

## How We Got Here and What History Teaches

Security has always evolved by wrapping controls around whatever layer exposed risk. Each new era brought its own perimeter: networks, applications, APIs, and now AI agents.

<div align="center">
  <img src="/images/blog/chart_labelled_legend.png" alt="Timeline of resource centric controls over time" width="80%">
  <small><em>Figure 1  A quarter century of resource centric controls culminating in Agent and MCP firewalls</em></small>
</div>

At first glance the trend looks like steady progress. In reality it is a warning. Every new type of firewall or gateway has required its own unique set of rules written in its own syntax and applied within its own context.

To protect how data is used, security teams have to translate business and compliance requirements into separate rule sets for every layer in the stack. Each layer interprets those rules differently. One looks at IP addresses, another at URLs, another at roles or tokens.
No two layers ever agree on what a rule truly means.

The result is a rule explosion and an impossible maintenance problem. Policies drift out of alignment and enforcement becomes inconsistent. The number of rules that must be written, reviewed, and reconciled grows faster than the number of controls meant to keep things safe.

Adding Agent or MCP firewalls does not solve this. They extend the same resource centric model that created the problem in the first place. They may block requests, but they do not control how the data those requests use is combined, shared, or reused.

---

## Why Resource Based Authorization Fails in AI Ecosystems

Traditional security assumes:
1. Resources are static
2. Access equals intent
3. Policy boundaries are knowable

In MCP systems, none of these are true.

<div align="center">
<table style="font-size: small; margin-left: 5pt; margin-right: 5pt;">
<thead>
<tr style="background-color: #f0f0f0;">
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Old Assumption</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">AI Reality</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Implication</th>
</tr>
</thead>
<tbody>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;"><strong>Static resources</strong></td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Dynamic tool composition</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Endpoints change at runtime</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;"><strong>Access = intent</strong></td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Agents act autonomously</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Intent is inferred, not declared</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;"><strong>Known boundaries</strong></td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Context recombines continuously</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Policies must adapt in real time</td>
</tr>
</tbody>
</table>
</div>

An MCP server may expose hundreds of tools, each able to reach into data stores in unpredictable ways.
Authorizing which tool is used tells us nothing about what data it touches, where it came from, or why it was requested.

When MCP calls carry only an agent's credentials, policy engines lose sight of the human behind the request.
Rules written for users or roles no longer apply, because the system cannot distinguish who the data is truly serving.

---

## Data Entanglement: The New Security Surface

In traditional systems, data could be neatly contained within application boundaries. Now, the same content is duplicated, embedded, and remixed across files, APIs, and vector databases.

Without a persistent way to identify what the data is and what it relates to, resource level control becomes meaningless. The same paragraph may appear in five systems, each with different owners, rules, and retention requirements. When one copy is restricted, others remain exposed.

---

## The Governance Vacuum This Creates

APIs once governed through endpoint scope, allowing or denying access to paths such as /finance or /hr. MCP cannot. A single call like summarize_customer_revenue() may blend data from finance, CRM, and analytics in one step. To existing security systems, that looks fine, but it may combine regulated financial data with public information in violation of policy.

When policies cannot follow the data, governance collapses into guesswork.

In agentic systems, no single application owns the data flow. Permissions must come from the data itself, from the relationships that define what it represents, where it originated, and how it connects to other information. Only by understanding these relationships can the system decide whether combining or sharing the data is allowed.

---

## What Data Use Control Actually Means

Controlling data use is not simply a finer grained resource policy, to stop bad things from happening. Instead of asking who can call this endpoint, the question becomes is this the best data the user is authorized to access. Answering that requires knowing the relationships each piece of data has to the systems, users, and policies around it.

When rules are tied to data relationships, they adapt naturally to how the data is used. Policies can be as much about relevance and quality as they can about authorization and access control. The result is not only safer outcomes but also higher quality and more complete answers from AI systems.

---

## The Knowledge Graph Approach

Modern AI systems already use knowledge graphs to model connections between entities, documents, and facts.
Those same graph techniques can describe how enterprise data relates to its sources, to other data, to users, and to governing policies.
By analyzing these relationships deterministically at the level of sentences, tables, or code fragments, organizations can finally control how data is used rather than where it happens to reside.

---

## Tracing Data Across Agent Chains, Not Just Call Chains

Multi-agent systems introduce a problem that call-chain observability alone cannot solve. When Agent A calls Agent B, which calls Agent C, existing tracing tools can record the sequence of invocations. But they cannot answer the question that governance requires: which specific data fragments moved through that chain, and on whose behalf?

Caber follows fragment identity through agent chains by maintaining the connection between the data and the human who initiated the request, without requiring credential passing between agents. When a user asks a question that triggers a multi-agent workflow, Caber's knowledge graph records which fragments each agent retrieved, which it passed downstream, and which were ultimately assembled into the response. The originating user's identity stays bound to the data throughout, not through token delegation or credential forwarding, but through the graph's record of which human request set the chain in motion and which fragments served that request at every step.

This means governance decisions at any point in the chain can account for who the data is actually serving, not just which agent is holding it. A fragment that Agent C retrieves from a vector store can be evaluated against the originating user's permissions and the purpose of the original query, even though Agent C has no direct knowledge of either. The graph provides the context that the call chain cannot.

---

## From Resource Boundaries to Data Use Control

Resource based controls keep multiplying because they chase symptoms, not causes. The next generation of governance will focus on controlling the motion and combination of data itself. That means identifying data precisely, mapping its relationships, and enforcing rules that determine how it can be used across any system.

This is the foundation of data centric Zero Trust, where control of data use replaces the illusion of perimeter defense.

---

## Closing Thought

Agent and MCP firewalls are the newest signs of an industry stuck protecting the wrong thing. After 25 years of building walls around resources, it is time to focus on controlling how data is used. Only then can enterprises move from preventing access to governing use, the real measure of control in the age of autonomous AI.

---

*Next in the series*
**Part 4: The Hidden Actor, When Agents Obscure the User Behind the Request**


Security assumed endpoints = data. Then AI agents and MCP arrived and broke that link forever. Now we're guarding the wrong target.


Why Securing MCP Servers is the Wrong Approach (Part 3)

VentureBeat recently said MCP stacks have a [92% exploit probability](https://venturebeat.com/security/mcp-stacks-have-a-92-exploit-probability-how-10-plugins-became-enterprise). Every wave of connectivity promises stronger security — and yet, the same vulnerabilities keep returning. APIs, OAuth, and now MCP all claim to close the gaps that came before them. But progress in design doesn't equal progress in outcome. The data shows that most breaches arise not from missing controls, but from controls that couldn't keep up. MCP is repeating the same pattern — just at machine speed.

---

## The Promise of Progress

Every new technology begins with the same optimism: *This time, we've learned our lesson.*

In 2010, the API economy embraced OAuth 2.0 to solve access delegation. In 2025, the MCP ecosystem announced OAuth 2.1, PKCE, and tool provenance as its answer. Both were right in theory — and wrong in practice.

<div align="center">
<table style="font-size: small; margin-left: 5pt; margin-right: 5pt;">
<thead>
<tr style="background-color: #f0f0f0;">
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Generation</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Innovation</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Intended Fix</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Real-World Outcome</th>
</tr>
</thead>
<tbody>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;"><strong>APIs (2010s)</strong></td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">OAuth 2.0, Scopes</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Limit access per app/user</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">80% of apps used global service accounts</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;"><strong>Cloud APIs (2020s)</strong></td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Fine-grained tokens, API gateways</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Centralized enforcement</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Token proliferation, gateway bypass</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;"><strong>MCP (2025)</strong></td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">OAuth 2.1, PKCE, tool filtering</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Context-aware delegation</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">70% unauthenticated or weakly scoped servers</td>
</tr>
</tbody>
</table>
</div>

The pattern isn't technical failure — it's structural. When ecosystems expand faster than the rules that govern them, even the most elegant controls degrade into suggestions.  You must be able to identify resources to control them, but determining what rules and policies those controls enforce isn't a technology issue.

---

## Familiar Vulnerabilities, Faster Timeline


MCP's most common vulnerabilities are almost identical to those that plagued early APIs:

<div align="center">
<table style="font-size: small; margin-left: 5pt; margin-right: 5pt;">
<thead>
<tr style="background-color: #f0f0f0;">
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Vulnerability</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">APIs (2010s)</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">MCP (2025)</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Cause</th>
</tr>
</thead>
<tbody>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Command Injection</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">#1 in OWASP API Top 10</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">43% of MCP servers vulnerable (Equixly 2025)</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Input not validated in dynamic calls</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">SSRF / Fetch Abuse</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Common API gateway exploit</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">33% allow unrestricted fetch (Docker Security)</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Missing network filters</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Broken Auth</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">~40% of APIs (Akamai 2020)</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">60% lack full auth (Astrix Labs)</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Optional enforcement</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Security Misconfiguration</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Persistent Top 10</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Default debug endpoints in MCP servers</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Developer speed bias</td>
</tr>
</tbody>
</table>
</div>

The difference is compression. What took **five years** to become critical in APIs took **five months** in MCP.  

This acceleration isn't just about faster development cycles. It's about the fundamental mismatch between how quickly systems evolve and how slowly security practices propagate through an ecosystem.  Patches and security vendor solutions for vulnerabilities take time.

---

## The Retrofitting Illusion

CISO teams often assume they can harden systems after adoption. History says otherwise.

<div align="center">
<table style="font-size: small; margin-left: 5pt; margin-right: 5pt;">
<thead>
<tr style="background-color: #f0f0f0;">
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Security Stage</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Typical Timing</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Success Rate</th>
</tr>
</thead>
<tbody>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Preventive design</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Pre-deployment</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">High</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Mid-cycle retrofit</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">After first exploits</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Moderate</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Late-stage remediation</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">After proliferation</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Low (&lt;25%)</td>
</tr>
</tbody>
</table>
</div>

API programs tried to retrofit fine-grained access controls years after release — and triggered massive breakage. OAuth 2.0 introduced scoped tokens, but tightening them disabled legitimate clients. Most teams reverted to coarse global credentials. 

MCP's [upcoming security layers](https://modelcontextprotocol.io/specification/draft/basic/authorization) — **ETDI** (cryptographic tool identity), **token delegation** (preserving user context through agent chains), and **per-user credential translation** — face the same adoption gravity. Once thousands of agents and tools depend on permissive defaults, enforcing precision feels riskier than leaving it weak.

---

## Why Retrofitting Fails Structurally

The research on MCP security efforts reveals why retrofits consistently fail:

1. **Backward compatibility always wins.** Enterprises will not break production workloads for new controls.
2. **Complex systems resist uniform enforcement.** Agents, servers, and tools evolve asynchronously.
3. **Governance cycles move slower than code cycles.** Standards take quarters; MCP updates propagate hourly.
4. **Security upgrades create support crises.** Each fix surfaces as a new outage before it becomes a feature.

Even when the OAuth 2.1 specification was updated to include stronger authentication flows, adoption data shows that most servers either don't implement them or make them optional. The security improvements exist on paper but not in practice.

The uncomfortable truth: **retrofits don't fail because they're wrong — they fail because they're late and often too complex.**

---

## Quantifying Recurrence

Despite a decade of progress, vulnerability recurrence rates in distributed ecosystems remain nearly constant:

<div align="center">
<table style="font-size: small; margin-left: 5pt; margin-right: 5pt;">
<thead>
<tr style="background-color: #f0f0f0;">
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Year / Ecosystem</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Avg. critical vulnerabilities per 1,000 services</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Source</th>
</tr>
</thead>
<tbody>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">APIs (2014)</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">58</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Akamai State of the Internet</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">APIs (2023)</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">31</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Salt Security Report</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">MCP (2025)</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">47</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Equixly + Docker composite scans</td>
</tr>
</tbody>
</table>
</div>

Even with tighter standards and more vendors, the rate of serious flaws per deployment has not improved meaningfully. What changed is *time to exposure* — now measured in **weeks instead of years.**

---

## What This Means for Governance

Governance models built for stable infrastructure can't handle dynamic proliferation. Security frameworks like NIST, OWASP, and ISO all assume an observable steady state — an assumption that collapses under continuous recomposition.

The data tells a single story: **growth neutralizes control faster than control can mature.**
When system evolution outpaces policy publication, enforcement devolves into theater.

MCP isn't a failure of innovation — it's proof that innovation alone cannot produce governance. Security must exist independently of protocol design.

---

## Breaking the Retrofit Loop

The alternative to retrofitting is **continuous observation from day one**. Rather than trying to add security after the fact, organizations need visibility infrastructure that evolves alongside the system it protects.

This approach requires a fundamental shift:

<div align="center">
<table style="font-size: small; margin-left: 5pt; margin-right: 5pt;">
<thead>
<tr style="background-color: #f0f0f0;">
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Phase</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Traditional Security Mindset</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Observation-First Approach</th>
</tr>
</thead>
<tbody>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;"><strong>1. Design</strong></td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Add new auth flows</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Observe real data paths first</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;"><strong>2. Deploy</strong></td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Apply generic policies</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Infer behavior from actual usage</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;"><strong>3. Enforce</strong></td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Restrict access post-failure</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Simulate impact before rollout</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;"><strong>4. Sustain</strong></td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">React to incidents</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Adapt policies in real time</td>
</tr>
</tbody>
</table>
</div>

Emerging security platforms are building this capability. Instead of assuming what data flows should look like, they observe what actually happens and derive policy from behavior.

For example, systems that build **deterministic lineage graphs** — tracking every data movement from source through transformation to destination — can identify policy violations without requiring upfront configuration. When a new MCP server starts moving sensitive data inappropriately, the system detects the anomaly based on relationship patterns rather than predefined rules.

Companies like Caber Systems are pioneering this visibility-first approach, treating observation as the control plane rather than enforcement. The philosophy is simple: **you can't retrofit what you never saw in the first place.**

---

## The Token Delegation Problem

One specific example illustrates why retrofits fail: the token delegation challenge.

APIs have had OAuth delegation for over a decade, yet research shows it's rarely implemented correctly. The same issues exist for MCP:

- **Agent → tool call is two hops**: The MCP client calls the MCP server; then the MCP server may call tools/APIs. Ensuring the second hop carries the user context and doesn't revert to a blanket service credential is nontrivial.
- **No built-in user identity**: Many MCP servers treat the "client" or "agent" as a trustful actor without tying operations to a user identity.
- **Granularity vs usability**: Too fine-grained scoping becomes complex to configure and manage in dynamic agent settings.

Token delegation proposals exist for MCP, just as they existed for APIs. But the same structural forces that prevented API adoption — backward compatibility, operational friction, debugging complexity — are already visible in MCP deployments.

---

## Closing Thought

APIs proved that strong standards can't save systems that evolve faster than they're governed. MCP is proving it faster.

The solution isn't more specification — it's **comprehension**. Organizations need visibility infrastructure that doesn't depend on perfect protocol design or universal adoption of security features.

Security has always been about control; AI-driven systems demand **understanding first**. And understanding begins with seeing what's actually happening, not what you hoped would happen.

---

**Next in the series:**
**Part 3 — The Wrong Target: Authorizing Resources When Data Is What Matters**

We'll explore why traditional resource-based authorization — controlling access to endpoints and servers — fails in AI ecosystems where data itself is the atomic unit of action. The shift from "who can access this API" to "should this data move" changes everything.

OAuth 2.0 promised to fix APIs. It failed. Now OAuth 2.1 promises to fix MCP. History repeating?

Posts

Recent Posts

When Your Governance Tool Causes the Hallucination

Ten Misconceptions About Context in AI Systems

Context Graphs for Governance

How Duplicate Data Kills Your RAG

Why Securing MCP Servers is the Wrong Approach (Part 3)

Old Vulnerabilities are New Again! (MCP Part 2)

See Caber in Action