a capability
Think of a concert ticket. It does not say who you are; it just says the bearer may enter hall B, seat 14. If you hold it, you get in; if you hand it to a friend, they get in instead. The venue does not look you up on a guest list — it simply checks that the ticket is genuine. A capability is the computing version of that ticket: an unforgeable token that names an object and the rights its holder may exercise on it. Possession is permission.
Slicing the access matrix by row gives each domain a list of the objects it may touch and the operations allowed — that list is a set of capabilities. A capability is typically a reference to an object bundled with a set of rights, made unforgeable so a program cannot just fabricate one or tamper with the rights it carries. Systems achieve unforgeability in different ways: keep the capabilities in a protected kernel table that user code can only name by index (so the actual token never lives in user-writable memory), or make the token a large random or cryptographically signed value that cannot be guessed or altered. To use a resource you present the capability; the system checks the token and grants exactly the listed rights, never asking who you are. A Unix file descriptor is a familiar, if limited, example: once a process has successfully opened a file, the small integer it holds is a kind of capability — it can read or write through that handle without the permission check being repeated, and it can even pass the handle to a child process.
Capabilities shine for the principle of least privilege and for delegation: handing someone a single capability gives them exactly one narrow power and nothing else, and they can pass it on without you maintaining a giant central list. The classic hard problem is revocation — taking a right back. Because the holder physically possesses the token, you cannot easily reach into their pocket and tear it up; systems resort to tricks like indirection through a revocable entry, or invalidating the underlying object. This is the mirror-image trade-off against access-control lists, where revoking is easy (just edit the list) but answering who can touch this object is the natural question instead of what can this subject touch.
A process opens /var/log/app.log and gets file descriptor 5. From then on it calls write(5, buf, n) without any further permission lookup — fd 5 is a capability for that open file. It can even pass fd 5 to a child via fork, handing over the same right.
Holding the token is the permission; the system checks the token, not your identity.
The defining property is unforgeability — if user code could fabricate or edit a capability, it would grant itself any right. The classic weakness, opposite to ACLs, is that selectively revoking an already-handed-out capability is genuinely hard.