The new thing is the old thing

The newest defense in AI security is half a century old.

In “What is actually new in AI security,” the answer for agents was to give each one its own narrowly scoped identity. In 1975, Jerome Saltzer and Michael Schroeder gave that idea the wording still cited today: “Every program and every user of the system should operate using the least set of privileges necessary to complete the job.”¹ We did not discover least privilege for AI. We remembered it.

The pattern is not unique to security. In 2005, Michael Stonebraker and Joseph Hellerstein summarized thirty-five years of data-model proposals, and the relational model (RM) was still the prevailing choice. In 2024, Stonebraker and Andrew Pavlo checked again. “Many systems that started out rejecting the RM with much fanfare (think NoSQL),” they wrote, “now expose a SQL-like interface for RM databases.”² Functional programming, too, has roots at least as old as Lisp, whose implementation “began in Fall 1958.”³

The industry does not have a memory problem. It has a renaming budget.

Fred Brooks offered a way to see why in 1986. He split the difficulty of software into essence, “difficulties inherent in the nature of the software,” and accidents, “difficulties which today attend its production but which are not inherent.”⁴ The biggest past breakthroughs, he argued, attacked the accidents. The essence stays. In security, the essence is deciding who may do what, and making that decision stick. An AI agent changes the accidents. It does not change the essence, though it does raise the stakes, because the program now picks its own next step. The question is old. Enforcing the answer got harder.

None of this means nothing improves. Google reports that memory-safety issues fell from 76 percent of Android vulnerabilities in 2019 to 24 percent so far in 2024, and it credits a shift to memory-safe languages for new code, not a rewrite of the old.⁵ Notice the shape. The goal, code that does not corrupt memory, is as old as the problem. What changed is who carries it. It used to depend on every engineer being careful every day. Now the language enforces it by default. SQL injection is on the same path. CISA and the FBI tell software makers to use parameterized queries, which “separate SQL code from user-supplied data,” and to enforce them with “development libraries that make the secure route the default one for developers.”⁶

Least privilege works the same way. Consider a dealership’s keys. A clipboard sign-out sheet asks every person to be honest. An electronic key cabinet releases only the keys that person is allowed to take. Same rule; one is a memo, the other is the system. An agent that can book service appointments but cannot open a customer’s credit application should work like the cabinet, and so should the credentials a vendor issues it: scoped to the task, expiring when the task is done. Least privilege written in a policy is a hope. Least privilege set as the default scope is a control.

That is the difference worth paying for. A new name for an old idea changes the slide. A new default changes the outcome.

So when the next category arrives, in a pitch deck, a vendor’s roadmap or a consultant’s framework, ours included, ask two things. Which old idea is this? And what does it make automatic that used to depend on someone remembering? Automatic means you can verify it, not that someone says so. If the second answer is nothing, what are you paying for?