IN THIS BREAKDOWN · 10 SECTIONS
You can read 23% of this breakdown.
The paper in one minute
Jerome Saltzer and Michael Schroeder at MIT wrote this tutorial for the Proceedings of the IEEE in 1975, when time-sharing systems were putting many users' information in one machine. Its first section, the part most often read and the part this page covers, sets out the problem and the principles.
They separate privacy (a person's or organization's right to decide what is released) from security (techniques that control who may use or modify the computer and its information), and focus on protection (controlling executing programs' access to stored information) and authentication (verifying who is making a request). Violations come in three kinds: unauthorized release, unauthorized modification, and unauthorized denial of use. The intruder may well be a legitimate user.
Penetration exercises had broken almost every system tested, and no method existed for building a large system without flaws. So the authors offer eight design principles as guidance: economy of mechanism (keep it small enough to inspect), fail-safe defaults (base access on permission, not exclusion), complete mediation (check every access to every object), open design (security must not depend on a secret design), separation of privilege (two keys are stronger than one), least privilege (every program and user gets only what the job needs), least common mechanism (share as little machinery as possible), and psychological acceptability (protection must match how users think, or they will misuse it). Two more from physical security, work factor and compromise recording, apply imperfectly. The principles are "warnings", not absolute rules.
The rest of the section builds protection from the bottom up: a wall, door and guard around each object; isolated virtual machines enforced by descriptor registers and a privileged state bit; authentication by secrets (passwords, stored only through a hard-to-invert transformation) or unforgeable objects, and the masquerading attack that one-way authentication allows; and sharing implemented either list-oriented (access control lists) or ticket-oriented (capabilities), on behalf of a principal, the entity accountable for a computation.
Research notes: the problem, approach and results
design principles for protection mechanisms, plus two from physical security (work factor, compromise recording) that apply imperfectly
four-letter alphabetic passwords (26⁴): adequate if typed at a terminal, trivial at a million guesses a second
of some 300 self-chosen passwords in a study the paper cites that were guessable by exhaustion or from the owner's personal details
Computers shared by many users need to enforce who may read, change or deny use of which information. In 1975, nearly every system tested by penetration exercises could be broken, and nobody knew how to build a large system without protection flaws.
Since flaws cannot yet be designed out systematically, collect the design principles that reduce their number and seriousness: economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism and psychological acceptability. Then build up protection from first principles: isolation, authentication, and sharing by lists or tickets.
A tutorial whose first section defines the vocabulary of computer security still in use: principals, domains, access control lists versus capabilities, protected subsystems, the guard-and-wall model, and eight principles cited in nearly every security design since.
Why it matters to an FDE
Giving an agent tools is giving a program authority. The questions Saltzer and Schroeder asked about time-sharing users are the questions a security reviewer will ask about your agent.
Least privilege bounds the blast radius. An agent that can read every CRM record because its service account can turns any prompt injection into a full data breach. Scope credentials to the task.
Fail-safe defaults: allowlists, not blocklists. Blocking known-dangerous tools or phrases fails silently when something new appears; granting approved tools only fails visibly, and gets fixed.
Complete mediation: check every tool call. Caching "this user may do X" for a session means a revoked user's agent keeps acting. Check authority on each call, against the user the agent acts for.
Separation of privilege for irreversible actions. Require a second key (human approval, a second system's check) before payments, deletions or external messages.
Know who the principal is. When an agent acts for a user, the paper's question applies: who is accountable for this computation, and does the agent's access match that person's?
Understand the mechanism. Try it on a real problem.
Unlock this breakdown and 99 more papers.
Premium opens every paper in full, plus every answer, concept, course and guide on the site. One payment for six months of access.
6 months · One payment · No auto-renewal
- ◇1 architecture diagram
- </>1 runnable code experiment
- ▦1 results table
- ?5 interview questions with answers
- 03Key takeaways
Definitions, functional levels, why the principles hold, sharing models, misreadings
Free account - 04How it works
Isolation by descriptors, authentication and masquerading, lists and tickets, principals
Premium - 05The numbers that matter
The few quantities in Section I, what they show, and what has changed since
Premium - 06Try it yourself
Recompute the work factor, then model four principles on an agent's tool access
Premium - 07Where it breaks
What the principles do not settle, tensions between them, and what this page leaves out
Premium - 08Using it on a deployment
Running a security review of an agent with these principles
Premium - 09Interview angles
Five questions this paper prepares you for, with answer hints
Premium - 10Read next
Where to go from here on this site
Premium