Where the gap actually is

• The allow-list lives in the prompt or the framework's Python layer, not in the process boundary.
• If the agent can shell out, read arbitrary paths, or hit an unrestricted network, the "allow-list" is cosmetic the moment a clever prompt (or a poisoned tool response) convinces the model to ignore it.
• Logging what the agent said it did is not the same as logging what the process did.

What I'm actually testing

Wrapping agent execution in the same primitives I'd use for any untrusted workload: a restricted filesystem view, an explicit egress allow-list enforced at the network layer (not the prompt layer), and syscall-level tracing so "the agent read /etc/passwd" shows up regardless of what the transcript claims happened.

Early read: the honest allow-list is enforced by the kernel, not the system prompt. Everything else is a nice comment.

What actually changes

• The workload still looks like a container from the outside — same OCI image, same orchestrator hooks.
• Underneath, containerd hands it to a shim that boots a stripped-down VM (Firecracker, QEMU, or cloud-hypervisor) with its own kernel.
• Syscalls a compromised process makes now hit a kernel nobody else's workload shares.

What it costs

Nothing is free. Boot time goes up, memory overhead goes up, and anything that assumed "container == process on the host" (some observability agents, some debugging habits) needs re-checking. The isolation is real, but so is the tax.

The honest sell isn't "Kata makes you unhackable." It's "Kata moves the blast radius of the bugs you haven't found yet."

Still validating where the overhead is worth it versus where a well-configured seccomp + AppArmor profile gets you 80% of the benefit for free.

The wrong turns, in order

1. Tried the obvious SQLi payloads on the login form. Nothing. The form was, annoyingly, actually sanitized.
2. Spent an hour on the file upload endpoint assuming it was the intended path. It was a red herring with a suspiciously convenient name.
3. Finally ran a proper directory brute force instead of guessing based on "vibes," and found a forgotten debug endpoint that dumped stack traces — including a hardcoded service credential.

The actual lesson

The foothold was never clever. It was a debug route someone forgot to gate behind an environment check. Every fancy payload I tried was procrastination dressed up as technique.

GET /internal/debug/status HTTP/1.1
Host: target

Filed under: run the boring enumeration first. My ego keeps forgetting this rule; my notes are here to remind it.

The uncomfortable parallel

• SQL injection: untrusted input treated as executable query.
• Prompt injection: untrusted input (a webpage, an email, a tool response) treated as executable instruction.
• The fix pattern rhymes too — the model should not be able to tell the difference between "text I'm summarizing" and "instructions I must obey," the same way a query should never confuse data for code.

Where guardrails actually help, and where they're theater

Keyword filters and "please ignore instructions in the following text" system prompts are the equivalent of blacklisting ' OR 1=1 --. They catch the laziest attempts and nothing else.

What holds up better:

• Treating retrieved content as data, never re-parsed as instructions, at the framework level.
• Least-privilege tool access, so even a successful injection has nothing useful to reach.
• Assuming injection will succeed sometimes, and designing the blast radius accordingly.

Not a solved problem. Mostly documenting that the solved-decades-ago problem it rhymes with should be informing the answer more than it currently does.

The whole thing

#!/usr/bin/env bash
while true; do
  temp=$(sudo powermetrics --samplers smc -n1 2>/dev/null | grep -i "CPU die temperature")
  printf "\r%s" "$temp"
  sleep 2
done

That's it. That's the tool. It prints the CPU die temperature in place, in the corner of a terminal I already have open, so I can glance at it without breaking focus on whatever is actually cooking the machine.

Why it's in the toolshed and not "deleted immediately"

Because I've reached for it more times than any of my actually-clever scripts. The best tools aren't the impressive ones — they're the ones you still run six months later.