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

*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?

Old Vulnerabilities are New Again! (MCP Part 2)

The AI ecosystem is growing faster than any IT technology in history. The Model Context Protocol (MCP) reached over 6,000 servers in its first year, nine times faster than the API boom that reshaped enterprise architecture. But the real problem isn't speed; it's granularity. AI agents operate at sentence level, extracting and recombining data fragments that document-level security tools can't see. The question isn't whether MCP will outpace traditional security; it already has. The question is whether enterprises can understand data identity at the granularity AI actually operates before the next wave of automation makes the problem exponentially worse.

---

## The 9× Growth Problem

In the 2000s, it took **seven and a half years** for public APIs to reach roughly 6,000 deployments. In 2025, **MCP hit the same milestone in 11 months.**
This isn't progress, it's acceleration without governance.

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

*Figure 1: MCP adoption trajectory compared to historical API growth. MCP reached ~6,000 servers in just 11 months versus 90 months for APIs.  This represents a 9× faster deployment velocity (575 servers/month vs 65 APIs/month). While APIs took 3.5 years to publish their first security standard, MCP achieved this in 5 months, demonstrating both accelerated growth and compressed governance timelines.*

This data reveals a dynamic complexity problem: the ecosystem is expanding at a rate **no security or audit process can match**. Each MCP server introduces new data paths, new toolchains, and new identity relationships, all changing faster than governance frameworks can adjust.

---

## The Human Capacity Cliff

Even if every organization dedicated staff to review new servers and policies, the math doesn't work.

<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;">Metric</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Value</th>
</tr>
</thead>
<tbody>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Estimated new MCP servers per month</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">~575</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Average manual audit capacity per enterprise</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">~50 servers / month</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Percentage unreviewed</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;"><strong>&gt;90%</strong></td>
</tr>
</tbody>
</table>
</div>

This is the first sign of **structural ungovernability**, when system change rates exceed the human capacity for understanding.
Governance isn't failing because enterprises are careless; it's failing because the system's speed makes comprehensive oversight impossible.

---

## Why Existing Security Models Don't Scale

Traditional Zero Trust and API governance rely on predictable endpoints and static identities. MCP, however, connects **ephemeral AI agents** to **dynamic tool servers**, forming fluid relationships that can't be enumerated ahead of time.
That breaks the assumptions behind most access controls:

<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;">Control Principle</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">What Works for APIs</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Why It Breaks for MCP</th>
</tr>
</thead>
<tbody>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Endpoint-based policies</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Static URL / method mapping</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Agents compose new routes dynamically</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Role-based access</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Fixed user-to-resource mapping</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Agents act across roles &amp; tenants</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Manual review</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Human review cadence (monthly)</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Machine reconfiguration (minutes)</td>
</tr>
</tbody>
</table>
</div>

MCP is not merely faster; it's **qualitatively different**.
It replaces predictable architecture with continuous recomposition.
Traditional security models struggle with this because they were designed for systems where change happens slowly enough for humans to review each modification.

---

## Evidence of the Data Identity Crisis

By mid-2025, multiple independent studies revealed that most MCP servers had minimal governance:

<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;">Source</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Finding</th>
</tr>
</thead>
<tbody>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Equixly MCP Vulnerability Scan (2025)</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">43% of tested servers vulnerable to command injection</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Docker Security Analysis</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">33% allowed unrestricted URL fetches</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Astrix Labs</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">60% lacked authentication for one or more endpoints</td>
</tr>
</tbody>
</table>
</div>

None of these issues are exotic zero-days, they're failures to understand what data is moving and whether it should be. AI agents don't consume documents; they use sentences, paragraphs, and tables extracted from them. Traditional security tools work at the document level, missing what agents actually access.

The lesson from the API era still applies: you can't control what you don't understand. The difference is **velocity**.  MCP compresses the timeline from exposure to exploitation from years to weeks.

---

## The Governance Paradox

Every enterprise faces a paradox: enforcing strong controls early breaks functionality, but waiting for maturity leaves exposure.
API security teams learned this the hard way, enforcing strict scopes too early causes mass outages; enabling them too late, vulnerabilities.

**MCP accelerates that paradox.** Every new tool added by an AI agent redefines what "normal" looks like. Security teams can't manually validate every relationship, and automation without context just amplifies the chaos.

This leads to a fundamental realization:

> **You can't authorize data use if you don't know what the data is.**
>
> Traditional security authorizes access to resources. AI security requires understanding data identity, what a sentence means, where it came from, and whether it's relevant to the question being asked.

---

## Quantifying the Risk Horizon

<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;">Factor</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">API Ecosystem (2010s)</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">MCP Ecosystem (2025)</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Consequence</th>
</tr>
</thead>
<tbody>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Growth velocity</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Moderate (linear)</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Explosive (exponential)</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Control can't keep pace</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Granularity</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Document/API level</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Sentence/paragraph level</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">100-1000× finer access control needed</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Identity complexity</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">User &amp; app</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">User, agent, data, context</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Authorization requires both user AND data identity</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Data transformation</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Mostly static</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Continuous (AI processing)</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Classification labels don't survive</td>
</tr>
</tbody>
</table>
</div>

The result: **systems that operate at sentence-level granularity being secured with document-level tools**. It's not just a speed problem, it's a fundamental mismatch between where AI operates and where security controls exist.

The hard truth is that **we can’t build a new firewall for every new AI resource**. Each innovation, LLMs, agents, RAG, MCP, A2A, and so on, demands another control surface, another governance model, another cycle of catch-up. That strategy can’t scale.

**Data is the invariant.**
It doesn’t evolve as fast as the tools that use it, and, becasueit's the fuel for AI, it’s the one layer that can govern AI innovation.
If we can control how **data is used**, not just **where it resides**, we break the velocity trap entirely.

---

## The Path Forward: Understanding Data Identity

The traditional model of security, authorize access to resources, no longer works when AI agents extract and recombine data at sentence-level granularity.

The emerging approach requires answering a question that document-level security never had to address: **What is this data?**

Not "what does it look like" (classification) or "where does it live" (resource authorization), but what it actually *is*, its meaning, context, provenance, and relationships.

This requires:
- **Triangulation**: Determining data identity by mapping relationships, not matching patterns. Understanding what a sentence means based on where it came from, how it's been used, and what it connects to.
- **Dual validation**:  Verifying both security (is the user authorized?) AND quality (is this data relevant to the question?). AI needs both to work correctly.
- **Sentence-level granularity**: Operating at the same level AI operates, not one or two levels above it.

Companies like Caber Systems are building platforms based on this triangulation approach, using knowledge graphs similar to GraphRAG systems to continuously map data identity at the sentence level. The philosophy: you can't authorize data use until you understand what the data is.

<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 Model</th>
<th style="color: #000000 !important; font-weight: bold; padding-left: 10px; padding-right: 10px;">Data Identity Model</th>
</tr>
</thead>
<tbody>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Step 1</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Define resource policies</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Triangulate on data identity</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Step 2</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Enforce at gateway</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Validate authorization AND relevance</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Step 3</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Audit post-incident</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Continuous lineage tracking</td>
</tr>
<tr style="background-color: #a8a7a9;">
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Step 4</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">React to breaches</td>
<td style="color: #000000; padding-left: 10px; padding-right: 10px;">Adapt as data/policies evolve</td>
</tr>
</tbody>
</table>
</div>

This isn't about seeing more, it's about understanding what you're seeing at the granularity that matters.

---

## Closing Thought

APIs were the first proof that innovation outpaces security. MCP proves that **document-level security can't protect sentence-level operations**.

The first step toward governing AI ecosystems isn't better enforcement; it's operating at the right granularity. Organizations that understand data identity at the sentence level, what data means, not just where it lives, will be able to authorize AI data use effectively. Those that continue applying document-level controls will face the same crisis that plagued the early API era, but compressed into months instead of years.

The question isn't whether to secure AI. It's whether to secure it at the level AI actually operates.

---

**Next in the series:**
**Part 2, The Myth of Progress: Why New Protocols Repeat Old Vulnerabilities**

We'll explore why MCP's security improvements underway mirror the API world's evolution, and why history suggests that better design doesn't prevent widespread vulnerabilities when adoption outpaces implementation.

MCP grew 9× faster than APIs. We still haven't gotten security fixed for APIs-is there hope for MCP?

AI Velocity Nobody Can Secure (MCP Part 1)

Think MCP, ANP, agents.json, Agora, LMOS, or AITP will "solve business context"? They won't. These protocols are great at making data available to agents. They make it easier to pass the right chunks from this data to other agents. They do not tell you what any given chunk actually means in your business, or when it's appropriate to use. That's not a transport problem, it's a meaning and governance problem.

Business context isn't just the metadata attached to the document your AI happened to retrieve from, or the semantic relationships you can squeeze out of a single paragraph. It's an ecosystem of relationships, and the most important ones often live outside the immediate source.

## The Hidden Life of a Chunk

When we talk about context, we're really talking about chunks. That's how LLMs, RAG systems, and most vector databases see the world. A "chunk" might be a sentence, a table cell, or a paragraph, small enough to embed, big enough to convey meaning.

Here's the catch: the exact same chunk might appear in dozens of different documents, each with its own metadata, authorship, timestamps, confidentiality flags, regulatory tags, workflow stage, and so on.

> If you only look at the document the chunk was read from, you miss the bigger story.

That's like judging a single line of code based solely on the file it's in, without knowing it's been copied into six other repos, patched in three of them, and is currently being used in production by a system with a different security model.

## Why Proximate Metadata Falls Short

Most classification and governance tools still think like librarians: "This document has these attributes, so its contents must too."
The reality?

* That "confidential" paragraph in your quarterly earnings report may be identical to one already published in last year's public filing.
* The same compliance clause in a contract may also appear in an internal policy draft with stricter access rules.

If your governance layer only sees the local metadata, it will either over-restrict (blocking safe use) or under-restrict (risking a leak).

## The Authorized Junk Problem

There is a third failure mode that over-restrict and under-restrict don't capture: authorized irrelevance. Authorization determines whether a user is allowed to see a piece of data. It says nothing about whether that data is relevant, current, or helpful for the question being asked.

An AI system that fills its context window with authorized-but-irrelevant fragments produces worse answers than one with a smaller, curated context. Boilerplate clauses, stale drafts, duplicated paragraphs, and template language all pass access checks without difficulty. They are permissioned. They are also noise. And because they satisfy the policy bar, no governance tool flags them.

The result is a context window full of content the user is allowed to see but that degrades the answer the user actually receives. Every governance tool that stops at "is this user allowed to see this" lets noise through. Authorization is necessary, but it is not a quality signal.

## The Broad-View Context Model

To really capture business context, you need to:

1. Aggregate metadata across every occurrence of a chunk, in every document, across time.
1. Resolve conflicts using precedence (source of authority) and prevalence (most common use) rules.
1. Maintain lineage so you can see exactly where that chunk has been, who touched it, and under what policy it lived at each point.

This is a fundamentally different mindset. Instead of starting with "this document says X about this chunk," you start with "this chunk exists in 27 places, and here's the union of everything we know about what it means and how it can be used, in other words, its business significance."

In practice, this broad view enables every fragment to be evaluated against four questions before it enters an AI context window:

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. **Is it relevant?** Does this fragment contribute substantive information to the question being asked, or is it noise that happens to pass the access check?

Without the broad view, you cannot answer any of these questions reliably. With it, governance stops being a gate that either blocks or permits, and becomes a filter that ensures only current, authoritative, authorized, and relevant content reaches the model.

## Why Agent Communication Protocols Can't Fix This

Let's be clear: protocols aren't the villain; they're just not the mechanism for meaning. MCP, ANP, Agora, agents.json, LMOS, and AITP define how agents talk to each other, how they exchange tasks, pass along context, and authenticate participants.

Many of them address critical security pillars for agent interactions:

* Confidentiality of communications (so only the intended parties see the data)
* Integrity (so the data isn't altered in transit)
* Authenticity and non-repudiation (so you know who sent it, and they can't deny it later)

That's essential for trust between agents. But none of it answers the core questions: what does this chunk mean in your business, and under what conditions can it be used?

Knowing which agent handed you a paragraph doesn't disambiguate its business significance. The same chunk can appear across silos under conflicting metadata. Until you resolve that conflict at the chunk level, policies will fail, regardless of how well your agents authenticate each other.

Protocols move context securely. Meaning and policy come from a cross-corpus, metadata-aggregated view of the chunk itself, the broad view we've been talking about.

## The Payoff

When you take the broad view:

* AI answers become explainable, because every retrieved chunk comes with a history.
* Permissions stop being brittle, because you're applying the right policy for the chunk, not the default for the nearest file.
* Data quality improves, because duplicate and stale chunks can be identified and resolved before they pollute your retrieval set.
* Authorized noise gets filtered, because relevance and currency are evaluated alongside access, not ignored.

And perhaps most importantly, you stop treating "context" as whatever happens to be nearby, and start treating it as the complete, cross-document truth.


Stop worshiping documents; meaning lives at the chunk. Unify metadata, resolve conflicts, apply policy.

Business Context on AI Data Won’t Be Solved by Retrieval.

Recent advances in AI—semantic graphs, vector search, and attention optimization—are exciting and powerful. They move beyond keywords and help us extract deeper patterns from unstructured content. But in enterprise environments, these approaches all share a critical blind spot:

> *They rely on what data looks or smells like—rather than how it's actually used in the business.*

Business significance doesn’t live in token frequency or surface similarity. It lives in metadata, lineage, structure, and workflow. In other words, **meaning is not inferred—it’s modeled**.

Let’s examine three promising techniques that illustrate this pattern of semantic approximation. These aren't critiques of the work itself—in fact, they’re valuable building blocks. But they highlight how much more is needed for AI to operate effectively in enterprise settings.

---

## 🧱 Example 1: Chunk Overlap in Vector RAG

Many vector RAG systems assume that if two chunks share similar tokens or embeddings, they must be “related.” It’s a useful shortcut for retrieval—but in enterprise environments, it can easily mislead.

> For example: A marketing ROI report and an HR training manual may both mention “ROI” and “performance,” but their business roles are entirely different.

Chunk overlap doesn’t reveal intent, governance, or data classification. It connects content by **how it reads**, not by **what it does**.

To truly relate content, we need:
- Document type and purpose
- Departmental origin
- Workflow stage
- User roles and permissions

These aren't textual features—they're structured context.

---

## 🎯 Example 2: Context Engineering and Frequency-Driven Relevance

[LLMSTEER (arXiv:2411.13009)](https://arxiv.org/abs/2411.13009v2) introduces a smart method for improving long-context performance: boosting attention on tokens that are reused across inference steps. This can help LLMs focus on “important” information.

In narrow domains—like code repositories or customer support logs—reuse often does signal importance. But across broad enterprise corpora, it falls short.

> While a runny nose is usually just a cold, in the emergency room it could be an early sign of Churg-Strauss syndrome—a rare and potentially life-threatening autoimmune disorder.

Token frequency doesn’t equate to business meaning. Instead, meaning comes from:
- Where a term appears (e.g. header vs. appendix)
- What kind of document it’s in (template vs. signed agreement)
- Who authored it and when

LLMSTEER’s attention boost is helpful—but it needs grounding in metadata to reflect enterprise significance.

---

## 🔁 Example 3: Knowledge Graphs and the Limits of Local Semantics

The latest innovation in knowledge Graphs is [Graph-R1’s (arxiv:2507.21892v1)](https://arxiv.org/abs/2507.21892v1) use of semantic hypergraphs is a real step forward—capturing n-ary relationships like “Alice and Bob co-founded Acme in 2019.” It adds structure and depth beyond typical vector methods.

But even this approach still builds relationships from **within** chunks of text. It doesn’t look at:
- The document’s policy role
- Workflow state (draft, pending, approved)
- Business process alignment

> For instance, “Chest X-ray recommended” might appear in a discharge summary, a clinical guideline, or a training example. Graph-R1 sees one relationship. But to the business, there are three different implications.

Without metadata and process context, even rich semantic links can’t distinguish authoritative action from illustrative mention.

---

## 📌 The Pattern: Approximation Over Anchoring

Each of these innovations reflects real progress. But they share an assumption: that meaning can be **inferred from usage patterns**, rather than **anchored in structured context**.

In enterprise AI, that’s not enough.

| **Technique**            | **What It Adds**                       | **What It Misses**                               |
|--------------------------|----------------------------------------|--------------------------------------------------|
| Vector RAG chunk overlap | Semantic proximity                     | Workflow context, data lineage                   |
| LLMSTEER                 | Attention to reused tokens             | Role, author, and system-level significance      |
| Graph-R1                 | Structured semantic relationships      | Policy role, document state, metadata hierarchy  |

These techniques are useful heuristics—but they’re only **a layer**, not the full foundation.

---

## 🧠 Why Semantic Structure Is Essential

To move beyond guesswork, enterprise AI must incorporate:

- **Metadata-aware reasoning**: Understand document types, classification levels, and authorship.
- **Data lineage and versioning**: Know how a clause or chart evolved and where it was reused.
- **Process and policy integration**: Understand how content fits into formal workflows or controls.
- **Semantic layers**: Define organizational concepts explicitly and connect content to them.

This is the foundation for explainability, compliance, and trust in enterprise AI. Without it, models can retrieve related-sounding content that **misleads more than it informs**.

---

## ✅ Final Thought

Vector search, attention steering, and semantic graphs are necessary steps. But alone, they’re not sufficient. Enterprise AI must do more than pattern match—it must model business meaning explicitly.

> It’s time to shift from guesswork to grounding.  
> From what data looks like—to what it *means* in context.


AI that guesses what data looks like can’t be trusted to know what it means. Business context is not a vibe.

When What Data “Looks Like” Isn’t What it “Means”



We all know the story: you’re building out a project, tweaking code on your organically grown website. One day you prompt an AI:  
> “I need a function to do X.”

It generates something good. Then later:  
> “I need my function to do X + Y.”

Instead of improving the original function and updating all its references, the AI spins up a new function. Now you’ve got duplicated logic—some calls point to the old function, some to the new. Chaos creeps in.

In my own codebase I saw this pattern over and over. For example:

```js
// Original helper
function processOrder(order) {
   validate(order);
   submit(order);
}

// Later request to add tracking
function processOrderWithTracking(order) {
   validate(order);
   submit(order);
   track(order);
}
```

Half the code called `processOrder`, half called `processOrderWithTracking`.  
Downstream references in `invoice.js` still used the old function, while `shipment.js` used the new one.  
**The AI had no visibility into the function graph to know it should merge logic and update references.**

---

## Models Are Great, But Data Rules the Outcome

AI models are getting better fast. Switching between them is becoming less painful, and their raw capabilities feel similar. So how do you know which one to use?  
**You don’t—because the model isn’t the whole story.**

The real question is:  
👉 *What data are you feeding it?*

When you provide structure, even a little, answer quality skyrockets. For example, supplying a database schema instead of just dumping tables into a prompt improved one system’s answer quality from **72% to 87%**—a 15% jump for minutes of extra work.

---
---
_**Example:  Try #1 — Use AI to find unused and disconnected files in my codebase**_

My Prompt:
```
Identify all files that are disconnected from the marketing pages, authorization, deployment and dashboard.  I'm looking for unused files that may be referenced in other files that themselves are disconnected from the core graph.
```
AI Response:
```ai
[...]
This cleanup could remove approximately **20-25% of unused code** from your components directory and simplify the codebase significantly.
```
**Time: 3 minutes 12 seconds**

---
---

## Unstructured Dump vs. Structured Context

Dumping unstructured data into a context window often fails to deliver the right results. You need to give your AI not just data, but data **with context:**

- What each element is.
- How elements are related.
- Which relationships matter for the task at hand.

Think of it like giving your AI a map instead of a random list of street names.


## Adding Structural Hints Improves Responses

Graph-based RAG (retrieval augmented generation) is a great start, but the trick is building relationships:  
- What functions call what.  
- What database fields depend on what tables.  
- How pieces of documentation relate to each other.

Here’s a snippet from my codebase that demonstrates the value of mapping out dependencies between files:

```
index.js -> utils/logger.js
index.js -> services/api.js
services/api.js -> utils/logger.js
services/api.js -> models/user.js
```

When you represent your code this way, the AI can see that both `index.js` and `services/api.js` rely on the same logger—so a change in `logger.js` affects them both. Instead of duplicating logic, the AI could reason:  
> *Modify `logger.js` once and update its usage everywhere.*`


---
---
_**Example:  Try #2 — Was I about to delete needed code?**_

Deterministically build a dependency graph
```bash
caber% time npm run analyze:json

> caber-systems-portal@0.1.0 analyze:json
> npx madge --json src/ > dependency-graph.json

npm run analyze:json  1.41s user 0.23s system 79% cpu 2.070 total
```

My Prompt:
```prompt
Given the attached dependency graph, identify all files that are disconnected from the marketing pages, authorization, deployment and dashboard.  I'm looking for unused files that may be referenced in other files that themselves are disconnected from the core graph.
```

AI Response:
```ai
[...]
This analysis shows your codebase is relatively clean with only ~8.5% disconnected files, mostly old pages and test files.
```

 **Time: 2 minutes 3 seconds + 2.070 seconds = 2 minutes 5 seconds** ⬅️ 

---
---


## Where Does Context Come From?

Context comes from **data elements** and the **patterns in their creation and use.**  Some patterns are standardized (a function calling another). Some are complex (like how weather patterns can affect call center volume). When you surface these patterns you’re giving AI clues about your data that it often won't uncover on its own.

In the examples above providing structured context (the dependency graph), saved us about 35% of the time while getting a more accurate result (8.5% disconnected files vs the original estimate of 20-25% unused code).

## Why It Matters

Interconnectedness in data is something we take for granted but rarely exploit. By unraveling those relationships and feeding them to the AI, you elevate it from a code generator or summarizer into a trustworthy partner that understands your data.

**It’s not the model—it’s the data you give it.**


AI giving you duplicate code? The fix isn't a better model - it's structured context. See 72% → 87% jump!

Why Adding Schemas Supercharges AI Answer Quality

Every enterprise today deals with an enormous volume of PDF documents. From financial reports and contracts to regulatory filings and internal memos, PDFs have become ubiquitous due to their portability and visual consistency. Yet putting the data these PDFs contain into a format enterprise AI applications can use is a roadblock 🚧.  

Beneath their convenience lies a simple fact: PDFs have no easily parsable structures, or metadata, describing what elements are, or which text might be the title, a heading, or a page footer--and this makes recognizing these different elements painfully difficult. While AI-based parsers produce impressive results, they do so at significant cost and still struggle to attain reliability and consistency across different types of documents 📑.

So what if we could get the information those PDFs contain into a usable format without parsing PDFs at all?  The key to answering that is actually pretty easy once you consider enterprise workflows and where those PDFs came from in the first place:  It's lineage.

## 4,628 AI Models to Work Harder, not Smarter?

As I write this, Hugging Face lists 4,628 AI models for [Image-Text-to-Text](https://huggingface.co/models?pipeline_tag=image-text-to-text).  Turns out printing PDFs to images and using AI for Optical Character Recognition (OCR) works better than having AI parse the PDF directly.  

There are dozens of free and paid online converters (see our list [here](https://github.com/Caber-Systems/ComparePDFparsers/blob/master/ListOfPDF2MarkdownConverters.md)), Python libraries, and projects on GitHub dedicated to parsing PDFs. [Adobe](https://developer.adobe.com/document-services/apis/pdf-extract/) themselves have one, and so do all of the leading AI providers: 
   * [OpenAI](https://learnprompting.org/blog/openai-api-works-with-pdfs) files API
   * [Anthropic](https://docs.anthropic.com/en/docs/build-with-claude/pdf-support) via thier Converse and InvokeModel APIs
   * [Mistral](https://mistral.ai/news/mistral-ocr) OCR-based PDF conversion  
   * [LlamaIndex](https://docs.llamaindex.ai/en/stable/llama_cloud/llama_parse/) LlamaParse
   * [Microsoft](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/?view=doc-intel-4.0.0) Azure Document Intelligence
   * [Google](https://cloud.google.com/document-ai) Document AI

While these methods can produce impressive results, the reality of scalability quickly becomes evident:

- A single PDF can take tens of seconds to minutes to process and parse accurately.
- Many enterprises have millions of PDFs stored which can quickly balloon processing into years of compute time and enormous associated costs.
- GPUs help, but not as much as you might think, by providing 3x to 4x increase in processing speed 


<div align="center">
<h3>AI-Based PDF Parsing Performance Summary</h3>
<table>
<thead>
<tr style="background-color: #f0f0f0; color: #000000">
<th>Processor</th>
<th>Total Time (s)</th>
<th>Sec/Page</th>
<th>Bytes/sec</th>
<th>Success Rate</th>
</tr>
</thead>
<tbody>
<tr style="background-color: #a8a7a9; color: #000000">
<td>Mistral</td>
<td>14.71</td>
<td>0.28</td>
<td>11493</td>
<td>100.0%</td>
</tr>
<tr style="background-color: #a8a7a9; color: #000000">
<td>PyMuPDF4LLM</td>
<td>15.00</td>
<td>0.27</td>
<td>11916</td>
<td>100.0%</td>
</tr>
<tr style="background-color: #a8a7a9; color: #000000">
<td>Docling (no GPU)</td>
<td>94.90</td>
<td>1.74</td>
<td>2415</td>
<td>100.0%</td>
</tr>
<tr style="background-color: #a8a7a9; color: #000000">
<td>Docling (GPU)</td>
<td>78.20</td>
<td>1.45</td>
<td>2938</td>
<td>100.0%</td>
</tr>
</tbody>
</table>
<strong>Total files processed</strong>: 12<br>
<strong>Total pages processed</strong>: 2,736<br>
</div><br>

These figures are consistent with those presented in the [Docling Research paper](https://arxiv.org/html/2501.17887v1) and highlight an inescapable truth: parsing PDFs using LLMs, despite being powerful, won't scale to meet the millions of documents needed to be parsed in typical production enterprise use.

## The Overlooked Power of Data Lineage

If you go to the web pages of [Apple, Inc.](https://investor.apple.com/sec-filings/default.aspx), and [Tesla, Inc.](https://ir.tesla.com/sec-filings), the sources for the SEC financial filings we used to obtain the results above, you'll see that every 10-K and 10-Q statement is provided in both HTML and PDF formats.  In fact, the EDGAR portal used to file these financial statements only accepts submissions in structured formats -- either HTML or XBRL.  

It's no surprise that the vast majority of enterprise PDFs were never original creations. They're outputs—exports from structured sources such as HTML web pages, Word documents, Excel spreadsheets, or database records. These original formats inherently encode structure, with rich metadata that describes tables, headings, and key semantic content in a clear, parse-friendly manner that conversion to the PDF format discards.

<div align="center">
<h3>HTML to Markdown Processing Performance</h3>
<table>
<thead>
<tr style="background-color: #f0f0f0; color: #000000">
<th>Processor</th>
<th>Total Time (s)</th>
<th>KB/sec</th>
<th>Elements/sec</th>
<th>Output Bytes</th>
<th>Success Rate</th>
</tr>
</thead>
<tbody>
<tr style="background-color: #a8a7a9; color: #000000">
<td>Markdownify</td>
<td>1.06</td>
<td>2627.9</td>
<td>33288</td>
<td>405516</td>
<td>100.0%</td>
</tr>
<tr style="background-color: #a8a7a9; color: #000000">
<td>html-to-markdown</td>
<td>0.49</td>
<td>4064.8</td>
<td>55248</td>
<td>403604</td>
<td>100.0%</td>
</tr>
<tr style="background-color: #a8a7a9; color: #000000">
<td>html2text</td>
<td>0.19</td>
<td>8691.6</td>
<td>126795</td>
<td>381705</td>
<td>100.0%</td>
</tr>
<tr style="background-color: #a8a7a9; color: #000000">
<td>MarkItDown</td>
<td>1.12</td>
<td>2418.0</td>
<td>30704</td>
<td>385882</td>
<td>100.0%</td>
</tr>
</tbody>
</table>
<strong>Total files processed</strong>: 12<br>
</div>
<br>

Compare the Bytes/sec and KB/sec columns in each graph. Parsing the HTML sources sources directly can be completed in milliseconds—literally ⚡️**1,000 times faster**⚡️ than parsing the PDFs.  Moreover, since all the structure and metadata exists in the HTML, the conversion is **100% accurate** because it's deterministic. 

The profound speed and accuracy advantages of parsing structured documents over PDFs become starkly evident at scale, making lineage knowledge incredibly valuable 💰💵💸.

## Trading One Hard Problem for Another?

While it's easy to "just use AI" to solve hard problems, blind recourse to brute force inherently suffers from inefficiency and unpredictability.  As in the example above, where an ounce of insight unlocks a thousand-fold increase in performance, a deep understanding of enterprise workflows, how enterprise data is created, shared, and used, can unlock better ways to use that data with AI. 

If you are thinking, "🐂💩! How am I going to find the HTML, XLS, DOCX, or whatever source the PDFs were created from?" 

We're with you...or at least we were before that question drove us to a solution.

## Data Bread Crumbs and Stepping Stones

Enterprises inherently generate massive amounts of duplicate data. Both the PDF and the HTML it was created from are stored, as are the emails that were sent with one of these in the attachments.  Formatting differences hinder straight up comparison of every PDF to every DOCX file, but while we are embedding them into Retrieval Augmented Generation (RAG) stores we break the files down into sentences, paragraphs, tables and other chunks of data.  

These chunks of data form natural, deterministic connections between documents, database tables, applications, AI agents, users, and even the APIs that move the data.  Like in the neural networks fundamental to today's AI, these connections are as important as the data itself to knowing what the data is, what business context applies to it, and how to best utilize the data.  

Knowing that the majority of PDFs exist alongside the documents and data sources they were created from, building RAGs in two-stages would give a significant performance increase:
1. Parse all non‑PDF documents first, build a RAG from them.
2. Look up PDFs, after parsing with fast, non‑AI, tools like [pypdfium2](https://pypi.org/project/pypdfium2/), and only parse with AI and add to the RAG if no good match is found. 

Like graph-based RAG or GraphRAG, knowledge graphs are key to putting these thoughts into practice. But unlike GraphRag, we need to look beyond relationships inside documents, and leverage the relationships between them. Even incomplete knowledge about the lineage of data can yeild significant benefits.  By explicitly mapping these relationships, we can uncover the origin, context, and optimal use of data, enabling the precise identification and control over data needed to optimize AI outcomes.

## It's Time to Work Smarter 🧐 With AI 🤖

The limitations of brute-force PDF parsing through LLMs illustrate an essential point: true scalability and efficiency require understanding and leveraging data relationships and lineage. PDF parsing difficulties underscore a broader enterprise truth—effective data utilization isn’t merely about computational power but rather about intelligently understanding and managing the underlying data.

If you would like to dive into the results presented in this post, the data and code are publicly available on Caber's GitHub page at the link below:

[https://github.com/Caber-Systems/ComparePDFparsers](https://github.com/Caber-Systems/ComparePDFparsers)

Dramatically faster and more accurate PDF data extraction could be achieved by leveraging existing document structures.

The PDF Parsing Secret That Outperforms AI by 1000x

Trustworthy AI is an uncomfortable subject. **It’s the most difficult question that everyone needs an answer to; but you never want an AI to answer it for you.** It’s the question that no one wants to talk about; but...everyone wants to believe we have an answer to. 

## Garbage-in, Garbage-out
The old addage "Garbage-in, Garbage-out" is a <a href="https://www.sciencedirect.com/science/article/pii/S0893395224002667" target="_blank" rel="noopener noreferrer">fundamental truth in AI</a>. If you feed an AI system bad data, it will produce bad results. With little or no stretch of the imagination you'll arrive at the corrolary: "Untrusted data in, Untrusted results out".  It's a simple concept that is often overlooked in the rush to deploy AI systems.

Unfortuntaly, lack of predictability in AI systems prevents the inverse statement, "Trusted data in, Trusted results out", from being true for all results.  Yet it does hold true that to have trusted results out, you must have trusted data in.  This is the foundation of trustworthy AI.

## The AI Trust Gap

On our journey to build a fundamentally new kind of data governance platform we’ve asked over one-hundred enterprises a simple question... **“Do you Trust your Agentic AI Systems?”</strong>**

95% of the time, the answer is, “of course not; but we use it anyway. We don’t have any real choice. Our competitors use AI, and we can’t sit idle while they gain an advantage” – FOMO is a real thing.

<div class="w-3/4 mx-auto py-4" align="left">
    <p>Today, trust in AI-driven processes is a key barrier. For AI to succeed at scale, individuals, companies and partners must trust and take responsibility for ensuring that processes powered by AI are safe, reliable and effective... A global survey found that 61% of people hesitate to rely on AI systems, often due to concerns over <strong>data security</strong> and third-party involvement.</p><span class="caption"><a href="https://reports.weforum.org/docs/WEF_AI_in_Action_Beyond_Experimentation_to_Transform_Industry_2025.pdf" target="_blank" rel="noopener noreferrer">- World Economic Forum, AI Governance Alliance</a></span>
</div>

Trustworthy AI starts and ends with your data. Data is fundamentally critical for AI models. The more data you give a model, the more information it can reason through, plan with and work with, to structure remarkable superhuman results. “Data is to AI, what oxygen is to Humans" is a universally accepted constant in the AI industry.
Data security and third party involvement get to the heart of the AI Trust Gap.  Was the data tampered with?  Where did the data come from?  

## Data Lineage
The aspirational goal of Agentic AI systems is to achieve “on-par trust” with human employees, so that the business decisions being made with AI are “Trustworthy at parity” with the employees that direct the AI (or are replaced by it). This compounded trusted relationship generates an environment that should deliver radically new remarkable superhuman results for businesses. We need both the employee and the AI system to co-operate within a **Circle of Trust** that the business can prove, believe in and govern. 

Knowing if data, and hence AI, is within this circle of trust requires knowledge of that data's lineage.  This is a modern hybrid GenAI concept that converges the business goals of data governance, security, compliance, data Lineage and trust...into a single Mission critical business objective - to achieve AI Trust.

## Data Knowledge Graph

At Caber, our core Gen AI thesis is that **AI Trust starts and ends with data**. Knowledge of data quality requires all sources of AI data and metadata consumed by Gen AI have a trusted, discoverable, lineage that is strongly connected to its security posture; at a deep granular level beyond the document container (down into the intra-document chunk, embedding and byte-segment level). We believe that trust can only be built from deeply understanding how data, metadata and segmented chunks of data flow through-out enterprise networks and Gen AI Agentic stacks (e.g. API’s, services, endpoints, databases, object stores, file systems, caches, frameworks, pipelines, etc.); and the relationships of all those data elements are graphed together in a way that trust can be deterministically computed and governed for your business.
Knowing we can't rely on such a dynamic knowledge graph of data to be pre-existing in companies is the reason why building this graph efficiently and scalably is at the heart of Caber's platform.

<div class="w-3/4 mx-auto py-4" align="center">
      <img src="/images/blog/caber_data_knowledge_graph_dark.png" alt="Caber Data Knowledge Graph" onclick="window.open(this.src, '_blank');">
</div>
<p class="caption" align="center">
      <span>Caber links common byte-sequences found in stored objects, database records, on the network, in APIs, and used inside Agentic services to trace the lineage of data through a company's environment and identify it by the relationships it has.</span>
</p>

Caber becomes your trusted data system that independently and neutrally governs AI Trust for your enterprise. As such Caber becomes your always-on system that runs as a core platform underneath and with your Gen AI Data systems, curating a complaint **circle of trust** for users as they interact and converse with your deployed Agentic AI Apps and infrastructure.

## Conclusion
Gen AI Trust starts and ends with deterministic knowledge of your data. Caber delivers data knowlege, intelligence, and governance on a platform that can redact, block and deny low quality user-centric data flows before they are injected into the LLM’s context frame; deterministically preventing low performance, error-prone, inaccurate, false and confused LLM outputs. The result is higher quality LLM performance, with guaranteed private and secure AI application data operations made compliant to existing and upcomming regulations through conversational policy inputs. 

We understand that Trustworthy AI requires an ‘Unstoppable Unyielding Always-on’ service based on intelligently knowing what constitutes useful, high-quality, trusted data – and can share that knowledge with other Agentic AI systems through powerful API services & insights. for Data that is utilized, accessed and flows throughout the entire Gen AI Agentic stack.
 
Caber is the platform that delivers this vision. We are excited to be on this journey with you.


Do trusted data inputs lead to trusted data outputs?  Lineage is fundamental to the answer.

Trust in AI Requires Trust in AI Data Use

Getting access control to work in vector databases is no easy feat. Most likely an AI agent using a service account with broad access rights, not the user the access is made on behalf of, is performing all data reads.  In this blog post by <a href="https://zilliz.com" target="_blank" rel="noopener noreferrer">Zilliz</a>, the makers of the <a href="https://milvus.io" target="_blank" rel="noopener noreferrer">Milvus</a> vector database, Caber CEO Rob Quiros discusses the challenges of data governance in AI systems like this at Zilliz's Unstructured Data Meetup.  A recording of the talk is available by clicking <a href="https://www.youtube.com/watch?v=gAqHbNrHMsM" target="_blank" rel="noopener noreferrer">HERE</a>

<div class="mx-auto py-4" align="center">
    <img src="/images/blog/zilliz_caber_blog_image.png" alt="Click this image to read the original post on Zilliz's website" onclick="window.open('https://zilliz.com/blog/beyond-rag-partitions-per-user-per-chunk-access-policy', '_blank');">
</div>
<p class="caption" align="center">
    Click the image above to read the original post on Zilliz's website
</p>


Dynamic policies and AI agent identites undermine access control

Fixing Access Control in Vector DBs

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

In the cybersecurity echo chamber, the relentless assault of false positives on Security Operations Center (SOC) teams is surpassed only by the cacophony of vendor marketing fluff claiming to reduce them. It's like listening to a symphony played on broken instruments. You know you're more likely to get that two or five percent reduction by turning off an existing tool than adding a new one.

False positive rates in existing tools are awful. Yet, we've accepted their inevitability to the point where we measure them to compare how good a tool is versus how bad it is. "Sucks-less" may be inevitable in political decisions, but it doesn't have to be with security tools. Deterministic detection of security incidents exists with the potential to silence the noise of those broken instruments and reveal attack signatures too faint to break through.

This blog explores the transformative potential of deterministic authorization across the three states of digital data, at rest, in transit, and in use, to eliminate false positives in incident detection.

### **The False Positive Quandary and Deterministic Solutions**

#### **Data-at-Rest: A Model of Determinism**

The foundation of data security, data-at-rest, showcases the efficacy of deterministic access controls such as Access Control Lists (ACLs). These controls set the stage for explicit, enforceable permissions that significantly mitigate the risk of false positives, demonstrating the untapped potential of deterministic methods in broader cybersecurity contexts.

#### **Data-in-Transit: Bridging the Gaps**

When data transitions into motion, it encounters a landscape where deterministic authorization becomes challenging yet increasingly necessary. The lack of embedded permissions in data packets underscores a critical vulnerability in confidentiality, despite existing measures for integrity and availability. This gap highlights the urgent need for integrating permissions within data protocols to ensure comprehensive and deterministic security measures.

#### **Data-in-Use: The Final Frontier**

Arguably the most complex state to secure, data-in-use demands a nuanced approach to deterministic incident detection. The proliferation of microservices and cloud-based architectures has obscured the clear linkage between user identities and data permissions, necessitating innovative solutions to restore determinism in authorization practices within these distributed environments.

### **Towards a Deterministic Future: Strategies and Solutions**

The journey to a more deterministic cybersecurity framework requires a multifaceted strategy. It begins with embedding permissions directly within data transactions and extends to reevaluating our architectural approaches to cloud applications. By drawing inspiration from initiatives like Caber's CA/CO, and filling in the gaps exposed by Google's BeyondProd, and enterprise Digital Rights Management we can chart a path towards achieving deterministic authorization across all states of digital data.

### **Conclusion: A Call to Action for SOCs**

The embrace of deterministic incident detection signals a pivotal moment in cybersecurity. By adopting a deterministic approach, SOCs can dramatically reduce false positives, focusing their efforts on genuine threats and enhancing overall operational efficiency. This blog has outlined the critical steps and considerations necessary for this transformation, highlighting the indispensable role of innovative solutions and collaborative industry efforts. As we move forward, the call to action is clear: the time for SOCs to pivot towards a deterministic and more secure future is now.


Directly securing data-in-transit is the key to eliminating growing false-positives

Posts