※ hackd

RL economics, morally charged terms, and "distillation"

2026-08-28T01:14:23.336Z

It will be easy to convince yourself that the flaw in your business model that gives your competitors a way to catch up with lesser investment is a moral outrage - it is so unjust! - and then complain about the fact that others have the right to do what they are doing.

— Halvar Flake

So what is this red teaming thing anyway?

2026-08-17T23:57:11.111Z

Seeing how I like to talk about offensive security around here, I should probably clarify what I mean about some things, like red teaming. There are plenty of running definitions out there, but just to have something to anchor on for now: ¹

Red teams apply adversarial methods to identify where there’s divergence between an organization’s intended position on a topic, and reality.

The organizational position on the topic of security could be something like: “Our perimeter is secure and our defenses are strong, including our ability to detect and respond to attacks.”

“What if it isn’t though?”: a red team does the work to (in)validate that stated position through repeated end-to-end testing (operations), playing the role of a determined, goal-driven attacker. In doing so, the red team can establish the truth about preventive, detective, and corrective controls and capabilities as they actually exist.

For a red team to be effective, what’s non-negotiable, in my view, is the adversarial part: the ability to think and operate free of as many assumptions and constraints as possible. To be creative, persistent, and unorthodox.

Note that I’m very deliberately avoiding the technical specifics here. I think those are a very important implementation detail, but fundamentally shift focus away from the core of what red teams do. Sure, frequently it looks like: find a bug, maybe even a 0-day vulnerability, then move internally through various systems towards the goal, write up the findings, help with remediation. But those aren’t requirements. Red teams are not a vulnerability-finding function (though incidentally they do find a lot of issues), and in the extreme they don’t even have to be technical all the time. Operations are usually live, with attacks being executed against the production environment of the organization, but it’s also legitimate to run tabletops when the risk is too high to do otherwise (or to expedite the process).

All the technical stuff is largely a function of what red teaming looks like in practice today. But it’s not fundamental to the concept. Lateral thinking and experimentation are.

This post may get updated occasionally ↩

Fix the News

2026-08-12T21:26:12.303Z

Progress isn’t a rule, it’s contested terrain, fought for daily by millions of people who refuse to give in to despair.

It’s easy to feel overwhelmed at times, looking upon the seemingly insurmountable efforts needed to right the world. Yet, good things are happening out there, every day. Fix the News has been my favorite source of positive stories for a long while.

A policy on AI in writing

2026-08-12T01:19:22.934Z

A good policy, well-articulated. Detail != clarity.

(Related: no slop grenade)

Offensive security is a reality test

2026-08-05T18:11:29.239Z

Distilling what a Red Team does can be difficult at times, because frequently people focus on the tactical findings: this vulnerability, that misconfiguration, some control that didn’t work or doesn’t exist. Those are all valuable and important aspects of the work, no doubt, and they’re the common artifacts of operations. But they’re not the essence.

I like Andy’s characterization of red teaming as a truth-finding function, and it’s very close to how I’ve been describing the work as well. Taking a contrarian position to a given claim (“Our data is secure.”) and then working to validate that hypothesis, to find the truth.

Prompt injection as role confusion

2026-06-23T03:52:27.233Z

It seems intuitively true that it is not possible to secure a system with an approach that’s enmeshed with the input mechanism through which attacks also arrive; we’ve done much better using out-of-band controls to avoid commingling code and data. Still, it’s great to see this research land and confidently show this:

Role tags were a formatting trick that became the security architecture and the cognitive scaffolding of modern LLMs. We’ve shown that this architecture doesn’t survive into the model’s actual representations, and that such role confusion is linked to prompt injection.

Unless LLMs achieve genuine role perception, we think injection defense will remain a perpetual whack-a-mole game. And the continuous nature of role boundaries opens the threat of injections designed to subtly shift LLM states through seemingly innocuous text, legally and at scale.

We are living in Pinocchio's world

2026-06-03T17:06:56.518Z

The grifters and the hucksters and the influencers selling impossible things succeed because audiences reward certainty and punish doubt. They honor confidence and resist complication. A clean story about a genius who will fix everything travels faster than a difficult story about tradeoffs.

Skepticism is always healthy. Mostly everything has trade-offs, apparent or not, so you have to keep going until you can see their shape.

uv lock files and malware on PyPI

2026-04-07T15:43:05.118Z

I’m pretty sure that saying “software supply chain security is important” won’t win anyone a prize, yet we see quite an alarming ramp-up in malicious campaigns that take advantage of various gaps in the space, despite all the industry attention. Some problems take time to fix, but there’s a lot more we could be doing today that isn’t for lack of technology, but organizational friction. Anyway, we’re not here to discuss that right now.

The LiteLLM compromise was interesting to watch, especially the impact on downstream consumers. Essentially, everyone that installed or happened to update the LiteLLM package (or something that depended on it) got compromised, as the newest (malicious) version was pulled in their environment.

One of the ways to reduce this kind of thing from happening is to use lock files in the package managers that support them. Lock files are a record of all dependencies for a given package, including versions and cryptographic hashes. Updating the lock file happens intentionally, during development, but deploying the package in production uses the lock file as-is, installing known-good versions as specified. This also has some other non-security related properties, like making sure the versions of packages you’re deploying won’t magically break things because of upstream changes. So you do your dev work, add deps as needed, update the lock file, and ship that. It’s also best practice to pin your dependencies to a specific version (like ==X.Y.Z) instead of using softer constraints that may allow for updates (e.g., >=X.Y.0 installing X.Y.23). This pinning usually happens in a configuration file adjacent to the lock file, like pyproject.toml or Cargo.toml.

The surprise

Let’s talk concretely about Python:

Define dependencies (and other stuff) in pyproject.toml.
Use uv because it actually lets you create and use a lock file, uv.lock (and it’s fast).
As needed, run uv sync and record all package versions, hashes, and download URLs in the lock file.
When building for prod, use uv sync --frozen which will only use what’s in the lock file, installing the same package versions regardless of upstream changes. This uses the URLs directly, and won’t check for any newer versions of packages, even if the constraints would allow for updates.

PyPI is the free package hosting and distribution solution for Python, and it’s a wonderful service to be grateful for. It’s where uv (and pip) look for by default for any Python dependency. So usually uv.lock will contain quite a few entries for things hosted there, and download URLs like https://files.pythonhosted.org/packages/12/34/big-hash/my_pkg-X.Y.Z-py3-none-any.whl which provide the location of my-pkg at version X.Y.Z.

But what if version X.Y.Z is compromised and malicious? Well, PyPI or a maintainer can delete it, which removes the package from the index, and it won’t be installable anymore.

Well, not quite.

The package does get removed from the index, true, but the URL remains active as a result of how storage works, and the PyPI CDN will happily continue serving it. Which means subsequent uv sync --frozen invocations will install that malicious package, since this form doesn’t consult the registry anymore, and just directly fetches the URL.

So, if during the window of time that an upstream package is compromised, one or more lock files get updated to point to that malicious URL, the bad package will still get installed. There can be a delay here until a defender might see these lock files deployed, especially given the nuance of unpinned versions and other things, so having an effective inventory of all installed packages to query is very important to properly address this. Package aging (delaying updates) and other mitigations are also part of the defensive story here, but ultimately it’s worth knowing what gets installed and where.

This isn’t really the fault of PyPI or uv, just how these two things interplay. uv is thinking about the problem and how to fix it.

Choices and responsibility

2026-02-12T18:13:53.452Z

Every time new technology comes out and becomes widely available, there is a difficult balance to be found between the exuberance of early adopters—keen to drive broad usage and land early wins unlocked by the new thing—¹and those who would seek to better understand the downsides before going too deep. There are essential (and obvious) risks none disagree on, but these are few. The real challenge is in negotiating the middle-ground, all the second+ order effects. It’s fair that neither side prevails unchallenged².

My primary perspective comes from doing Security Engineering work across companies of different sizes (and cultures), some defense but mostly offense. On either side though, I’ve largely thought about what the new technology amplifies in terms of risk. Today, of course, it’s LLMs, but the problem space is fractal: we run into variants³ of the same meta issues all the time in security, because that’s the nature of our work. Something shiny, often useful, almost never designed with safety⁴ as a primary property.

Yet, in accepting that we cannot wait for good-enough guardrails around new technology within certain time constraints, we also do not get to abdicate our responsibility for the choice of using such tech. We might not be aware of all the specific second+ order effects, but we can be sure they exist⁵.

So it is with LLMs and all they’ve recently unlocked in terms of working with software and systems (e.g., code assistance, vulnerability discovery, semi- or fully- autonomous personal agents). Broadly, we’ve been able to convert A LOT of ideas into running code, and got some pretty funny and clever things out, too. Quite fast, generally. Yet, all of this software remains the responsibility of whatever human actor is ultimately at the top of the pyramid, and we should neither pretend otherwise, nor enable unaccountability in this regard.

There are situations where and simply using whatever the LLM generated for code is fine without paying it too much attention: prototypes, one-off scripts, even tools that would only ever impact that human if there was a problem (i.e., skin in the game), etc.

Yet for code that’s to be shared with other people it remains the human’s responsibility to review it, ensure its quality, and do so both in terms of respect, and empathy, before sharing it in the first place. That human is still responsible.

I really enjoyed reading (and recommend) both Russ Cox’s post in golang-dev@ on suggestions for how to approach aspects of this issue in that project, and the Oxide RFD (576) he mentions.

I happen to know how to use em-dashes; this article is 100% organic. ↩
Even this concession is uncomfortable for some cultures, which would much rather build up a high degree of confidence/containment before allowing anything. This moves into a different discussion on risk, and while that conversation is interesting and worth iterating on, it is not how things currently work in practice. ↩
Injections of all kinds are as old as computing, as is the unsafe mixing of code and data. ↩
I think of safety in general, not just security. They are deeply intertwined, yet the actual, meaningful property we should strive to deliver upon has to be safety; security is a critical and related, but not identical, attribute. ↩
At a macro scale this gets complex, and we see plenty of imbalances in who pays for these externalities; it’s why we have regulations for some things, frequently the result of socialized negative outcomes we want to avoid repeating. ↩

Mimestream Private Push

2026-02-07T02:19:10.320Z

A nice bit of technical detail on how to achieve a privacy-preserving implementation for email push. I hope many people would care about such details, though realistically I’m unsure of it. It’s one of those things that can be done quickly, easily, and poorly; or with a little more effort and attention, quite well.