· via dev.to (home feed)
okf-guard scans documents for hidden prompt injection before AI agents ingest them
A new Python library called okf-guard inspects PDFs, Office files and HTML for invisible text and machine-directed instructions before their content reaches a knowledge base or agent context.

A developer has released okf-guard, a Python library that sits between document extraction and a trusted knowledge base, screening files for hidden text and machine-directed instructions before AI agents treat the content as fact. According to a post on dev.to, the tool targets a specific blind spot in retrieval and knowledge pipelines: everyday file formats routinely carry text a human reviewer would never see, yet extraction tools copy it verbatim along with everything else.
How hidden text reaches an agent's context
The dev.to post walks through ordinary formatting features that can conceal content. PDFs can render text in a mode that tells viewers not to display it, or set the fill color to match the page background. Word documents have an explicit hidden attribute on runs of text, independent of color or size. PowerPoint speaker notes are parsed by most extraction tools but never shown to a live audience. Spreadsheets can hide rows, columns or entire sheets, or attach comments that only appear on hover. Standard CSS properties can keep an HTML element out of a browser's rendering entirely.
None of these are exotic edge cases; they are used constantly for benign reasons like draft text, presenter notes or helper columns. The problem, the author argues, is that an extraction pipeline has no default reason to distinguish legitimate visible content from deliberately hidden content. An instruction written for a machine rather than a person — say, telling a system to approve something without further review, or to treat a claim as verified — placed in a hidden Word run gets extracted identically to the surrounding text. That makes it a variant of indirect prompt injection: the attacker plants the payload in a document that a scraper or ingestion job will later process.
The post ties this directly to Google's recently published Open Knowledge Format (OKF), which the author describes as a specification for representing organizational knowledge as Markdown files that agents read with no processing layer in between. That directness is the format's central design goal, but it also removes any opportunity to catch a problem before an agent treats the content as trustworthy — the gap okf-guard is built to fill.
What the library checks
okf-guard runs two independent inspections on every scan. The first is format-aware hidden-content detection, with an adapter for each supported format — plain text, Markdown, HTML, PDF, DOCX, PPTX and XLSX — where each adapter understands that format's specific mechanisms for hiding content from a human reader. (The post says six formats while listing seven; the listed set is what the adapters cover.)
The second is pattern-based detection of language characteristic of an instruction aimed at an AI system, plus a check for encoding-based obfuscation such as zero-width characters and homoglyph substitution. Both checks run on every scan, so content that is both hidden and phrased like an injection produces two separate findings — either signal alone is meaningful, and the combination is stronger evidence than either in isolation. A sanitize call returns an action of pass, quarantine or block, a risk score, and per-flag details covering type, location and snippet.
Deterministic by design
The release deliberately has no LLM dependency and makes no network calls. All detection is rule-based and fully deterministic, described as a considered tradeoff rather than a temporary limitation, on the grounds that a security-relevant tool should behave reproducibly and be auditable, and that a light dependency footprint matters for a library meant to be embedded in someone else's pipeline. The library also makes no claim about the accuracy of content it passes: every result carries provenance metadata marking the content as machine-processed and unverified, and nothing in the library ever asserts human review.
What v0.1.0 does not cover
The first release handles document- and web-sourced content — the categories most likely to originate outside an organization's direct control. It does not yet address structured or technical sources such as source code, API specs and database schemas; connectors for collaboration tools like Notion, Confluence and Slack; or content generated by an agent's own reasoning process. All three are planned for subsequent releases. The code is available on GitHub under darshanNhb/okf-guard, installs as a pip package with an all extra for full format support, and the injection pattern bank is explicitly designed to grow through contribution as new attack phrasing is identified.
Why it matters
Indirect prompt injection is shifting from a theoretical concern to a practical one as agents get wired directly into knowledge bases. Formats like OKF assume the ingested corpus is trustworthy, but every PDF, scraped page and spreadsheet is an input the organization did not author. okf-guard's contribution is narrow but concrete: flagging text that was hidden from human readers and phrasing aimed at machines, deterministically, at the ingestion boundary — a checkpoint that most pipelines currently lack entirely. Its limits are equally instructive. Rule-based pattern matching will miss novel phrasing, and the adapters cover office and web documents but not code, specs or chat exports. Whether deterministic screening proves sufficient or a stopgap, the boundary it occupies — the moment before untrusted content becomes trusted context — is exactly where attention in agent security is moving.
- #prompt-injection
- #security
- #open-source
- #python
- #llm-safety