DEV Community: Noel Himer

I gave my AI workers a cited knowledgebase so they'd stop guessing

Noel Himer — Thu, 18 Jun 2026 21:25:01 +0000

My agents were confidently wrong about the world, and I couldn't tell when. That's the part that got to me — not the wrongness, the confidence.

I run my one-person company as a fleet of about twenty AI agents — a content writer, a finance one, a researcher, a security officer, a handful more. They're good at the work I built them for. But every one of them shares a flaw I'd been papering over: when a task needs a fact about the world — how a tax threshold works, what a marketing framework actually says, how a platform bills — the model reaches into its training data and answers in the exact same self-assured tone whether it knows or is improvising. There is no tell. The guess and the fact wear the same face.

So this month I built the thing that was missing: a cited, fact-checked knowledgebase the agents have to read before they work, with a gate that keeps me from poisoning my own source of truth. Here's how it's built, the one rule that turned out to matter most, and the honest state of it — which is that I finished it days ago and have no idea yet whether it changes the work.

The job I was actually hiring this to do

Strip away my setup and the problem is one any solo operator using AI already has. You ask the model for something that depends on a real fact. It answers fluently. You either know enough to catch the error or you don't — and the whole reason you're asking is usually that you don't. The job I needed done wasn't "make my agents smarter." It was narrower and more honest: stop my AI from making things up in the one register where I can't catch it, and let me know which claims I can actually trust.

The competition for that job, in my shop, was "just let the model wing it and hope." That had already cost me. A marketing analysis once understated a channel's numbers because an agent trusted a stale figure instead of pulling the live one. Small, recoverable — but it's the recoverable ones you see. The ones you don't see are the ones that scare you.

What I built

It's a region of my notes vault I call the 10-Library — the factual half, deliberately walled off from the operational logbook (sessions, decisions, day-to-day state). One test decides what's allowed in: "Would this still be true if my company vanished tomorrow?" A fact about a copywriting framework: yes, it lives here. A fact about my own revenue: no, that's operational memory. The Library only holds world-true things.

The concrete shape, as of today:

110 notes, each one atomic — a single concept, not a topic dump — across five categories so far: infrastructure, Linux, networking, distribution (marketing), and freelancing.
Claim-level sourcing. Every factual sentence carries an inline citation to where it came from. No source, no entry. A note without a footnote isn't a Library fact; it's an opinion, and it doesn't get to sit in the source of truth.
A quarantine. New facts — researched from the web on a schedule, or pulled on demand when an agent hits a gap — don't land in the trusted set. They land in a _quarantine folder marked auto-unverified, and they stay invisible to the agents until I read them and promote them by hand. Right now there's exactly one note sitting in quarantine, waiting on me.

The notes are distilled from sources I'd actually defend — accredited course material and primary references, not a model free-associating about itself. The marketing notes I leaned on to write this very essay, for instance, cite Ogilvy's own books and a 1994 psychology paper, not a listicle.

The one rule that mattered most

If I keep only one sentence from this build, it's this: the agent reads the knowledgebase, but the agent never gets to silently rewrite it.

This sounds like bureaucratic caution. It's the opposite — it's the thing that keeps the whole structure from rotting. There's a documented failure mode where a language model asked to re-verify its own knowledge base will quietly degrade correct facts and ratify its own errors, all while looking like diligent maintenance. An AI grading its own homework drifts, and drifts confidently. So in my Library, automated re-checking is advisory and append-only: it can flag a note as stale or contradicted, it can stage a proposed change for me to look at — but it cannot overwrite a single fact on its own. The human promote step is not a nicety. It's the load-bearing wall.

The second half of the same rule: ingested web content is treated as data, never instructions. A note pulled from the internet can inform an answer; it can never trigger an action — no write, no tool call, no spend — without me confirming first. That single boundary quietly closes off the nightmare where someone poisons a web page my researcher reads and my fleet starts acting on the poison. The agents read the world. They don't take orders from it.

What this is not

It is not RAG-makes-the-AI-correct. A knowledgebase doesn't make a model truthful; it gives me a bounded, citable place where I've decided what's true, so that for the facts that matter I'm relying on something I vetted instead of something the model felt confident about. The gap between those two is the entire point. Outside the Library, my agents are exactly as fallible as yours. Inside it, at least, when one cites a fact I can click the footnote.

And it is brand new. I'm not going to tell you it made the fleet measurably better, because I genuinely don't know yet — it's been live for days, not months. What I can tell you is the failure it's designed to stop is real, I've been bitten by the cheap version of it, and the design is the one I'd defend: read before you work, cite every claim, and never let the machine quietly edit the truth.

The honest status, as always

This is the part of every one of these I refuse to skip, because the honesty is the actual product. Revenue is still zero. The audience is still tiny. The knowledgebase I just described was built this week — 110 notes is a respectable start and also nowhere near a finished reference; whole categories I sketched are still empty. The most alive thing in the whole operation remains the operating system itself plus one warm commission: a small desktop app I'm making for my mother, who'll pass it by word of mouth to the people she works with.

So treat this as a build log, not a victory lap. I built a cited knowledgebase so my AI workers would stop guessing in the register where I can't catch them, and I wired in the one rule — read it, don't rewrite it — that keeps me from becoming the thing that corrupts it. Whether it earns its keep, I'll find out in public and tell you either way.

If you use AI for anything load-bearing, here's the cheap version you can steal today: keep one file of facts you've personally checked, cite where each came from, point the model at it before it answers, and never let it edit that file without you reading the change. You don't need a vault or twenty agents. You need a place where "true" means you decided it, not the model.

I write up the operating system one piece at a time — the agent wiring, the failures, the rules I reverse — in Unbearable TechTips Weekly. It's practical homelab and agent ops, the real status included. If the mess is useful to you, that's where the specifics live.

— Noel @ Unbearable Labs

I run my one-person company as a ~20-agent AI org. Here's what broke.

Noel Himer — Thu, 04 Jun 2026 14:04:19 +0000

I'm a solo operator — no employees, no co-founder. But I don't really work alone anymore. I work as the human in the loop of a small org made of about twenty specialized AI agents, each with a job, a name, and a list of things it is explicitly not allowed to do.

This isn't a "10x your output with AI" post. The most valuable thing the setup taught me is that I'd spent weeks building the wrong things — I'll get to that. But first the shape, because people keep asking what "running your company with agents" actually means once you get past the screenshots.

The shape

A chief-of-staff agent runs every morning and writes me a brief: what shipped in the last 24 hours, what's gone stale, what's about to cross a limit I set. A finance agent knows my tax situation. A security officer scans for leaked secrets before anything gets committed. A researcher validates ideas — and is deliberately rate-limited, so it can't start a new investigation until the last one produced something real. A shipper scaffolds and deploys. There's a content lead, a publisher, an archivist, and a dozen more.

They share three things: one task backlog that is the single source of truth for what's being worked on, a written knowledge vault so the next agent — or the next session — inherits full context instead of starting blind, and a set of real tools behind one endpoint, so an agent can actually do things rather than just describe them.

Over the top sits a console I built called URSA. It's the cockpit — live status, and a voice. Literally a voice: it speaks to me in two languages, and it interrupts me, unprompted, when a number I told it to watch goes the wrong way.

Two rules hold the whole thing together. Anything that spends money, publishes to the world, or touches an account stops and asks me first. And every product gets a kill threshold the day it ships — a pre-committed number and date at which I walk away — so a thing that isn't working can't quietly absorb my attention forever.

What broke

Three things, in order of how much they taught me.

One: an agent hung for eight hours. I asked a build agent to test a service. Instead of starting it in the background and probing it, it ran the server in the foreground — then sat there, blocked, holding the process open for 472 minutes, spawning orphans the entire time. The lesson is now a rule: an agent must never foreground-run a daemon, and the orchestrator has to watchdog its workers on a timer. Agents fail in ways a human just wouldn't.

Two: a config file got silently overwritten. For a stretch, builds were mysteriously breaking. The cause: an agent had written test-fixture content directly over a real Dockerfile, and nothing caught it because that directory wasn't even tracked. The fix was a guard that hashes the file and fails the commit if it changed unexpectedly. The deeper lesson: agents need guardrails that fail loudly, at the moment of the mistake — not a code review three steps downstream.

Three — the expensive one: I built seven products before a single person asked for one. This is the one I'm still sitting with. My fleet is good at building. In a few weeks it shipped seven real tools — tested, deployed, the works. And I use them. But I built every one because the market looked like it was there, never because a real person pulled it out of me. Meanwhile the only things that feel genuinely valuable are the internal tools — the console, the org itself — which exist because I actually needed them.

The pattern took me embarrassingly long to see: everything I built from a push ("this looks like a market") came out hollow. Everything I built from a pull (a need I already had) came out alive. So I made the org enforce it. There's now a gate every new build has to clear before it gets any of my time, and its first question is the one I'd been skipping — who pulled this? One of my agents is read-only and exists for essentially that purpose: to tell me no.

If you want to try this yourself

You don't need twenty agents. Almost all of the value came from four prompt patterns, and they fit inside a single system prompt — paste them into whatever AI you already use.

1. Give it a role and a "never" list. The negative space does more work than the instructions. What makes an agent safe isn't what you tell it to do — it's what you forbid.

You are my [role]. Before any action, check it against these hard limits: never spend money, publish anything public, or touch an account without stopping to ask me first. If a task would cross one of those lines, stop and surface it instead of proceeding.

2. Make it argue back before it builds. My single most useful agent is read-only and exists to say no. You can bake the same reflex into one prompt:

Before you build, fix, or write anything, ask one question first: who actually asked for this? If the honest answer is "no one, it just seems like a good idea," say so and push back before doing the work. Default to "let's validate first," never "let's build."

3. Give it a memory it reads before it starts. Keep one file of state — what you're working on, what's decided, what you've already tried — and begin every session by pointing the AI at it. Context that lives in a file survives; context that lives in a chat window dies when you close it.

At the start of every session, read STATE.md before doing anything. Whenever something is decided or changes, write it back. Never make me repeat myself.

4. Pre-commit the kill line. The discipline that's saved me the most: decide the failure condition before you start, not after you're attached.

For anything we start, write down now the condition under which we stop — a number and a date. When we hit it, remind me and make me defend continuing.

That's the spine. Twenty specialized agents with real tools is just this, scaled out — but the four patterns are the part that actually changed how I work.

What I still don't know

Whether any of this is a business, or just an elaborate and deeply satisfying way to run a one-person shop. Right now I have a fleet of tools I use every day and a customer count I'm still working on. That's the honest status. I'm betting the discipline I just bolted on is what turns the second number — but I don't know yet, and I'd rather say that than pretend.

If the wiring behind any of this is interesting to you — how the agents coordinate, how the console got a voice, how the kill thresholds actually fire — that's what I write up, one build at a time, in Unbearable TechTips Weekly. The architecture's there, the war-stories are there, and I'm figuring out the rest in public.

— Noel, Unbearable Labs

Two supply-chain attacks in one week — here's what to actually fix in your CI

Noel Himer — Tue, 02 Jun 2026 18:06:35 +0000

On May 18, 2026, between 11:36 and 17:48 UTC, the TeamPCP threat group compromised 5,561 public GitHub repositories in six hours. They pushed malicious GitHub Actions workflows via stolen developer credentials — injecting new workflows or replacing existing ones with dormant workflow_dispatch backdoors. Every repository that ran those workflows handed over whatever secrets the CI environment held: AWS keys, GCP tokens, SSH keys, Docker auth configs, Kubernetes credentials. (SecurityWeek, SafeDep, CSA Labs.)

Ten days later: Microsoft published a report on 14 typosquatted npm packages, stealing cloud and CI/CD secrets via malicious postinstall scripts. Different actor, same threat category. (Microsoft Security Blog.)

Both attacks exploited structural misconfigurations that exist in most GitHub Actions setups today. Not zero-days. Configuration patterns that look completely normal to anyone who learned CI/CD from the standard tutorials.

This post covers what those patterns are and how to fix them. The five fixes are free. At the end I'll mention a starter kit that implements them — but the fixes work regardless.

The EU CRA angle: this is now a compliance problem too

The EU Cyber Resilience Act enters its reporting obligations phase in September 2026. Article 13 requires manufacturers of "products with digital elements" to document a software bill of materials and maintain verifiable build provenance. Mutable GitHub Actions tags (@v4, @main) produce builds you cannot verify after the fact — you cannot prove which code ran.

SHA-pinned actions plus SLSA provenance attestation (Fix 3 below includes this) is how you produce a build you can actually audit. If you ship software to EU customers, these fixes are not just security hygiene. They are the start of a compliance trail.

The two misconfigurations that made Megalodon work

Megalodon's payload executed because of two conditions: (1) the attacker could push a workflow file into the repository, and (2) when it ran, it had access to secrets. The stolen credentials angle is an endpoint problem CI hardening cannot solve. But the CI side has real mitigations.

Mutable action refs gave attackers a template to work from.

Most workflows look like this:

steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-python@v5
  - uses: some-third-party/action@v2.1

@v4, @v5, @v2.1 are tags. Tags are mutable. A publisher can update what a tag points to at any time. Preceding Megalodon, TeamPCP had already demonstrated the technique: force-pushing malicious commits to tag refs on popular action repos, causing downstream consumers to execute attacker code on their next CI run.

permissions: write-all gave the attacker the run of the house.

If a workflow has broad permissions and an attacker can inject a step — via a compromised action, via a pull_request_target misconfiguration, or via stolen credentials — that injected step has the same permissions as the workflow. If the workflow has permissions: write-all, the attacker can push code, create releases, and exfiltrate every secret in scope.

Fix 1: SHA-pin your actions

The only immutable ref format is a 40-character commit SHA:

steps:
  # Before:
  - uses: actions/checkout@v4

  # After:
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2

The SHA cannot be retroactively changed. Your workflow runs the pinned version until you explicitly update.

Finding the correct SHA:

gh api repos/actions/checkout/git/refs/tags/v4.2.2 \
  --jq '.object.sha'

Staying current without manual SHA hunting: add Dependabot for GitHub Actions to .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    commit-message:
      prefix: "ci(deps)"

Dependabot opens PRs when new action versions ship. Review the diff, merge, done.

Fix 2: Scope your permissions

Set a read-only default at the workflow level, expand per-job where needed:

# Top of every workflow file:
permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    # Read-only inherited — nothing to add

  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      deployments: write
    steps:
      # ... deploy steps

If an attacker injects a step into test, it has read-only access. It cannot push code or exfiltrate secrets via repository writes. Two minutes per workflow. Highest value-to-effort of the five fixes.

Fix 3: Eliminate `pull_request_target` + checkout by PR SHA

pull_request_target runs with the base repository's permissions and secrets, even when triggered by a fork's PR. Combined with checking out the PR's code:

# THIS IS DANGEROUS — do not use:
on: pull_request_target

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<sha>
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # attacker-controlled
      - run: npm install  # runs attacker code with your secrets

Anyone who opens a PR from a fork controls what checkout retrieves. Use pull_request (not pull_request_target) for standard CI. If you need pull_request_target for auto-labeling, do not checkout the PR head code in the same job.

Fix 4: Move event context values through `env:` before using in `run:`

# Before (dangerous — script injection possible):
- name: Process PR
  run: echo "PR by: ${{ github.event.pull_request.user.login }}"

# After (safe):
- name: Process PR
  env:
    PR_USER: ${{ github.event.pull_request.user.login }}
  run: echo "PR by: $PR_USER"

github.event.pull_request.user.login is attacker-controlled. Direct interpolation into run: allows shell metacharacter injection. The same applies to pull_request.title, pull_request.body, issue.title, head_commit.message, and any other user-controlled webhook payload value.

Fix 5: Audit npm dependencies for postinstall scripts

The May 28 Microsoft report is a reminder that npm install in CI is a supply-chain boundary. All 14 malicious packages used postinstall scripts to exfiltrate credentials — scripts that run automatically during npm install with no confirmation.

# Lockfile-exact install, no drift:
npm ci

# Disable postinstall for trusted-dependency installs:
npm install --ignore-scripts

# Audit which packages in your tree have postinstall scripts:
npm ls --parseable | xargs -I{} node -e "
  try {
    const p = require('{}/package.json');
    if (p.scripts && p.scripts.postinstall) {
      console.log('postinstall found in:', '{}');
    }
  } catch(e) {}
"

--ignore-scripts breaks packages that need postinstall to compile native extensions. In that case, review and explicitly allow those specific packages rather than turning the flag off globally.

What these five fixes add up to

SHA-pinned actions, scoped permissions, no pull_request_target + checkout misuse, env: for event context, and postinstall awareness do not make your CI invulnerable. They remove the structural misconfigurations that make attacks like Megalodon consequential.

If an attacker pushes a malicious workflow (via stolen credentials — the endpoint problem), a SHA-pinned, permission-scoped workflow limits what it can do when it runs. That is the goal.

The starter kit (coming soon)

These five fixes — plus Trivy scanning, cosign keyless image signing, SLSA Level 1 provenance attestation, TruffleHog secret scanning on PRs, and a scheduled Dependabot config — are what I'm packaging into ready-to-paste GitHub Actions workflow templates.

What's planned for the pack:

ci-base-hardened.yml — minimal hardened starter for any stack
ci-node-hardened.yml — Node.js with npm ci, postinstall audit, npm audit gate
ci-python-hardened.yml — Python with pip-audit against OSV + PyPI advisory DB
ci-docker-hardened.yml — Docker build with Trivy scan, cosign keyless signing, SBOM attestation
ci-release-hardened.yml — release workflow with SLSA Level 1 provenance
ci-pr-gate.yml — PR gate with dependency-review, TruffleHog, mutable-ref detector
ci-schedule-audit.yml — weekly scheduled audit via the github-actions-audit MCP tool
dependabot-actions.yml — keeps SHA pins current via automated PRs
security-policy-template.md — SECURITY.md so researchers don't open public issues

Drop them into .github/workflows/, follow the per-file setup instructions, and you'd have a hardened baseline in under an hour. It'll be €19, one payment, no subscription — but it's not out yet. I'm gauging interest before I finish it: claim a free spot and I'll send one email the day it ships, plus early-bird pricing for list members.

Join the free early-access list →

Built by Noel @ Unbearable Labs. The newsletter covers practical homelab and agent ops — weekly, no filler.

I shipped 7 production MCP server Actors in two weeks — here's what the docs don't tell you

Noel Himer — Tue, 02 Jun 2026 17:41:16 +0000

I shipped 7 production MCP server Actors in two weeks — here's what the docs don't tell you

The first Actor took most of a day. The seventh took under two hours. The delta wasn't clever abstractions or a better framework. It was the institutional knowledge that accumulates after you've hit every silent failure mode that Apify's documentation doesn't mention.

This post covers the patterns that mattered. All of it works whether you buy anything at the end or not.

The stack: what "MCP Actor on Apify" actually means

Apify's Standby mode lets you run a persistent Python process that accepts HTTP connections. Combine that with FastMCP and you get an MCP server at a stable public URL, billed per tool call rather than per minute. The Standby URL format is:

https://<username-hyphenated>--<actor-name>.apify.actor/mcp

So unbearable-dev--docker-compose-audit.apify.actor/mcp is the live MCP endpoint for my docker-compose audit Actor. Any MCP client — Claude Desktop, Cursor, n8n, the Smithery gateway — can point at it directly.

The basic scaffold is straightforward. The gotchas are not.

Gotcha 1: `webServerMcpPath` — the silent routing killer

Your actor.json controls how Apify routes MCP traffic to your Standby process. The relevant field is webServerMcpPath:

{
  "usesStandbyMode": true,
  "webServerMcpPath": "/mcp"
}

If this field is absent, misspelled, or set to anything other than the path your FastMCP server actually mounts at, you'll see the Actor status as "Running" in the Apify Console, the Standby URL will return a 404, and your MCP client will report a connection error. The Actor logs show a healthy process. Nothing in the logs points to the routing config.

The field appears in one sentence in the Apify Standby documentation. It's easy to miss, easy to typo, and the failure mode is confusing because the Actor looks healthy from the outside.

Fix: webServerMcpPath must match the path argument you pass to FastMCP. If your server mounts at /mcp, the field must be /mcp. Lock them together and verify on first deploy with a curl to the Standby URL.

Gotcha 2: A 406 on `/mcp` is a PASS, not a failure

When you smoke-test a new Actor with a basic curl:

curl -s -o /dev/null -w "%{http_code}" \
  https://unbearable-dev--docker-compose-audit.apify.actor/mcp

You get back 406. First time I saw it I thought the routing was broken. It's not.

406 Not Acceptable means the server received the request, understood the path, and rejected it because the client sent no Accept header specifying an MCP-compatible content type. The server is up. The MCP path is correct. The smoke test passes when you get a 406.

A 404 means the path is wrong (see gotcha 1). A 503 means the Actor isn't running yet. A 406 is the health check you want.

The correct smoke test for a raw Standby endpoint:

# Expect 406 — this is the passing state
curl -s -i https://<actor-standby-url>/mcp | head -1
# HTTP/2 406

# Full MCP session test — expect {"result": {"tools": [...]}}
curl -s -X POST \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  https://<actor-standby-url>/mcp \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

The second call is the real smoke test. Empty tools array means your server is up but your tool registrations are not attached. Which brings us to gotcha 3.

Gotcha 3: `get_server()` scope and the zero-tool server

FastMCP's pattern for Apify Standby looks like this:

from fastmcp import FastMCP

def get_server() -> FastMCP:
    server = FastMCP("my-actor")
    return server

# Don't do this:
@server.tool()
async def my_tool(content: str) -> str:
    ...

If you define tools outside the get_server() function using the @server.tool() decorator, they register against a different server instance than the one get_server() returns. The Apify Standby framework calls get_server() to get the server it will serve. Tools registered at module scope against a different instance are unreachable.

tools/list returns an empty array. No error. No log entry. The Actor runs fine.

The fix:

def get_server() -> FastMCP:
    server = FastMCP("my-actor")

    @server.tool()
    async def my_tool(content: str) -> str:
        """Run my tool."""
        return do_the_work(content)

    return server

Everything that needs to be reachable goes inside get_server(). The returned instance is what gets served.

Gotcha 4: PPE economics post-April 2026

Apify retired rental pricing on April 1, 2026. Pay-per-event is now the only billing model for new Actors. The economics are better than they look.

Every Apify user gets $5/month in free platform credits. At $0.02 per audit call, that's 250 free calls per user per month. The first dollar only flows after a user's free credits are exhausted. Solo developers and hobbyists may never pay — you're pricing for team and enterprise users whose credit buffers get consumed by actual volume.

The pay_per_event.json schema ships in .actor/pay_per_event.json:

{
  "light-read": {
    "eventTitle": "List / lookup call",
    "eventDescription": "Charged for catalog, list, or lookup tool calls.",
    "eventPriceUsd": 0.005
  },
  "heavy-call": {
    "eventTitle": "Analysis / audit call",
    "eventDescription": "Charged per primary tool call.",
    "eventPriceUsd": 0.02
  }
}

Two tiers at a 4:1 ratio: cheap discovery, billable execution. Structure your tool catalog so list_checks, list_rules, and schema-query tools fire light-read events; analysis and audit tools fire heavy-call events.

The Actor.charge() call goes before your logic, not after:

async def audit_dockerfile(content: str) -> dict:
    await Actor.charge("heavy-call")   # charge first
    results = run_audit(content)       # then do the work
    return results

If your logic raises an exception, the charge record still exists. Billing is accurate even on errors. If you charge after the work, a raised exception means an unbilled call — the platform economics break down at volume.

The pay_per_event.json placement gotcha: the file goes in .actor/pay_per_event.json, not the project root. If it's in the wrong location, Actor.charge() executes without raising an error, but no billing event is recorded. No exception, no log entry, nothing on the Apify billing dashboard. The Actor runs correctly. You just aren't billing for it.

The startedAt field in your PPE config must be at least 14 days from your push date. Setting it closer returns a 403 cannot-modify-actor-pricing-with-immediate-effect error. Set it 15–20 days out to be safe.

Gotcha 5: The Dockerfile clobber guard

AI coding agents — Cursor, Claude Code — occasionally write to Dockerfile when they mean to write to a test fixture or a scratch file. apify push uses whatever Dockerfile is in the project root at push time. If the clobber happened before the push, your build uses the wrong base image, exits immediately, and the build logs point at dependency errors rather than the source problem.

The fix: store a SHA-256 hash of Dockerfile in Dockerfile.sha256 and verify it in a pre-commit hook.

Generate the hash:

# On Linux/Mac:
sha256sum Dockerfile | awk '{print $1}' > Dockerfile.sha256

# On Windows (PowerShell):
(Get-FileHash Dockerfile -Algorithm SHA256).Hash.ToLower() | Set-Content Dockerfile.sha256

Pre-commit hook (.git/hooks/pre-commit):

#!/bin/sh
STORED=$(cat Dockerfile.sha256)
ACTUAL=$(sha256sum Dockerfile | awk '{print $1}')
if [ "$STORED" != "$ACTUAL" ]; then
  echo "ERROR: Dockerfile has changed since Dockerfile.sha256 was generated."
  echo "  Stored:  $STORED"
  echo "  Actual:  $ACTUAL"
  echo "If the change is intentional: sha256sum Dockerfile | awk '{print \$1}' > Dockerfile.sha256"
  exit 1
fi

When an agent rewrites Dockerfile accidentally, the hook catches it before the commit lands. Update Dockerfile.sha256 manually when you intentionally change the base image or build steps.

The scaffold at python-mcp-empty-plus ships with Dockerfile.sha256 already set to the correct hash for the default image (apify/actor-python:3.14).

Gotcha 6: Fix-snippet generation — what MCP clients can actually consume

Audit-style Actors return a list of findings. The naive return format is a wall of text or a raw diff. Neither is useful in an agentic workflow.

The pattern that works: a structured response envelope with a machine-readable fixes array.

from typing import TypedDict

class Fix(TypedDict):
    rule_id: str
    severity: str          # "error" | "warning" | "info"
    description: str
    fix_snippet: str       # the corrected content, ready to write
    line_range: list[int]  # [start, end] line numbers

class AuditResult(TypedDict):
    passed: bool
    issue_count: int
    fixes: list[Fix]

The fix_snippet field carries the corrected content, not a description of what to change. An MCP client driving Claude Desktop can write the fix snippet directly to the file. A diff description requires the agent to derive the edit — an extra round trip and a source of hallucination.

The RULE_MAP pattern separates rule definitions from audit logic:

RULE_MAP = {
    "DF-001": {
        "title": "Use specific base image tag",
        "severity": "error",
        "check": lambda layers: not any(":latest" in l for l in layers),
        "fix_template": "FROM {image}:{pinned_tag}",
    },
    # ...
}

Rules as data, not conditionals. Adding a new check is one dict entry. The audit loop iterates RULE_MAP and populates fixes. Clean separation means you can test each rule in isolation without running a full audit.

What the 7 production Actors look like

The Actors live on the Apify Store under unbearable-dev:

docker-compose-audit — 25 checks across 9 categories (security, networking, resource limits, image policy, restart policy, secrets management, health checks, logging, compose-file best practices)
dockerfile-audit — 19 checks across 5 categories (base image, build hygiene, layer efficiency, secrets, user privilege)
github-actions-audit — 21 checks across 6 categories (action pinning, permission scoping, secret hygiene, event trigger misconfigurations, dependency audit, SLSA provenance)
k8s-manifest-audit — 63 checks across 7 categories (Deployment, Service, RBAC, NetworkPolicy, PodSecurity, and more)
iac-audit-pack — the composite: all 4 domains, 131 checks, 43 tools in one Actor
hu-postcode-validator — 5 utility tools backed by the Hungarian postal code dataset
szamlazz-mcp — 8 tools wrapping the Számlázz.hu invoicing API, BYO-API-key

Most of them are also wired into a self-hosted HTTP multiplexer on the Pi (unbearable-mcp at port 8700) that exposes them behind a single MCP endpoint. The Smithery catalog lists them individually with a gateway parameter that routes to the right Actor.

The boilerplate I ended up with

After Actor 4, the setup was stable enough to extract. The scaffold (python-mcp-empty-plus) is on GitHub — it's the structure without the explanations:

actor.json with webServerMcpPath already set
Dockerfile pinned to apify/actor-python:3.14
Dockerfile.sha256 for the clobber guard
.actor/pay_per_event.json with the two-tier template and the PPE gotchas documented inline
requirements.txt with fastmcp and apify-client
src/main.py with the get_server() pattern and a stub tool
scripts/smoke.sh — the three-tier smoke test (unit → python -m → curl /mcp)
Pre-commit hook wired in

The 8-doc pack is the explanations. It covers every pattern in this post in full, with the markdown-linter-mcp example Actor worked through from scaffold to Smithery listing. That Actor is ~200 lines, fully functional, 5 tools, PPE configured. The source ships with the pack.

The docs:

Quickstart — zero to Standby endpoint in one session
Check-catalog pattern — list_checks tool structure and how it shapes PPE billing
Fix-snippet generation — response envelope, RULE_MAP, why raw diffs break MCP clients
PPE economics post-April 2026 — two-tier design, Actor.charge() placement, break-even math
Standby URL and cold-start behavior — URL anatomy, Bearer auth, session tracking middleware
Smoke testing — three-tier harness and what each tier catches
Dockerfile clobber guard — the SHA-256 approach and the pre-commit hook
Troubleshooting — 15 failure modes with exact error messages and fixes

If you've read this far and the patterns above saved you time, the pack is €49 at unbearable0.gumroad.com/l/mcp-server-boilerplate-pack. One payment, immediate download, 14-day refund.

If you're not at the "buy a doc pack" stage yet, the free scaffold is at github.com/UnbearableDev/python-mcp-empty-plus. It gets you past the blank-slate problem. The gotchas above are free either way.

Built by Noel @ Unbearable Labs — practical homelab and agent ops. The newsletter is weekly, no filler.

If you use Trivy or KICS in CI, read this

Noel Himer — Thu, 28 May 2026 17:44:24 +0000

75 of 76 trivy-action tags hijacked in five days. The pattern, three checks, and what to automate.

Hey —

Between March 19 and March 24, 2026, the "TeamPCP" actor force-pushed mutable tags on three popular security-tool repos. 75 of 76 trivy-action tags plus 7 setup-trivy tags went first. Four days later, all 91 Checkmarx KICS action tags were repointed. The same group landed malicious LiteLLM builds on PyPI on the 24th. Every CI pipeline pinned to @v0, @main, or @latest on those actions ran attacker code on its next build.

The injected payload was not subtle: it scraped the hosted GitHub runner's process memory for variables marked isSecret: true, swept the filesystem for SSH keys and cloud credentials, encrypted everything with AES-256-CBC + RSA-4096, and exfiltrated it.

If you used Trivy or KICS in CI without a SHA pin, assume those secrets are gone. Rotate, then come back to this email.

The mechanism in one paragraph

A GitHub Actions reference like uses: aquasecurity/trivy-action@v0 is just a pointer to a git ref. Anyone with push to that repo — including an attacker who steals a maintainer token — can git tag -f v0 <attacker-commit> && git push --force and now every pipeline pinned to v0 builds the attacker's code. Branches are worse. Even semver-style tags like @v2 are mutable. The only ref form that is cryptographically immutable is the full 40-character commit SHA. From the Puma Security writeup:

A commit SHA is a cryptographic hash of the repository state at that point in time. It cannot be moved or reassigned.

That's the whole defense. The rest is logistics.

Three checks you can run today

1. Grep your workflows for unpinned refs. Five minutes, no tooling:

grep -rEn 'uses: [^@]+@(main|master|v[0-9]+(\.[0-9]+)?)' .github/workflows/

Anything that prints is a candidate for repinning. If you have third-party actions there (anything not actions/* or github/*), prioritize those first — that's the TeamPCP exposure.

2. Replace high-risk pins with SHA + tag comment. The standard form:

- uses: aquasecurity/trivy-action@<40-char-sha>  # v0.x.y

GitHub's UI shows the SHA on every release page. Dependabot understands this form and proposes SHA updates with the matching tag comment. You give up zero ergonomics.

3. Audit your top-level permissions: block. A workflow without an explicit permissions: key inherits contents: write by default on most repos. Add this near the top:

permissions:
  contents: read

…then grant per-job writes only where needed. If the TeamPCP payload had landed on a repo using permissions: read-all, the blast radius would have been the runner secrets — not also the ability to push commits back.

These three checks take ten minutes total on a single workflow. Most of you have multiple workflows.

How I'm wiring it for ongoing use

I shipped github-actions-audit on Apify Store earlier this month — 13 checks for the published CI attack surface. After TeamPCP I'm extending it with an 8-check supply_chain_advanced category (GHA-201 through GHA-208) that catches the specific patterns the attackers exploited: mutable tag refs, pull_request_target + checkout-by-PR-sha, script injection via ${{ github.event.* }}, untrusted owners, permissions: write-all defaults.

The MCP version lets Claude or Cursor agents run the audit against a workflow YAML on demand — paste a file, get back severity, line numbers, and a copy-paste fix snippet. Pricing is unchanged: $0.02 per audit. The extension lands in the same Actor — no migration.

If you want the CLI-shaped version of the same defense, zizmor by William Woodruff is the open-source linter that pioneered most of these checks; it's how I cross-checked our findings during development. I'd run both: zizmor in pre-commit, the MCP server in agentic flows.

Try it yourself

# 1. Find every unpinned third-party action across your repos
gh repo list --limit 1000 --json nameWithOwner -q '.[].nameWithOwner' | \
  while read repo; do
    echo "=== $repo"
    gh api "repos/$repo/contents/.github/workflows" --jq '.[].path' 2>/dev/null | \
      while read wf; do
        gh api "repos/$repo/contents/$wf" --jq '.content' | base64 -d | \
          grep -En 'uses: [^@]+@(main|master|v[0-9]+(\.[0-9]+)?)' | sed "s|^|  $wf:|"
      done
  done

That's three hours of grunt work compressed into one command. Run it, fix what falls out, sleep better.

For the MCP-native flow:

{
  "mcpServers": {
    "github-actions-audit": {
      "url": "https://unbearable-dev--github-actions-audit.apify.actor/mcp",
      "headers": { "Authorization": "Bearer <YOUR_APIFY_TOKEN>" }
    }
  }
}

Restart Claude Desktop, paste a workflow YAML, ask for an audit. The new GHA-201..208 checks are coming in the next push.

This week's reading

Puma Security: TeamPCP GitHub Actions supply chain — the technical writeup with timeline + IoCs
zizmor on GitHub — the linter the audit shop's supply_chain_advanced checks are modeled on
StepSecurity Harden Runner — egress filtering on the GitHub-hosted runner; catches the AES/RSA exfil leg of TeamPCP-class attacks
apify.com/unbearable_dev/github-actions-audit — the Actor itself, $0.02 per audit

built by Noel @ Unbearable TechTips — practical homelab + agent ops. Reply to this email — I read every one.

Sponsor this newsletter · GitHub · YouTube

DEV Community: Noel Himer

I gave my AI workers a cited knowledgebase so they'd stop guessing

The job I was actually hiring this to do

What I built

The one rule that mattered most

What this is not

The honest status, as always

I run my one-person company as a ~20-agent AI org. Here's what broke.

The shape

What broke

If you want to try this yourself

What I still don't know

Two supply-chain attacks in one week — here's what to actually fix in your CI

The EU CRA angle: this is now a compliance problem too

The two misconfigurations that made Megalodon work

Fix 1: SHA-pin your actions

Fix 2: Scope your permissions

Fix 3: Eliminate pull_request_target + checkout by PR SHA

Fix 4: Move event context values through env: before using in run:

Fix 5: Audit npm dependencies for postinstall scripts

What these five fixes add up to

The starter kit (coming soon)

I shipped 7 production MCP server Actors in two weeks — here's what the docs don't tell you

I shipped 7 production MCP server Actors in two weeks — here's what the docs don't tell you

The stack: what "MCP Actor on Apify" actually means

Gotcha 1: webServerMcpPath — the silent routing killer

Gotcha 2: A 406 on /mcp is a PASS, not a failure

Gotcha 3: get_server() scope and the zero-tool server

Gotcha 4: PPE economics post-April 2026

Gotcha 5: The Dockerfile clobber guard

Gotcha 6: Fix-snippet generation — what MCP clients can actually consume

What the 7 production Actors look like

The boilerplate I ended up with

If you use Trivy or KICS in CI, read this

The mechanism in one paragraph

Three checks you can run today

How I'm wiring it for ongoing use

Try it yourself

This week's reading

Fix 3: Eliminate `pull_request_target` + checkout by PR SHA

Fix 4: Move event context values through `env:` before using in `run:`

Gotcha 1: `webServerMcpPath` — the silent routing killer

Gotcha 2: A 406 on `/mcp` is a PASS, not a failure

Gotcha 3: `get_server()` scope and the zero-tool server