The Answer That Kept Losing — An Imagined Interview with Norm Hardy

Norm Hardy died before the industry caught up with him. The computer scientist who named the confused deputy problem in 1988 spent decades advocating capability-based security as the fix. He never saw Google DeepMind name a framework after capabilities, or watched the Model Context Protocol independently derive audience-bound tokens as though nobody had thought of them before.

What follows is an imagined conversation, assembled from Hardy's published writings, his cap-lore.com archives, colleagues' accounts of his thinking, and the logical extension of positions he held for over thirty years. We can't interview Hardy. But his arguments are precise enough, and the present moment strange enough, that the conversation practically writes itself.¹

You once wrote that the Tymshare incident convinced you capabilities were "more than merely neat." What changed?

Norm: I watched a compiler overwrite a billing file. Not because it was malicious. Because it was dutiful. It did exactly what it was designed to do: write to the file it was told to write to. The system had handed it a ring of keys, and one of those keys happened to open a door the compiler had no business walking through. No amount of careful programming would have caught it, because the programmer hadn't done anything wrong.²

That's when you stop thinking about access control as a policy question and start seeing it as an architectural one. "Neat" is admiring someone else's solution. "Necessary" is watching a perfectly correct program cause damage because the system couldn't tell the difference between authority it needed and authority it inherited by accident.

You built KeyKOS to prove this could work in production. It ran on commodity hardware from 1983. Why wasn't that enough?

Norm: Because "it works" has never been sufficient to displace "it ships."

ACLs shipped with UNIX. UNIX shipped with everything. The access control list was conceptually familiar: here's a resource, here's a list of who can touch it. Administrators understood it. Textbooks taught it. Capabilities required you to think differently about authority itself, to treat it as something you carry rather than something that gets checked. That's a cognitive shift, and most organizations won't make a cognitive shift when the alternative is already installed in the building.³

KeyKOS demonstrated that capability systems could run real workloads with real uptime. What it couldn't demonstrate was that the industry had a reason to care. The quick fix was good enough. It's always good enough, right up until it isn't.

Let's talk about "right up until it isn't." CaMeL, Google DeepMind's prompt injection defense, stands for "CApabilities for MachinE Learning." They cite Dennis and Van Horn 1966 in their references. Do they know they're continuing your work?

Norm: Some of the researchers, yes. They found the thread. But here's what's interesting: they found it by working backward from the problem, not forward from the literature. They arrived at capabilities because they had to. When your system processes trusted instructions and untrusted data in the same token stream, with no architectural separation between them, you cannot solve the authority problem inside the model. You solve it around the model. And once you're enforcing authority at the system layer, scoping it to specific operations, making it unforgeable and non-transferable... well. You've reinvented capabilities whether you know the word or not.⁴

Meanwhile, the MCP authorization specification has independently arrived at audience-bound tokens, resource indicators, and least-privilege scoping without citing the capability literature at all.

Norm: That's the more telling case. The CaMeL researchers are academics; literature reviews are what they do before breakfast. The MCP practitioners are engineers solving an OAuth problem. They're deriving the same principles from scratch because the engineering constraints demand it. Every token request includes an explicit resource parameter. Tokens are bound to their intended recipient. Short-lived, narrowly scoped. They've built valet keys and they think they invented parking.⁵

I don't say that with bitterness. I say it because it matters whether you know the failure modes of the thing you're building. Mark Miller spent years documenting why naive capability implementations fail: the revocation problem, the confused-grant problem, the difference between real capabilities and access tokens that merely look like capabilities.⁶ If you're reinventing the mechanism without the accumulated knowledge of its edge cases, you will hit the same walls. You just won't know they have names.

The NCSC called LLMs "inherently confusable deputies" last year. Your original deputy was confused by circumstance, a fixable design flaw. Is this the same problem?

Norm: No. And that's precisely why it might finally matter.

My compiler could have been fixed. Scope its authority, problem gone. An LLM cannot be fixed the same way because the confusion is architectural. It processes everything as tokens. It cannot reliably distinguish an instruction from data that resembles an instruction. The confusion is the feature.⁷

So the cage is always partial.

Norm: The cage is always partial. Which means the system around the cage has to be very good. And that's where capabilities stop being "neat" and become...

Necessary.

Norm: Mm.

For forty years, capabilities lost because ACLs were easier. Does this generation face the same headwind?

Norm: That's the question I genuinely don't know the answer to.

The old headwind was simple: an easy path existed. Bolt an ACL onto your UNIX system, check the compliance box, move on. The easy path worked, mostly, for systems where the deputy could be fixed.

But I've watched this industry choose the wrong path with extraordinary creativity for four decades. I wouldn't underestimate its talent for finding a new one.

What would it take for you to believe this time is different?

Norm: When the people building the scoping mechanisms start reading the papers about why previous scoping mechanisms failed. When "audience-bound token" and "capability" appear in the same sentence in production documentation, not just research papers. When the feedback loop between the people who know the history and the people building the future actually closes.

Hardy's 1988 paper remains available in full through ACM archives. The CaMeL framework paper is at arXiv:2503.18813. The MCP authorization specification, as of June 2025, implements audience-bound tokens, resource indicators, and least-privilege scoping — the core mechanisms of capability-based security — without referencing the capability literature.

Footnotes

1. Hardy passed away prior to the current wave of AI agent development. The Foresight Institute established the annual Norm Hardy Prize for "Advances in Usable Security," awarded in 2023, 2024, and 2025. See https://foresight.org/press/norm-hardy-prize-winners-2025/ ↩

2. Hardy's original account of the Tymshare incident appears in "The Confused Deputy (or why capabilities might have been invented)," ACM SIGOPS Operating Systems Review, Vol. 22, No. 4, 1988. Full text: http://web.cs.wpi.edu/~cs557/f14/papers/confused_deputy-hardy.pdf ↩

3. For a thorough comparison of capability-based vs. ACL-based security models, see https://www.skyhunter.com/marcs/capabilityIntro/capacl.html ↩

4. Debenedetti et al., "Defeating Prompt Injections by Design" (CaMeL), arXiv:2503.18813v2, March 2025. The paper explicitly cites Dennis and Van Horn (1966), the original capabilities paper. ↩

5. MCP authorization specification details from https://dasroot.net/posts/2026/04/mcp-authorization-specification-oauth-2-1-resource-indicators/ and https://www.scalekit.com/blog/ship-secure-mcp-server ↩

6. Miller, Yee, and Shapiro, "Capability Myths Demolished," 2003. Review at https://blog.acolyer.org/2016/02/16/capability-myths-demolished/. See also Mark Miller's account of his apprenticeship with Hardy: https://erights.medium.com/norm-hardys-place-in-history-cecf191df641 ↩

7. NCSC characterization of LLMs as "inherently confusable deputies," December 2025. See also Schneier and Raghavan, IEEE Spectrum, January 2026, on the absence of code/data separation in LLM architectures. ↩

8. Odersky et al., "Tracking Capabilities for Safer Agents," arXiv:2603.00991v2, May 2026, proposes capability-safe programming languages as agent security harnesses — another independent convergence on Hardy's core insight. ↩

9. https://foresight.org/press/norm-hardy-prize-winners-2025/ ↩