What is the Embedded Permission pattern, and what disaster illustrates why it matters?

Build access control into every smart-contract function so it checks the caller's address before running its core logic — because a public-chain contract is callable by anyone by default, and a permission-less sensitive function is an open door.

• Problem. By default a deployed contract has no owner and any participant (or any other contract) can call any of its functions — the code is public. A permission-less function meant to be privileged can then be triggered by an unauthorised user, even accidentally. This is exactly how a bug in a Parity multi-signature wallet library let someone invoke an unprotected function and freeze roughly 500K Ether.
• Solution. Add a permission check to every function: before executing the core logic, verify the caller's blockchain address is authorised, and reject unauthorised calls up front. In Solidity this is typically done with a modifier that runs the check before the function body.
• Benefits. Security and secure authorization, enforced on-chain using the chain's own identity primitives.
• Drawbacks. Cost (extra code raises deployment and run-time cost on a public chain) and lack of flexibility (permissions are fixed at deployment and hard to change without an additional dynamic granting/removal mechanism).

Go deeper:

• A major vulnerability has frozen hundreds of millions of dollars of Ethereum (TechCrunch) — the 2017 Parity multisig freeze: an unprotected library function anyone could call locked roughly 500K ETH, the textbook case for embedded permission checks.