How does a capability list work?

How a capability list works in practice

A capability list is an object-centric access control structure. Instead of asking “what can this subject do?” it answers “who, or what process, holds authority over this object?” That means the list sits with the protected object and names the allowed operations, such as read, write, execute or delegate, for each subject or token that has been granted access.

Compared with a role model, the capability list is usually more granular. A subject receives a capability only for the specific object and action recorded in the list, so authority does not automatically spread to other objects. That makes it useful where least privilege matters and where access should travel with the object, not with a broad organisational role.

In a typical system, a capability is not just a permission in the abstract. It is the proof that a subject may act on an object, often embodied as a token, key, handle or similar reference. The check is simple: if the capability is present and valid, the operation proceeds; if not, access is denied. When designed well, that model reduces ambient authority and makes delegation more explicit.

What the list contains and how decisions are made

Each entry in a capability list normally ties three things together: the subject, the object and the permitted action. Some implementations also record constraints such as time limits, propagation rules or whether the capability can be copied or delegated. Those details matter because they determine whether authority is narrow, durable or transferable.

The list is consulted at enforcement time. When a process tries to act, the system checks whether its capability matches the requested object and operation. This is different from a central lookup of broad user privileges because the decision is bound to a specific object. In practice, that can make revocation and auditing clearer, but only if the system keeps an accurate record of issued capabilities and their lifecycle.

Capability systems can support delegation, but delegation should be deliberate. If a subject can hand on its capability, the receiving subject may inherit effective access even when the original owner never intended broad sharing. That is why many designs distinguish between possession of a capability and the right to further delegate it.

Why capability lists are useful for least privilege and revocation

Capability lists are attractive when you want to avoid coarse global permissions. They can limit blast radius because a subject only carries authority for the objects named in its capabilities. They also make hidden access paths easier to spot, because any meaningful authority should have an entry you can inspect. For readers who want to compare this with broader access-control models, the Authorisation Models Guide is a useful companion for understanding how object-centric permissions differ from role- and policy-based approaches.

The same precision can become a weakness if the environment is large and dynamic. Stale capabilities, duplicated grants and inherited permissions can accumulate quietly, especially when issuance happens through automation. Over time, the list may no longer reflect the access the organisation believes it has. That is why teams should review both the content of the list and the rules that govern expiration, renewal and revocation.

In secure systems, capability revocation is one of the hardest parts of the model. If a capability has been copied, cached or delegated, taking it back may require more than deleting one record. The real control objective is to ensure that the system can reliably invalidate the capability everywhere it is trusted, including any derived or propagated form.

Risk and Threat Considerations

Capability lists reduce standing privilege, but they also create concentrated trust in the validity of each issued capability. If an attacker steals a capability, or if a process receives one that is broader than intended, the compromise is often direct and immediate because the token itself is the authority boundary. That makes overbroad grants, weak revocation and poor lifecycle hygiene materially risky.

Failure mechanism: A stale, copied or improperly delegated capability continues to authorize actions even after the organisation believes access has changed, so the attacker or mistaken process keeps acting with legitimate-looking authority.

Impact: The result can be unauthorized object access, privilege persistence, failed containment after incident response, and a false sense of security if teams look only at user accounts rather than live capabilities.

Practitioner Guidance

What to verify: Confirm whether the system can enumerate all active capabilities, including delegated or inherited ones, and whether revocation actually prevents further use. If you cannot prove that a capability has stopped working, treat the control as incomplete.

What to measure: Track stale entries, excessive object breadth per subject, and the age of capabilities that still carry meaningful authority. A rising count of long-lived or unreviewed capabilities usually signals that the model is drifting away from least privilege.

Common mistake: Treating the list as just another permission table. In a true capability model, the operational question is not only “who is allowed?” but “where can this authority be exercised, can it be copied, and how fast can it be withdrawn?”

Practitioner takeaway: A capability list is strongest when it is narrow, explicit and revocable in practice, not just in design; the control fails when the organisation loses sight of where the authority lives after issuance.

Related resources from NHI Mgmt Group

• How should regulated organisations structure an AISPM programme so they can prove controls work, not just list findings?
• How does dangerous capability evaluation work?
• How does Capability Maturity Model work?
• How does a trust service status list work?