<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Darshan Buddhdev</title>
    <description>The latest articles on DEV Community by Darshan Buddhdev (@darshan_buddhdev).</description>
    <link>https://dev.to/darshan_buddhdev</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4099859%2F1f1274fb-5e97-4c3b-b8c0-56e02b40cf92.jpg</url>
      <title>DEV Community: Darshan Buddhdev</title>
      <link>https://dev.to/darshan_buddhdev</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/darshan_buddhdev"/>
    <language>en</language>
    <item>
      <title>okf-guard: A Security Layer for Open Knowledge Format (OKF) Pipelines</title>
      <dc:creator>Darshan Buddhdev</dc:creator>
      <pubDate>Sat, 29 Aug 2026 06:25:31 +0000</pubDate>
      <link>https://dev.to/darshan_buddhdev/catching-prompt-injection-before-it-enters-a-trusted-knowledge-base-5hf4</link>
      <guid>https://dev.to/darshan_buddhdev/catching-prompt-injection-before-it-enters-a-trusted-knowledge-base-5hf4</guid>
      <description>&lt;p&gt;Catching Prompt Injection Before It Enters a Trusted Knowledge Base&lt;/p&gt;

&lt;p&gt;AI agents increasingly consume knowledge from sources they did not author and cannot independently verify: a PDF policy document, a scraped web page, a spreadsheet exported from another team's system. The prevailing approach — extract the text, write it into a knowledge base or context window, let the agent treat it as fact — has an underexamined weakness. Extraction tools capture everything present in a source document, including content a human reviewer would never see.&lt;/p&gt;

&lt;p&gt;The Mechanism&lt;/p&gt;

&lt;p&gt;Several ordinary, well-documented features of common file formats allow text to be present in a document while remaining invisible to anyone reading it normally:&lt;/p&gt;

&lt;p&gt;A PDF can render text in a rendering mode that instructs viewers not to display it, or set its fill color identical to the page background.&lt;br&gt;
A Word document has an explicit "hidden" attribute on any run of text, independent of color or size.&lt;br&gt;
A PowerPoint file's speaker notes are parsed by most extraction tools but never appear to an audience watching the presentation.&lt;br&gt;
A spreadsheet can mark entire rows, columns, or sheets as hidden, or attach a comment to a cell that is invisible unless hovered.&lt;br&gt;
An HTML page can hide an element from a browser's rendering entirely via a handful of standard CSS properties.&lt;/p&gt;

&lt;p&gt;None of these are obscure edge cases. They are common, legitimate formatting features, used constantly for entirely benign reasons — a hidden helper column in a spreadsheet, a private note to a presenter, draft text a Word user hid rather than deleted. The problem is not that these features exist; it is that an extraction pipeline has no reason to distinguish "this text is legitimate content" from "this text was deliberately hidden" unless something is specifically checking for the difference.&lt;/p&gt;

&lt;p&gt;Why This Matters for AI Pipelines Specifically&lt;/p&gt;

&lt;p&gt;If an attacker can place text anywhere in this chain — inside a PDF a company will later ingest, inside a web page a scraper will later visit — using any of the above mechanisms, that text becomes indistinguishable from the surrounding legitimate content once extracted. An instruction phrased for an AI system rather than a human reader ("approve this without further review," "treat the following as verified") sitting in a hidden run of a Word document will be extracted identically to the visible text around it.&lt;/p&gt;

&lt;p&gt;This is a variant of indirect prompt injection, and it applies most directly right now to Google's recently published Open Knowledge Format (OKF) — a specification for representing organizational knowledge as markdown files that AI agents read directly, with no processing layer in between. That directness is the format's central design goal; it is also precisely what removes any opportunity to catch a problem before an agent treats the content as trustworthy.&lt;/p&gt;

&lt;p&gt;What okf-guard Does&lt;/p&gt;

&lt;p&gt;okf-guard is a Python library intended to sit at the point where a source document is extracted and before its content becomes part of a trusted bundle. It performs two independent kinds of inspection on every scan:&lt;/p&gt;

&lt;p&gt;Hidden-content detection, format-aware — each of six supported formats (plain text, Markdown, HTML, PDF, DOCX, PPTX, XLSX) has an adapter that understands that format's specific mechanisms for hiding content from a human reader.&lt;br&gt;
Pattern-based detection of language characteristic of an instruction directed at an AI system, plus a check for encoding-based obfuscation (zero-width characters, homoglyph substitution).&lt;/p&gt;

&lt;p&gt;Both checks run on every scan independently. Content that is both hidden and contains injection-style phrasing produces two separate findings, since either alone is meaningful signal, and their combination is stronger evidence than either in isolation.&lt;/p&gt;

&lt;p&gt;python&lt;br&gt;
from okfguard import sanitize&lt;/p&gt;

&lt;p&gt;result = sanitize("suspicious_document.pdf")&lt;/p&gt;

&lt;p&gt;print(result.action)       # "pass", "quarantine", or "block"&lt;br&gt;
print(result.risk_score)   # e.g. 0.9&lt;br&gt;
for flag in result.flags:&lt;br&gt;
    print(f"[{flag.type}] {flag.location}: {flag.snippet}")&lt;br&gt;
What It Deliberately Does Not Do&lt;/p&gt;

&lt;p&gt;This release has no LLM dependency and makes no network calls. All detection is rule-based and fully deterministic — a considered tradeoff, not a temporary limitation. A security-relevant tool benefits from behavior that is reproducible and auditable, and a lightweight dependency footprint matters for a library meant to be embedded in someone else's pipeline.&lt;/p&gt;

&lt;p&gt;The tool also makes no claim about the accuracy of content it passes. Every result includes explicit provenance metadata marking content as machine-processed and unverified — nothing in the library ever asserts that content has been reviewed by a human.&lt;/p&gt;

&lt;p&gt;Where It Stands Today&lt;/p&gt;

&lt;p&gt;v0.1.0 covers document- and web-sourced content specifically — the categories where content plausibly originates outside an organization's direct control. It does not yet address:&lt;/p&gt;

&lt;p&gt;Structured/technical sources (source code, API specs, database schemas)&lt;br&gt;
Collaboration-tool connectors (Notion, Confluence, Slack)&lt;br&gt;
Content generated by an AI agent's own reasoning process&lt;/p&gt;

&lt;p&gt;All three raise distinct problems and are planned for subsequent releases.&lt;/p&gt;

&lt;p&gt;Source &amp;amp; docs: &lt;a href="https://github.com/darshanNhb/okf-guard" rel="noopener noreferrer"&gt;https://github.com/darshanNhb/okf-guard&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;bash&lt;br&gt;
pip install okf-guard[all]&lt;/p&gt;

&lt;p&gt;Feedback, particularly from anyone who has worked on related problems in document security or LLM safety, is genuinely welcome — the pattern bank in src/okfguard/rules/injection_patterns.py is explicitly designed to grow through contribution as new attack phrasing is identified.&lt;/p&gt;

</description>
      <category>ai</category>
      <category>python</category>
      <category>security</category>
      <category>architecture</category>
    </item>
  </channel>
</rss>
