capability-based security
Most systems answer 'is this program allowed to do this?' by checking an identity against a list: this user owns this file, this account has admin rights, so the action is permitted. Capability-based security takes a different stance. Authority is not something you have because of who you are; it is something you hold - an unforgeable token that both names a specific resource and grants a specific right to it. If you hold the token, you can act; if you do not hold it, you cannot even refer to the resource. The token is called a capability.
Concretely, think of a capability as a key that is also a label: it says 'this exact file, with write permission' and cannot be guessed, forged, or altered to point somewhere else - typically it is a protected reference the kernel hands out and tracks, not a number a program can fabricate. Crucially there is no ambient authority: a program cannot reach a resource just by naming a path in the global namespace, because there is no global naming - it can only use resources it was explicitly given capabilities for. You delegate authority by passing a capability to someone else (and you can pass a weaker one, say read-only), and that someone now has exactly that and nothing more. WASI's pre-opened directories and seL4's access control are real, modern examples of this model.
It matters because it makes 'least privilege' the natural default rather than an aspiration: a component that was handed only a capability to one socket and one directory literally cannot touch anything else, so a bug or a compromise in it is contained by construction. Compare the usual ambient-authority world, where a process runs with all of your permissions and a single flaw can reach your whole account. Be honest about the limits, though: capabilities must genuinely be unforgeable and revocation can be awkward (taking back a delegated capability is harder than deleting a row in a permission list), and confused-deputy-style mistakes are still possible if a privileged component is tricked into using its capabilities on someone else's behalf. The model reshapes where authority lives; it does not by itself make a system bug-free.
ambient authority (typical): process runs with ALL your rights; open("/etc/passwd") works just by naming the path -> one bug reaches everything capability model: you were handed only { dir handle: /srv/data, rights: read } -> you can read under /srv/data and literally cannot name anything else
With capabilities there is no ambient authority: a component can only act on resources it was explicitly handed a token for, making least privilege the default.
Capability security reshapes where authority lives but does not by itself make a system bug-free: the tokens must truly be unforgeable, revoking a delegated capability is harder than deleting a permission entry, and a privileged 'confused deputy' tricked into using its capabilities for an attacker is still possible.