Designing for Security: Revisiting Saltzer & Schroeder

A reflection on the foundations of protection mechanisms, fifty years on — and why every interesting failure in modern systems is still a violation of one of eight principles written in 1975.

§ PreludeA Classic That Still Shapes Modern Security

In 1975, Jerome Saltzer and Michael Schroeder published one of the most influential papers in computer security: The Protection of Information in Computer Systems. Five decades later, it remains a cornerstone of secure system design — the load-bearing vocabulary that the field still uses to argue with itself.

What's remarkable is how cleanly the eight principles map forward. They were written in an era of mainframes and time-sharing systems, but they describe the failure modes of microservices, identity systems, container runtimes, zero-trust networks, and increasingly, AI agents. The vocabulary is fifty years old. The problems are this morning.

This post revisits the principles not as historical artifacts but as working tools — the kind you can hold up against any system and ask: which of these am I honoring, which am I trading away, and do I know why?

The Eight, In Order
  1. Economy of mechanismkeep it small
  2. Fail-safe defaultsdefault deny
  3. Complete mediationcheck every access
  4. Open designno obscurity
  5. Separation of privilegetwo keys
  6. Least privilegeminimum authority
  7. Least common mechanismdon't share
  8. Psychological acceptabilitymake it usable

§ 01Economy of MechanismKeep it simple. Keep it small.

Security thrives on simplicity. The more complex a mechanism, the more places bugs can hide — especially the bugs that only surface under malicious use, never during normal operation. You cannot review what you cannot read.

Modern Echoes Minimal attack surface. Small trusted computing bases. Microkernels. Terse IAM policies. A single policy engine instead of authorization logic scattered across four files.
Simplicity isn't elegance — it's defense.

§ 02Fail-Safe DefaultsDeny by default. Permit explicitly.

If you forget to configure something, it should remain secure. Systems that default to allow are one misconfiguration away from a postmortem. Saltzer and Schroeder's argument was psychological: permissive failures are silent, deny-by-default failures are loud, and loud failures get fixed.

Modern Echoes Private-by-default cloud storage. Zero-trust networking. Deny-all firewall baselines. Opt-in OAuth scopes. MCP connectors that grant nothing until the user picks specific capabilities.
Mistakes should fail closed, not open.

§ 03Complete MediationCheck every access, every time.

No caching permissions without careful invalidation. No assuming a previous check still applies. The token tells you who; the policy engine has to tell you still?

Modern Echoes Token validation on every API call. Continuous authorization. Revocation-aware access control. Agent sessions that re-check policy on every tool call instead of trusting the token they were issued an hour ago.
Every request is a new question.

§ 04Open DesignSecurity should not depend on the secrecy of the mechanism.

The design can be public. The keys must remain secret. A system whose security depends on the secrecy of its design becomes insecure the moment that design is no longer secret — and designs always leak.

Modern Echoes Open-source cryptography. Public algorithms (AES, RSA, SHA). Transparent security reviews. The professional contempt for security through obscurity.
If your system breaks when someone reads the design doc, it wasn't secure.

§ 05Separation of PrivilegeRequire two or more conditions for access.

Two keys are harder to steal than one. A mechanism that requires two independent credentials is, all else equal, more robust than one that requires one.

Modern Echoes Multi-factor authentication. Dual-control financial approvals. Multi-party authorization for sensitive operations. Kubernetes admission combined with RBAC combined with network policies. For agents: narrow scoped tokens per action rather than one omnibus token holding every capability the agent might ever need.
One failure shouldn't compromise the system.

§ 06Least PrivilegeGive every user and program the minimum permissions necessary.

Nothing more. And capabilities should be acquired and released, not held continuously — a program that needs to write one file for one second shouldn't run for an hour with write access.

Modern Echoes IAM roles scoped to a single task. Container sandboxing. Fine-grained API permissions. Just-in-time credential issuance. SPIFFE workload identity. For AI agents this is the principle violated most flagrantly: the easiest way to make an agent capable is to give it broad authority and trust it to use that authority sparingly. The trust is misplaced.
The smaller the blast radius, the safer the system.

§ 07Least Common MechanismAvoid shared components whenever possible.

Shared mechanisms create shared vulnerabilities. Every component that two users both depend on is a place where one can leak information to or about the other.

Modern Echoes Tenant isolation. Per-user encryption keys. Dedicated caches and queues per service. The side-channel literature in general. Multitenancy is fundamentally a violation of this principle, justified by economics — which is fine, as long as the trade is made knowingly.
If everyone depends on it, everyone can be hurt by it.

§ 08Psychological AcceptabilitySecurity must be usable.

If the mechanism is hard to use, users will work around it — and the workarounds become the new attack surface. The consent dialog that nobody reads is not a security control; it is a liability that pretends to be a security control.

Modern Echoes Clear permission prompts. Password managers. Human-readable MFA flows. Consent UIs that speak the user's language rather than the protocol's. The OAuth scope string calendar.events.write is not what the user is consenting to; let the assistant move my meetings is. The gap between those two is where social engineering lives.
Usability is not a luxury. It is a security requirement.
· · ·

§ CodaClosing Thoughts

Saltzer and Schroeder didn't just give us a list of rules. They gave us a mindset — a way of thinking about security that survives every technology shift the field has been through, and looks poised to survive the next one too.

Even in today's world of AI agents, distributed systems, and cloud-native architectures, these principles remain the backbone of secure design. They remind us that:

The principles sometimes conflict with each other — least common mechanism wants you to duplicate, economy of mechanism wants you to deduplicate. That is not a bug in the framework. It is the framework. The skill is in the judgment, and the judgment is built by reading the paper, sitting with it, and then looking at the system in front of you and asking which principle each decision honors and which it trades away.

If you are building systems that handle sensitive data, these principles aren't optional. They are the foundation.

The paper is freely available at web.mit.edu/Saltzer/www/publications/protection. It takes about an hour to read. It pays that hour back for the rest of your career.