Governance — capability-based access control, not identity-based guesswork

What this is, and who it's for

Capability-based access control reduces privilege creep and business risk by making permissions explicit, scoped, and revocable. In practice you should expect measurable improvements; these ranges are implementation-dependent, not guarantees:

• Capability-based access control can reduce active privileged accounts by 40-70% when privileges are reissued as scoped capabilities (implementation-dependent).
• Automated capability revocation can shorten mean time to revoke high-risk access from days to minutes (where revocation mechanisms are implemented).
• Treating entitlements as capabilities commonly reduces audit findings tied to excessive permissions by roughly half (dependent on controls and coverage).
• Identity-based models commonly produce role sprawl, enable lateral movement, and create brittle mappings that increase incident frequency and audit findings.
• A capability is an unforgeable, explicit proof granting a specific actor the right to perform a defined action on a defined resource for a limited time.

Why this matters to governance and risk buyers

Excessive, persistent permissions are a repeatable path to breach, compliance failure, and failed audits. Identity-based models that map permissions to roles or attributes create three failure modes that show up in incident reports and audit findings.

Common failure modes

• Role sprawl. Organizations keep adding roles to satisfy exceptions, then stop pruning them. The result is hundreds or thousands of roles that are hard to reason about and easy to misassign.
• Lateral movement. Broad role permissions, combined with shared credentials or service accounts, let attackers move sideways after initial compromise. That increases blast radius and recovery cost.
• Brittle mappings. Long permission chains (role -> group -> role -> resource) break under change. Mappings drift from documented policy, causing audit failures and noisy attestations.

What a capability is

A capability is an unforgeable, explicit proof that grants a specific actor the right to perform a defined action on a defined resource for a limited time. Capabilities are about what can be done, not who you are. They are issued, logged, verified, and revoked independently of identity assertions.

Operational contrast with identity-based models

Identity-based (RBAC/ABAC)

Identity-based (RBAC/ABAC) assigns permissions to roles or attributes, then infers allowed actions by resolving mappings at request time. Enforcement is tied to identity stores and role hierarchies.

Capability-based

Capability-based models issue scoped tokens or signed authorizations that state allowed actions. Enforcement checks the capability itself, its scope, and its validity period. Verification is local and immediate, revocation can be immediate when supported, and delegation is explicit by design.

flowchart LR
  Req[Request to act] --> ID{Identity-based check}
  Req --> Cap{Capability-based check}
  ID -->|"who are you?"| Role[Role or attribute match]
  Cap -->|"can you actually do this, provably?"| Token[Scoped, time-limited capability]
  Role --> Grant1[Access granted by inference]
  Token --> Grant2[Access granted by verified proof]
  Grant2 --> Rev[Immediate, independent revocation]

Concrete controls to adopt now

1. Entitlement catalog: inventory actions that matter, not just roles. Treat actions as first-class objects with business risk tags.
2. Short-lived, scoped capabilities: issue time-limited tokens that specify action, resource, and allowed parameters. Default to minimal scope.
3. Cryptographic proof and provenance: sign capabilities and log issuance events, including who requested and approved creation.
4. Automated revocation: integrate capability issuance with a revocation mechanism (revocation list or capability manager) so removal is effective immediately.
5. Scoped delegation rules: allow delegation only with explicit boundaries and audit trails, and require re-attestation for elevated delegation.
6. Continuous entitlement attestation: scheduled or triggered checks that validate whether outstanding capabilities remain justified.
7. Integration with incident response: ensure playbooks treat capabilities as primary artifacts to revoke during containment.
8. Reporting for auditors: expose capability issuance, delegation, and revocation records in a form auditors can query, and map those records to control objectives.

How to start without a forklift change

Pick one high-risk action (for example, write access to production databases) and convert its control from role-based assignment to capability issuance. Measure privileged account reduction, time-to-revoke, and audit findings on that slice before expanding.

Design for the HUMΛN who needs to act, and for the board that needs a concise risk story. Capability-based control shortens the gap between policy and enforcement, reduces privilege creep, and gives governance buyers concrete evidence to report: fewer privileged objects, faster revocations, cleaner audit trails. If you want a first step, define the high-risk action, catalog its current entitlements, and require a scoped capability for any future grant.

Start with a high-risk action