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

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

Recent Posts

AI Velocity Nobody Can Secure (MCP Part 1)

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

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

Why Adding Schemas Supercharges AI Answer Quality

The PDF Parsing Secret That Outperforms AI by 1000x

Data: The Path to False Positive Freedom

See Caber in Action