The Sovereign Redactor — A Precision-Guided Privacy Airlock

In the last post, we gave our forensic system “Eyes” using local Multimodal Vision. We successfully extracted a mysterious handwritten inscription from a first edition of The Great Gatsby without a single pixel leaving our local network.

But perception is only half the battle. To turn that raw text into a forensic verdict, we often need the “High Reasoning” capabilities of frontier cloud models like Claude 3.5 or GPT-4o. This creates a Privacy Paradox: How do we send the context of a finding to the cloud without leaking the Personally Identifiable Information (PII) contained within it?

Today, we implement the Sovereign Redactor—a precision-guided airlock that scrubs sensitive entities at the edge before they hit the egress pipe.

The Problem: NLP Over-redaction

Traditional redaction is a blunt instrument. If you use a simple regex or a basic NER (Named Entity Recognition) model, it might redact the author “F. Scott Fitzgerald” or the publisher “Scribner’s” because it identifies them as PERSON or ORGANIZATION.

In rare book forensics, for example, the author’s name isn’t PII—it’s primary metadata. If we redact the subject of the audit, the cloud-based reasoning agent becomes useless. We need a system that can distinguish between Metadata (to keep) and PII (to hide).

The Stack: Microsoft Presidio + spaCy

To solve this, we integrated Microsoft Presidio. Unlike a standard regex, Presidio allows us to define a complex pipeline of “Recognizers” and “Anonymizers.”

We use spaCy’s en_core_web_lg (Large) model as the underlying NLP engine. This gives the Redactor the linguistic context to understand that “Gatsby” in a book title should stay, but “Gatsby” mentioned as a person’s name in a private letter might need to go.

The Architecture: Secure by Default

The Redactor is built on a “Secure by Default” philosophy. In our orchestrator, we don’t ask if a provider is “dangerous.” We ask if a provider is Local.

If the provider is ollama or none, the data stays raw. If the provider is anything else (Anthropic, OpenAI, etc.), the Sovereign Vault Airlock engages automatically.

Mermaid diagram showing the Sovereign Redactor airlock architecture. Local vision findings are checked against the provider type; local providers get direct egress while cloud providers pass through a precision shield containing spaCy entity recognition, metadata allow-listing, and Presidio PII scrubbing.
The Precision Shield: How the Sovereign Redactor intercepts sensitive PII at the edge while allowing critical metadata to pass through for cloud-based reasoning.
# The Sovereign Egress Guard
LOCAL_PROVIDERS = {'ollama', 'none'}

if provider not in LOCAL_PROVIDERS:
    # Engage the Airlock
    scrubbed_text, count = redactor.scrub(
        text=visual_findings,
        allow_list=metadata_allow_list
    )
    logger.info(f"🛡️ Sovereign Vault: {count} entities redacted from egress.")

The “Precision Shield”: Using Allow-lists

To prevent the “Fitzgerald” problem, we implement a Precision-Guided Allow-list. Before the Redactor scans the text, the orchestrator dynamically builds a list of “safe” words based on the Master Bibliography:

  1. The Book Title
  2. The Author’s Name
  3. The Publisher’s Name

These entities are passed to the Redactor as an allow_list, instructing Presidio to ignore them even if it’s 99% sure they are PERSON or ORGANIZATION entities.

Resiliency: The “Safe-Fail” Pattern

One of the biggest challenges with local NLP is the resource cost. Loading a 500MB spaCy model into memory is “expensive.”

We implemented a Sentinel-based Lazy Loading pattern. The Redactor only loads when it’s needed. If the system fails to load the model (e.g., missing dependencies), it doesn’t crash the audit. Instead, it marks itself as _REDACTOR_DISABLED, logs a critical warning to the human auditor, and “fails open” to preserve forensic continuity.

“In a forensic system, a hard crash is a loss of data. A safe-fail is a managed risk.”

The Result: Privacy-Preserving Reasoning

When we ran the Gatsby audit, the local Vision Agent found a handwritten note. The Redactor identified three sensitive entities (mentions of a name and a location not in our allow-list) and scrubbed them.

The cloud received this:

“Handwritten note found on title page. Content: ‘I must have you by . I would like to read it for my English class at .'”

Claude 3.5 was still able to reason that the note was non-canonical and unusual for a first edition, without ever knowing the names or locations written in that 100-year-old pencil.

Architect’s Summary

The Sovereign Redactor proves that Privacy and Intelligence are not a zero-sum game. By moving the redaction logic to the edge and using precision allow-lists, we can utilize the world’s most powerful cloud models while ensuring our “Forensic Vault” remains truly sovereign.

Ready to build your own Sovereign Vault?

Explore the hardened SovereignRedactor logic in the mcp-forensic-analyzer repository. Don’t forget to check out the new WALKTHROUGH.md to see how the code evolved from a simple tool to a privacy-preserving airlock.

The Shield is up. Now we need the Verdict.

We have the raw visual data from the Eye. We have the privacy shield from the Redactor. But an audit isn’t a list of findings; it’s a decision.

In our final installment of this series, The Auditor, we introduce the high-reasoning synthesis layer. We’ll explore how to combine disparate forensic streams into a single, structured verdict and implement the Guardian Pattern—a Human-in-the-Loop handshake that ensures the AI never has the final word on a $50,000 asset.

Coming Next: High-Reasoning Synthesis & The Ethics of Autonomous Verdicts.

Facebooktwitterredditlinkedinmail

The Local Eye (Sovereign Vision)

We’ve built a system that is Reliable, Affordable, and Governed. But until now, our Forensic Team has been “blind.” It could only reconcile text-based metadata.

In the world of rare book forensics, the text is only half the story. The typography, paper grain, and binding texture are the true “fingerprints.” However, sending high-resolution, proprietary scans of a $50,000 asset to a cloud-based LLM is a Data Sovereignty nightmare.

Today, we introduce The Local Eye: Edge-based Multimodal Vision that processes pixels without letting them leak into the cloud.

The Sovereignty Gap in Multimodal AI

Most multimodal implementations send raw images directly to frontier models (like GPT-4o). For an enterprise, this is a liability.

  1. Intellectual Property: Who owns the training data rights to the scan?
  2. Privacy: Does the image contain metadata or background information that violates NDAs?
  3. Cost: Sending 10MB 4K images for every query is an “Accountant’s” nightmare.

Implementing “Feature Extraction” at the Edge

Instead of sending the image to the cloud, we use Llama 3.2 Vision running locally via Ollama. Our MCP server acts as an “Airlock.”

The Handshake:
Normalization: The sharp library resizes and standardizes the forensic scan locally.
Local Inference: The Vision SLM analyzes the image and generates a text-based “Feature Map.”
Metadata Egress: Only the textual description is passed to the reasoning agents. Even if The Accountant routes the task to a Cloud model for deep analysis, the cloud only sees our description, never the pixels.

Architectural diagram of the 'Local Eye' workflow. An artifact image is processed locally using the Sharp library and Llama 3.2 Vision. Only the resulting text metadata is allowed to pass through the security airlock to cloud-based reasoning models, ensuring the original pixels never leave the local environment.
The Sovereign Vision Workflow—Extracting intelligence at the edge to prevent data leakage.

The Sovereign Vision Workflow—Extracting intelligence at the edge to prevent data leakage.
Architectural diagram of the 'Local Eye' workflow. An artifact image is processed locally using the Sharp library and Llama 3.2 Vision. Only the resulting text metadata is allowed to pass through the security airlock to cloud-based reasoning models, ensuring the original pixels never leave the local environment.

In code we might have something like this then:

// From src/index.ts: The Vision Airlock
async function analyzeArtifactVision(imagePath: string, focus: string) {
  const processedImage = await sharp(imagePath).resize(512, 512).toBuffer();

  // Local-only call to Ollama
  const description = await ollama.generate({
    model: 'llama3.2-vision',
    prompt: `Analyze the ${focus} of this artifact.`,
    images: [processedImage.toString('base64')]
  });

  return description; // Pixels stay here. Only text leaves.
}

The “Zero-Pixel” Policy

The goal is to maximize Intelligence while minimizing Exposure. By implementing Local Vision, we treat the cloud as a “Reasoning Utility,” not a “Data Store.” We send it the logic puzzle, but we never give it the raw forensic evidence. We gain the power of frontier-model reasoning without the risk of data harvesting.

Developer Lessons: The “Latency of Locality”

In building the Sovereign Vault, we learned that ‘Data Sovereignty’ has a physical cost: Time.

While a cloud-based API might analyze a 4K image in seconds, running a deep-dive OCR and visual analysis on local consumer hardware using Llama 3.2-Vision takes significantly longer. We had to tune our “Airlock” timeouts—raising the ceiling from 120 seconds to 300 seconds—to give the local “Eye” enough time to process complex handwriting on a standard CPU.

Additionally, we realized that our error logs were a potential privacy leak. We implemented Log Truncation to ensure that even our failures respect the Sovereign Vault’s privacy mandate.

The “Zero-Glue” Discovery

In a traditional setup, adding vision would require rewriting the orchestrator’s core logic. Because we use the Model Context Protocol, the orchestrator simply asked the server: “What can you do?”. The server replied with the analyze_artifact_vision manifest. The agent then dynamically decided to use this new “Eye” to investigate the Gatsby image. No new glue code was written to connect the vision model to the reasoning brain.

Case Study: The Gatsby Inscription

To test our Sovereign Vault, we ran a forensic audit on a high-value first edition of The Great Gatsby. Our local Vision Agent detected something anomalous on the title page: a cursive, multi-line inscription.

An image of The Great Gatsby copyright page
Image credit: [University of Southern Mississippi Special Collections](https://lib.usm.edu/spcol/exhibitions/item_of_the_month/iotm_june_2021.html) (June 2021 Item of the Month)

The Sovereign Trace

When we ran the analyze_artifact_vision tool, the local Llama 3.2 Vision model performed a deep scan and returned a fascinating finding:

**Visual Findings: Handwritten Inscription**
* Location: Right-hand margin of title page
* Medium: Faint pencil, cursive script
* Transcribed Content: "Then we are not alone at all when we remember that we have in our hearts that something so precious..."

Why this matters: Notice that the model didn’t just see “scribbles.” It attempted to transcribe a 40-word passage. Crucially, the Forensic Analyst (Claude) recognized that this text does not exist in any canonical version of The Great Gatsby.

This is a massive forensic win. The “Eye” identified a potential fabricated provenance or a non-standard owner intervention. Because this happened inside our “Airlock,” the specific handwriting and the non-canonical text were captured without ever touching a cloud API.

The Architect’s Trade-off: The Reasoning Gap
While our local Llama 3.2-Vision is an incredible “Eye,” it occasionally faces a Reasoning Gap. In certain runs, it may identify a note as “illegible” or produce repetitive output due to CPU thermal throttling or model constraints.

Instead of hallucinating a “clean” signature, our system is designed to Safe-Fail. It flags the finding as “Indeterminate” and triggers a High-Severity Human Authorization request.

The Governance Challenge: We now have a transcribed inscription that might contain a previous owner’s private thoughts or names. If we simply passed this output to an LLM for summarization, we would have leaked a private message to a third-party server. This discovery sets the stage for our next architectural layer: The Redactor.

Facebooktwitterredditlinkedinmail