Prompt-Injection on

My Simple Little Workflow Earned a C+

Tue, 30 Jun 2026 00:00:00 +0000

A few months ago I turned a pile of Oracle HCM PDF guides into something I could actually search. Convert each PDF to Markdown with a small tool I built, drop the Markdown into an Obsidian vault, and search it in plain language when a ticket lands. No vector database, no server, no infrastructure to babysit. It saved me real time on triage, and I wrote it up as a clean little productivity win.

Then I audited it against the same NIST standard I would use on a client system. It came back a C+. Here is why that grade is the honest one, and why the lowest-infrastructure part of the workflow turned out to be the most dangerous.

The Grade Lives in the Boring Step

When people look at this workflow, they look at Obsidian and the AI search, because that is the part that feels new. That is not where the risk is. The risk is in the step nobody looks at twice: converting a PDF.

My converter used to run on one library. Somewhere along the way I upgraded it to a newer one, IBM’s Docling, because it produced better Markdown. Better output, and a new problem I did not go looking for. Docling has a published remote-code-execution vulnerability: feed it a malicious document and it can be tricked into running code while it parses. A knowledge workflow’s entire job is to parse documents. So the one tool whose whole purpose is to ingest files I did not write is also the one carrying the sharpest edge.

That is the finding worth publishing. Not “Obsidian is scary.” The parser is scary, and the parser is the part that looked boring.

What an Honest Audit Actually Does

An audit is not a checklist you fill in to feel thorough. It is a specific method. Characterize the system, map where data and trust flow, catalog the controls that genuinely exist, work the threat scenarios, then rate the residual risk after those controls. NIST calls it SP 800-30. I ran the real thing.

The part that separates an audit from a vibe is the tool-by-tool lookup. For every named tool in the workflow, I searched live for two things: known vulnerabilities, and recent real-world incidents. Not from memory, because the threat landscape moves every week. That search is what surfaced the Docling flaw. It is also what surfaced the Ghostscript RCE that rides along in the OCR step, and the Obsidian plugin-abuse campaign that Elastic documented in April.

You can read the whole assessment for yourself: here is the full NIST SP 800-30 risk assessment , with the system characterization, the threat matrix, the per-tool vulnerability and breach lookup, and the residual risk after controls. It carries an overall grade, because a finding a hiring manager can act on needs a number, not an impression.

The Part Where the Audit Pays You Back

Here is the half of auditing that nobody talks about. It does not only find problems. It also confirms the things you did right, and it lets you say so with evidence instead of hope.

Two risks I expected to find turned out to be already handled, and the audit is what let me prove it. The Obsidian plugin-abuse campaign needs one precondition: the victim has community plugins installed and enabled. I checked the actual vault. There are no community plugins installed at all, not disabled, not present. The precondition is not met. The Ghostscript vulnerability affects versions at or below a certain release. I checked the version on my machine. It is well above the vulnerable line. Patched.

Neither of those is a guess. Each one is a fact I read off the real system and wrote into the assessment as a control in my favor. That is the difference between “I think it is fine” and “here is why it is fine, and here is what I looked at.”

Why It Is a C+ and Not an A

The letter is not a mood. It is computed from the worst residual risk the audit found, then adjusted by what is actually exploited in the wild and what controls I could verify. The Docling parser risk is High and currently open, because the dependency is unpinned and nothing in the workflow enforces that only Oracle’s own PDFs get converted. That pins the grade in the C-to-D band. The verified controls, no community plugins, a patched Ghostscript, no secret on disk, entirely local, pull it back up to a C+.

I could have made it look like an A by only describing the tidy parts. The tidy parts are real. So is the parser. A grade that ignores the parser would be the kind of clean sheet I do not trust when I see it on someone else’s work, so I will not put my name on it for my own.

What I Want You to Take From This

If you build a workflow that ingests files, audit the ingestion step first, not last. The interesting-looking parts, the AI, the search, the automation, are usually not where the exposure lives. The exposure lives in the quiet tool that opens documents you did not write. That is the one to pin, to sandbox, and to feed only from a source you trust.

The workflow still saves me time every day. I just know exactly what it costs now, down to a letter and the reasons behind it. The productivity post was the build. The audit is what made it safe to keep.

Auditing My Own Threat Briefing Tool Before I Trusted It

Mon, 29 Jun 2026 00:00:00 +0000

I found an open-source project that builds a weekly cybersecurity briefing for non-technical employees. It pulls a threat-intel newsletter, some linked articles, a bit of video commentary, sends all of it to a model, and writes out a clean HTML page you can drop on a company intranet. Useful idea. I wanted my own version, tuned for a security operations audience instead of general staff, and I wanted it as a reusable skill rather than a standalone app.

So I built it. Then, before I let myself trust it, I ran a real risk assessment on the thing I had just built. That second step is the whole point of this post, so let me start there and work backward.

The Tool Is Not the Interesting Part

The briefing generator is straightforward. It fetches the current threat intel live, the newsletter feed plus authoritative sources like the CISA Known Exploited Vulnerabilities catalog, then writes a single self-contained HTML briefing with the sections a SOC analyst actually wants: an executive summary, the week’s exploited and critical CVEs with a source link on every row, indicators of compromise, a MITRE ATT&CK mapping, and a prioritized action list. Every claim carries a source URL, and if I cannot source something, the rule is to omit it rather than invent it.

You can see one for yourself: here is an example briefing the tool produced , generated from real sources.

I made one deliberate choice that matters later. The original needs a runtime, four package dependencies, and a standing API key sitting in a file. My version needs none of that. It uses the fetch and search tools the assistant already has, so it runs with no install and no secret on disk. Hold that thought, because removing the key turned out to be a security decision, not just a convenience one.

That is the build. It is fine. It is not what I want to show you.

Auditing Your Own Build Is the Real Skill

Here is the move most people skip. When you build something that touches untrusted input, the valuable discipline is not shipping it. It is turning the same scrutiny you would aim at someone else’s system onto your own, before anyone is depending on it.

So I ran the briefing tool through a NIST SP 800-30 risk assessment, the same standard I would use to assess a client system. Not a checklist I filled in to feel thorough. An actual audit: characterize the system, map where data and trust flow, catalog the controls that genuinely exist, then work the threat scenarios honestly and rate the residual risk after those controls.

The honest finding came fast, and it was not flattering. This tool ingests untrusted, attacker-influenceable text, the newsletter body, the linked articles, the search results, and feeds it straight into an AI context, then writes an HTML file a human will open. That is the textbook setup for two problems. The first is indirect prompt injection: a poisoned article could try to steer what the briefing says. The second is stored cross-site scripting: a malicious headline could smuggle a script tag into the output HTML and run when someone opens the file. Both rated as my top risks, and both were real in the version I had just written.

This is the part I want a hiring manager or a client to see. Not a clean sheet that says everything is fine. A build where the author found the sharp edges himself and said so plainly.

You can read the whole assessment for yourself: here is the full NIST SP 800-30 risk assessment , with the system characterization, the threat matrix, a per-tool check for known vulnerabilities and recent breaches, and the residual risk after the fixes. It carries an overall grade, because a finding a hiring manager can act on needs a number, not an impression.

The Audit Has to Change the Build, or It Is Theater

A risk assessment that sits in a folder next to the tool is a document. A risk assessment that changes the tool is engineering. So the findings went straight back into the build.

The audit told me to treat every piece of fetched text as untrusted data and never as instructions, so that became a hard rule in the skill: summarize what the feed says, never obey it. It told me to escape every fetched string before writing it into HTML, so that became a rule too, with a check afterward that greps the output for an injected script tag and throws the result away if one slipped through. It told me to add a content security policy to the output so that even a missed escape cannot execute, so the template now ships with one. And the one risk I cannot fully engineer away, a model being subtly steered by poisoned input, is handled the honest way: a human reads the briefing before it goes anywhere. The tool does not get to publish itself.

The thing I shipped is not the thing I first wrote. It is the thing the audit corrected. That gap between the two is the build log.

Why the Missing API Key Was a Security Win

I mentioned I dropped the standing API key. The audit is where that paid off. A whole category of risk, a secret sitting on disk that could be read by the model or leaked into the output, simply does not exist in my version, because there is no secret to steal. Removing the four package dependencies did the same thing for supply-chain risk: libraries you do not install cannot carry a vulnerability into your tool.

This is worth saying out loud because it runs against instinct. The smaller, more boring build, no runtime, no dependencies, no key, was also the more secure one. Most of the time, security is not a feature you add. It is surface area you refuse to take on in the first place.

What I Want You to Take From This

If you are building anything that puts untrusted text in front of a model, the briefing tool is a fine pattern to copy. But copy the second half too. Build the thing, then audit your own thing against a real standard, find where it is exposed, and let the findings rewrite the build before you trust it.

The residual risk on mine, after the fixes, is low to medium and acceptable for an internal, human-reviewed briefing. I can say that with a number behind it because I did the work to earn the number, not because the tool looked clean on the surface. That is the difference between something that demos well and something you can actually run.

I did not bolt security on at the end. Auditing it was the build.