Access Control

Prime #

170

Origin domain

Computer Science & Software Engineering

Also from

Security Intelligence, Statistics & Experimental Design, Law & Governance

Aliases

Authorization, Permissions, Access Management

Related primes

Authentication, Principle of Least Privilege, principal, policy, information security

Core Idea

Access control is the mechanism and policy by which a system decides whether a particular principal (user, process, service, device) may perform a particular action (read, write, execute, modify, delete) on a particular resource (file, record, endpoint, physical space, function) at a particular moment — enforcing a security policy that separates authorized from unauthorized access and is the primary technical implementation of confidentiality, integrity, and need-to-know principles^[1]. The essential commitment is that resources requiring protection must have an explicit authorization layer; that authorization is distinct from authentication (identity establishment); that the policy expressed through permissions / roles / attributes / rules must be auditable and correctly enforced; and that the principle of least privilege (grant only the minimum access needed for a task) is a foundational design heuristic.

How would you explain it like I'm…

Who Can Do What

Think of a bouncer at a party. Before letting anyone in, they check the guest list and the rules: who can come, what room they can go in, and what they can do. Access control is the same — it decides who gets to do what with what.

Permission Rules

Access control is how a system decides who is allowed to do which things to which stuff. Maybe a teacher can change grades but students can only read them. Maybe your phone lets your fingerprint open it but blocks everyone else. The system has a list of rules — like a rulebook — that says which people, programs, or devices can read, write, or change which files or actions. A core rule of thumb is least privilege: give everyone only the access they need, and no more.

Authorization System

Access control is the mechanism and policy by which a system decides whether a specific principal — a user, process, service, or device — may perform a specific action (read, write, execute, delete) on a specific resource at a specific moment. It enforces a security policy that separates authorized from unauthorized access, and it is the main technical implementation of confidentiality, integrity, and need-to-know. Access control is different from authentication, which only establishes who you are; access control decides what you, once identified, are allowed to do. The policy — expressed as permissions, roles, attributes, or rules — must be auditable and enforced correctly. A foundational design heuristic is least privilege: grant only the minimum access needed.

 

Access control is the mechanism and policy by which a system decides whether a particular principal (user, process, service, or device) may perform a particular action (read, write, execute, modify, delete) on a particular resource (file, record, endpoint, physical space, function) at a particular moment. It enforces a security policy that separates authorized from unauthorized access and is the primary technical implementation of confidentiality, integrity, and need-to-know. Access control sits downstream of authentication: authentication establishes who or what is acting, access control decides whether that established identity may carry out the requested operation on the requested resource. The policy is expressed through permissions, roles (RBAC), attributes (ABAC), or rule-based logic, and must be both auditable and correctly enforced — bugs in the enforcement layer collapse the policy. A foundational design heuristic is the principle of least privilege: grant only the minimum access a principal needs to do its task, no more and no longer than necessary. Defense in depth then layers access control alongside encryption, monitoring, and segregation so that a single bypass does not expose everything.

Structural Signature

• The reference monitor evaluating authorization requests (principal, action, resource, context) ^[2]
• The access control matrix decomposition (ACLs, capabilities, or role-based delegation) ^[3]
• The policy model selection (DAC, MAC, RBAC, ABAC, ReBAC, or hybrid) ^[4]
• The enforcement mechanism (kernel reference monitor, middleware PDP/PEP, admission controller, or hardware-backed) ^[1]
• The principle of least privilege applied to role scope and action granularity ^[1]
• The completeness and bypass-resistance properties ensuring policy is universally mediated ^[2]

What It Is Not

• Not identical to authentication. Authentication answers "who are you?"; access control answers "are you allowed?" They are distinct but composed: authentication produces the principal identity used as input to authorization. Authentication failures and authorization failures have different remediations and mitigations.

• Not equivalent to encryption. Encryption protects data confidentiality from those without keys; access control governs what key-holders (or authenticated principals) can do. Encryption is a mechanism often used in service of access-control policy but is not itself access control.

• Not information security writ large. Information security is a broader program (cryptography, incident response, secure development, supply chain, training); access control is one pillar. A system can have perfect access control and still be compromised via other vectors (phishing, supply-chain attacks, side channels).

• Not binary or static. Real authorization is contextual (time-of-day, network-origin, device-posture, session-duration, step-up for high-risk actions), graduated (read vs write vs delete), revocable (temporary privileges, session expiry, break-glass auditing), and dynamic (attribute changes propagate, policies evolve).

• Not a single model. DAC, MAC, RBAC, ABAC, ReBAC all have different trade-offs in expressiveness, manageability, and enforcement cost. Many real systems combine models (RBAC with attribute predicates, DAC with MAC guard rails).

• Common misclassification: Confusing access control (authorization) with authentication (identity establishment), or treating any security boundary as access control when it may lack auditability, completeness, or consistent enforcement mechanisms.

Broad Use

Access control appears in operating systems (POSIX permissions — rwx for owner/group/other; SELinux, AppArmor, capabilities(7); Windows ACLs), in filesystems (NTFS, NFSv4 ACLs), in databases (GRANT/REVOKE, row-level security, column-level policies), in cloud platforms (AWS IAM, Azure RBAC, GCP IAM; service-to-service auth via SPIFFE/SPIRE), in Kubernetes (RBAC roles, namespaces, admission control, OPA Gatekeeper, Kyverno), in web apps (session-based, OAuth 2 / OIDC scopes, JWT claims, row-level multi-tenant), in zero-trust architectures (BeyondCorp, identity-aware proxies, per-request policy), in healthcare (HIPAA-governed access; role-based medical record access), in finance (PCI-DSS compliance; SOX segregation of duties), in government (classification levels: Confidential, Secret, Top Secret; compartmented access), in physical security (card readers, biometric locks, mantraps), in libraries and archives (restricted collections; access-by-appointment materials), in organizations (need-to-know, project access, separation of duties), and in legal systems (judicial access to sealed records, attorney-client privilege).

Clarity

Access control clarifies that security is implemented policy (decide, then enforce) rather than a generic property of systems, that authentication and authorization are distinct concerns, that least privilege and separation of duty are foundational for limiting blast radius, that policy complexity grows with system scale and requires explicit management^[4], and that access-control failures are a leading vulnerability class (OWASP A01 in 2021).

Manages Complexity

The construct manages complexity by decomposing security policy from application logic (authorization as an orthogonal concern), providing a mature catalog of models (DAC, MAC, RBAC, ABAC, ReBAC) with known trade-offs, enabling audit (access logs, policy reviews), and supporting hierarchical / role-based abstractions that compress the number of distinct rules^[4]. Modern policy-as-code tools (OPA, Cedar, Casbin) make policy version-controlled, testable, and independently evolvable. The structural clarity enables reasoning about policy without implementation details.

Abstract Reasoning

Access-control reasoning proceeds by identifying the protected resources and the actions available, enumerating principals and their functional roles, selecting a policy model appropriate for the scale and sensitivity (RBAC for most enterprise, ABAC / ReBAC for fine-grained / relationship-based, MAC for classification-based), specifying policies in the model, verifying completeness and consistency, and monitoring for drift and violations^[1]. It supports software design (authorization layers, middleware, guards), organizational design (segregation of duty, approval workflows), and compliance (HIPAA, PCI, SOC 2, NIST 800-53).

Knowledge Transfer

A systems engineer's access-control reasoning (principal, resource, action, policy, enforcement) transfers across OS, web, cloud, and physical security. The structural core is explicit policy decisions on every access request; what varies is the substrate, principal granularity, and resource vocabulary. The same diagnostic framework — can every access request be mediated, are permissions minimal, is the policy auditable, can it be revoked — applies to POSIX file permissions, Kubernetes RBAC, OAuth scopes, and physical badge systems.

Examples

Formal/abstract

Lampson's access-control matrix (1971)^[3] provides the foundational formalism: a matrix with principals as rows, resources as columns, and cells containing allowed actions^[3]. In practice this matrix is sparse and decomposed into access control lists (ACL: per-resource, listing who can do what) or capabilities (per-principal, listing what the principal can access). Modern systems use role-based access control (RBAC), introduced by Sandhu (1996), where principals are assigned roles, and roles are granted permissions on resources — reducing the combinatorial explosion of individual principal-resource pairs. The structural property is that every access request (principal P, action A, resource R, context C) is evaluated against a policy function auth(P, A, R, C) → {allow, deny}, and this mediation is the reference monitor.

Mapped back: This instantiates the structural signature directly — policy function, mediation at every access, and model-agnostic formalism enabling audit and reasoning.

Applied/industry

A Kubernetes ServiceAccount running a microservice must read ConfigMaps in its namespace. An RBAC Role ("configmap-reader") specifies verbs (get, list) on resources (configmaps) in the namespace. A RoleBinding binds the ServiceAccount to the Role. When the pod makes an API call (GET /api/v1/namespaces/default/configmaps/foo), the API server's authorization chain evaluates RBAC (the bound role allows get on configmaps), producing allow or deny. This system enforces least-privilege (the service can only read ConfigMaps, not Secrets or Pods) and separation of duty (the cluster operator manages RBAC policies independently of pod code). Google's Zanzibar extends to a relationship-based global model (ReBAC) for Google Drive / Docs / Calendar, where authorization depends on hierarchical relationships (file is in folder, user is folder member) rather than static roles.

Mapped back: This shows RBAC as a concrete instantiation of the reference monitor pattern, with principled enforcement across cloud infrastructure and direct application to organizational access governance.

Structural Tensions

• T1: Least Privilege vs Operational Friction. Strict least-privilege policies produce many ticket-based, time-limited grants; users' productivity suffers; workarounds (shared credentials, privileged always-on service accounts) emerge. Loose policies speed work but expand blast radius^[5]. The right balance requires ongoing investment and automation (just-in-time access, approval workflows).

• T2: Policy Complexity Grows Beyond Auditability. RBAC role explosion in large organizations (tens of thousands of roles); ABAC policy interactions; ReBAC cascading updates. Reviewing "who has access to X?" becomes infeasible by inspection. Audit reviews become perfunctory; dormant privileged roles persist; least privilege is aspirational rather than enforced; policy-as-code and continuous access review tooling partially remediate but are non-trivial investments.

• T3: Broken Authorization Is a Top Vulnerability Class. OWASP Top 10 lists Broken Access Control as A01 (2021 revision). Insecure Direct Object Reference (IDOR), missing function-level checks, horizontal / vertical privilege escalation, confused-deputy attacks, TOCTOU in permission checks^[5]. Developers implement authorization inconsistently across endpoints; new features omit checks; framework defaults are wrong; defense-in-depth (gateway + app + data layer) is not in place.

• T4: Authentication-Authorization Conflation and Confused Deputies. A principal authenticated with one identity performs work on behalf of another, under the authority of a third; the reference monitor must determine which identity's authority governs. Confused-deputy attacks (Hardy 1988) exploit this; OAuth's scopes, token delegation, and workload identity (SPIFFE) address parts but introduce their own complexity.

• T5: Dynamic Context and Policy Change. Authorization may depend on time, network location, device posture, user behavior, or external events (incident, suspension). Propagating policy changes across distributed systems without cascading failures requires careful coordination and eventual-consistency handling^[6]. The system must balance immediate enforcement with operational stability.

• T6: Audit and Forensics at Scale. Comprehensive logging of all access decisions produces massive audit logs; retention and queryability are burdensome. At the same time, insufficient audit trails make incident forensics impossible. The balance depends on the risk profile and regulatory requirements, and auditing itself can become a performance bottleneck.

Structural–Framed Character

Access Control is a hybrid on the structural–framed spectrum. Part of it is a bare relational pattern that means the same thing in any field; part of it is a vocabulary and set of assumptions inherited from computer science. It leans structural, carrying only a light frame.

Stripped down, the prime is a clean decision relation: for a given principal, action, and resource at a given moment, a reference monitor permits or denies. That gating pattern recurs unchanged across file systems, networked services, and physical spaces such as locked buildings, and you recognize it as a structure already present in any guarded system. What it imports from its security home is a thin normative layer — the language of authorization, confidentiality, integrity, and need-to-know, which presumes a policy worth enforcing and parties who ought or ought not to have entry. On most diagnostics it reads structural, but that inherited policy framing keeps it just short of the pure pole, in the mixed-structural range.

Substrate Independence

Access Control is a moderately substrate-independent prime — composite 3 / 5 on the substrate-independence scale. At its core sits a clean, substrate-agnostic decision — does this principal get to take this action on this resource in this context — and that authorization logic genuinely travels from computing into organizational delegation (need-to-know, role-based privileges) and physical space. What holds it at the middle is where the evidence actually lands: the worked examples are heavily computational (ACLs, RBAC, Kubernetes), and a manager reasoning about who-may-do-what would not necessarily recognize the same framework. The structure carries, but the load-bearing instances cluster in one corner.

• Composite substrate independence — 3 / 5
• Domain breadth — 3 / 5
• Structural abstraction — 4 / 5
• Transfer evidence — 3 / 5

Relationships to Other Abstractions

Current abstraction Access Control Prime

Parents (3) — more general patterns this builds on

• Access Control is a kind of Authority Prime

  Access control is a specific kind of authority, exercising legitimate power to grant or deny actions on resources.

• Access Control is a kind of Constraint Prime

  Access control is a specific kind of constraint, restricting admissible principal-action-resource combinations to those satisfying a security policy.

• Access Control presupposes Boundary Prime

  Access control presupposes boundary because deciding who may cross into resources requires a demarcation between inside and outside.

Children (6) — more specific cases that build on this

• Mass Assignment Domain-specific presupposes Access Control

  The mass-assignment verdict presupposes field-level access control defining which attributes an authorized action may write by default-deny allow-list.

• Source Protection Domain-specific is part of Access Control

  Source Protection contains Access Control because the source's identity must be available only to explicitly authorized people, systems, and legal processes.

• Minimum-Necessary Disclosure Prime presupposes Access Control

  Minimum_necessary_disclosure operates AFTER authorization — access_control gates who-may-read; this prime governs response-payload breadth under authorized access, projecting surplus at the source.

▸ Show 3 more

Hierarchy paths (3) — routes to 3 parentless roots

• Access Control → Authority

Show alternative paths (2)

Neighborhood in Abstraction Space

Access Control sits in a sparse region of abstraction space (94^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely rather than landing on a neighbor.

Family — Authority, Delegation & Governance (10 primes)

Nearest neighbors

• Principle of Least Privilege — 0.70
• Goal Shielding — 0.67
• Side Channel Attack — 0.67
• Regulatory Capture — 0.67
• Antagonist — 0.67

Computed from structural-signature embeddings · 2026-07-26

Not to Be Confused With

Access Control must be distinguished from Governance, which specifies the durable architecture of authority, accountability, and decision rights through which groups make binding collective decisions. Governance asks: "Who has the right and responsibility to make decisions? How is that authority distributed? To whom are decision-makers accountable?" These are foundational questions about the structure of legitimate power in an organization or system. Access control, by contrast, is a technical mechanism enforcing authorization policy at the point of resource use. It asks: "Given the decision about who should access what, how do we ensure that this decision is enforced when someone tries to access a resource?" Governance distributes legitimate power and establishes accountability relationships; access control mediates execution against the policy governance has established. A university governance structure might establish that tenure committees have the right to access personnel files; access control implements the system that checks: "Is this person authenticated as a tenure committee member? Yes—then they may read this file."

Access Control is also distinct from Oversight Capacity, which names the structural limit on how many direct subordinates or task-units one overseeing entity can effectively supervise before quality or attention deteriorates. Oversight capacity is about supervisory bandwidth—the human or organizational limit on how many items can be managed with adequate care. A manager can effectively oversee 5-7 direct reports; beyond that number, oversight quality typically declines. Access control, by contrast, specifies an authorization layer determining which principals (people, systems, roles) may perform which actions on which resources. The two are orthogonal: a manager with high oversight capacity (can supervise many people) still needs access control to ensure that subordinates can only access the resources their roles permit. Oversight capacity is about the number of items one can actively manage; access control is about resource authorization independent of management span.

Nor is access control identical to Delegation of Authority, though the two often work together. Delegation assigns decision-making power and responsibility from a principal to an agent, with clear boundaries defining the scope and duration of delegated authority and establishing accountability for how that authority is used. A CEO delegates hiring decisions to department heads; a user delegates password reset authority to system administrators. Delegation is about who has decision rights and responsibility. Access control is the enforcement mechanism that determines what actions authenticated principals may execute. Delegation creates authority relationships and specifies scope ("you may hire up to 3 new people per year"); access control enforces execution against that scope (if you exceed your budget, the purchase requisition system rejects it). They are complementary: delegation answers "who decides?"; access control answers "who is allowed to execute this already-delegated decision?"

Access Control is not Transparency, which is the disclosure of information to stakeholders for oversight and accountability. Transparency mechanisms—audit logs, open records, public reporting—enable stakeholders to review what decisions have been made and what resources have been allocated. Transparency is about information visibility. Access control is the mechanism governing who may read, write, or execute against resources and functions. Critically, access control operates independent of whether the policy itself is transparent. A system can have strong access control with opaque policy (restrictive controls, but stakeholders don't know why access is restricted), or it can have transparent policy with weak access control (everyone knows the rules, but the system doesn't effectively enforce them). The two can and should work together—transparent policies that are effectively enforced—but they address different structural problems.

Finally, access control is not Layered Coordination and Oversight, which is the structural architecture distributing authority and information flow across multiple tiers or organizational levels, each with different scopes and decision-making boundaries. Layered coordination arranges how authority flows upward and downward through an organization, what information is aggregated at each level, and how decisions at each level affect the level below. It is about the shape of organizational structure and information flow. Access control is the enforcement mechanism at each resource boundary determining authorization. Layered coordination structures how authority flows and aggregates; access control mediates execution at the point of resource contact. An organization with layered coordination (hierarchical levels, each with decision authority) still needs access control at each level to ensure that people at each level can only access the resources their tier permits. The two work together but serve different purposes: layering structures authority flow; access control enforces it.

Solution Archetypes

Solution archetypes in the catalog that build on this prime — directly (this prime is a source ingredient) or as a related prime.

Built directly on this prime (14)

• Accountable Gatekeeping Design: Design choke-point selection so passage decisions use explicit criteria, bounded discretion, traceable reasons, review paths, and distribution audits rather than opaque gatekeeper preference.
  ▸ Mechanisms (12)
• Bottleneck Power Governance: When one actor controls a necessary access point with no close substitutes, constrain that power through access duties, price/service rules, oversight, remedies, and paths to substitutes or contestability.
  ▸ Mechanisms (15)
• Data-Control Boundary Inertization: Keep untrusted content inert until a structural boundary, validation rule, and authority gate explicitly permit it to become control.
  ▸ Mechanisms (11)
• Evidence-Bound Authentication: Grant trust, access, or evidential weight only after an asserted identity or origin is bound to admissible evidence and returned as a scoped authentication verdict.
  ▸ Mechanisms (12)
• Fragmented Rights Clearance Design: Unlock under-used resources by mapping fragmented exclusion rights and replacing costly one-by-one permission assembly with legitimate clearance, pooling, default, brokerage, or bundling paths.
  ▸ Mechanisms (9)
• Least-Privilege Access Design: Grant actors only the access needed for their role, task, or context, with escalation and audit paths for exceptions.
  ▸ Mechanisms (9)
• Misuse-Resistant Affordance Design: Shape affordances and defaults so the harmful path is unavailable, costly, or unattractive while the legitimate path stays easy.
  ▸ Mechanisms (10)
• Nonactivating Occupancy Blockade: Block an unwanted trigger by safely occupying the recognition site with a nonactivating substitute that denies access without producing the response.
  ▸ Mechanisms (8)
• Principal-Bound Authority Mediation: Let a deputy act only when the requesting principal, stated intent, delegated scope, and use of the deputy’s authority are explicitly bound and checkable.
  ▸ Mechanisms (9)
• Property Rights Bundle Governance: When access to a resource must be stable, enforceable, and transferable, define the property-rights bundle—use, exclusion, transfer, income, stewardship duties, limits, and remedies—rather than treating ownership as a single undifferentiated claim.
  ▸ Mechanisms (14)
• Restricted-Issuance / Open-Verification Design: Let many actors verify an artifact, credential, claim, or mark without giving them the protected capability needed to create valid ones.
  ▸ Mechanisms (11)
• Role-Scoped Disclosure Minimization: Release only the role- and purpose-justified subset of a richer record, removing surplus at the producer boundary before it can propagate.
  ▸ Mechanisms (12)
• Side-Channel Leakage Containment: Audit and redesign legitimate outputs so timing, size, errors, metadata, resource use, aggregates, or other side effects cannot reveal protected state beyond the access policy.
  ▸ Mechanisms (16)
• Transitive Trust Boundary Hardening: Do not let a trusted relationship admit a payload automatically; re-scope and verify the artifact, channel, transformation, and authority at the point of use.
  ▸ Mechanisms (16)

Also a related prime in 64 archetypes

• Access-Conditioned Bundle Decoupling: Prevent access leverage from forcing unwanted bundled acceptance by testing necessity, unbundling separable conditions, and preserving meaningful refusal, alternatives, or remedies.
• Aspect-Scoped Identity Projection: Represent one underlying entity under a defined aspect or role as a linked derived bearer, so properties, rights, obligations, identifiers, and lifecycle rules attach only where they belong.
• Autonomous Action Zone Protection: Protect a bounded zone where a legitimate actor can make and execute in-scope decisions without needing permission from outside authorities.
• Backfire-Aware Suppression Design: Handle harmful or unwanted information without making the act of suppression more newsworthy than the information itself.
• Capture-Resistant Institutional Design: Protect an institution from being redirected by the actors it governs by mapping capture channels, preserving independence, broadening countervailing voice, exposing privileged access, and reviewing decisions for mandate drift.
• Commons Governance: Govern shared resources so individually rational use, neglect, or pollution does not destroy collective viability.
• Competence-Condition Activation: When a situation calls for action, make the qualified actor know that the condition is met, that they are competent to act, and that inaction or handoff is accountable.
• Conditional Authority Envelope Design: Give actors advance permission to act inside known conditions, with explicit limits, escalation triggers, and after-action accountability.
• Conservation Accounting: Track conserved quantities across transformations so losses, leaks, substitutions, duplications, and hidden transfers become visible.
• Constitutive Act Governance: Treat state-making words and acts as governed transitions, not mere messages, so the realities they create have valid authority, clear uptake, durable records, and accountable reversal paths.

▸ Show 54 more

Notes

Access control is held at High confidence. Foundational CS / security / organizational construct with strong cross-domain applicability. The distinction between access control (authorization) and authentication is critical; both are necessary for security but address different questions. Least privilege and separation of duty are design heuristics that recur across all models. Modern instantiations (Kubernetes RBAC, OAuth 2.0, relationship-based access control) build on Lampson's matrix and Sandhu's RBAC, demonstrating the construct's lasting relevance. The entry catalogs the major models and flags the leading failure modes (role explosion, broken authorization, confused deputy, policy complexity, audit at scale).

References

[1] NIST. (2020). Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev. 5). The Access Control (AC) family — AC-3 Access Enforcement, AC-6 Least Privilege, plus account management and continuous monitoring — is the canonical control catalog implementing authorization, need-to-know, and least privilege; supports markers 001, 005, 006, 010. ↩

[2] Anderson, J. P. (1972). Computer Security Technology Planning Study (ESD-TR-73-51, Vol. I). USAF Electronic Systems Division. Coins the reference-monitor concept and its required properties — complete mediation (every access validated), tamper-resistance, and verifiability — the correct source for markers 002 (reference monitor evaluating every request) and 007 (completeness / bypass-resistance / universal mediation), which Lampson 1971 does not establish. ↩

[3] Lampson, B. W. (1971). "Protection". Proceedings of the 5^th Princeton Conference on Information Sciences and Systems, 437–443 (reprinted in ACM Operating Systems Review 8(1), Jan 1974, 18–24). Introduces the access-control matrix (subjects as rows, objects as columns, cells holding permitted access modes) and its decomposition into ACLs and capabilities — supports markers 003, 011, 015. ↩

[4] Sandhu, R. S., Coyne, E. J., Feinstein, H. L., & Youman, C. E. (1996). "Role-based access control models". IEEE Computer, 29(2), 38–47. Defines the RBAC reference-model family (RBAC0–RBAC3) in which permissions attach to roles and principals acquire them via role membership, compressing principal-permission assignment and easing administration/review — supports markers 004, 008, 009. (Fixes original author typo 'Coynek'.) ↩

[5] OWASP. (2021). OWASP Top 10 — 2021: A01 Broken Access Control. Ranks Broken Access Control #1 (94% of tested apps affected); enumerates least-privilege/deny-by-default violations, IDOR, missing function-level checks, and horizontal/vertical privilege escalation — supports markers 012 (least-privilege failures expand exposure) and 013 (A01 + the listed failure modes). ↩

[6] Weber, M., Bieniusa, A., & Poetzsch-Heffter, A. (2016). "Access Control for Weakly Consistent Replicated Information Systems". In Security and Trust Management (STM 2016), LNCS 9871, 82–97. Springer. Presents an access-control model for weakly consistent replicated systems in which concurrent updates to access rules deterministically converge while preserving invariants — directly supports marker 014 (propagating policy changes across distributed systems with eventual-consistency handling). Replaces the non-existent Chen 2014 citation. ↩

[7] Hardy, N. (1988). "The confused deputy: (or why capabilities might have been invented)". ACM SIGOPS Operating Systems Review, 22(4), 36–38. Origin of the confused-deputy problem, motivating capability-based authority; bibliography-only (cited in tension T4 prose without a FACT marker — verified existence and linked).

[8] Pang, R., Caceres, R., Burrows, M., Chen, Z., Dave, P., Germer, N., Golynski, A., Graney, K., Kang, N., Kissner, L., Korn, J. L., Parmar, A., Richards, C. D., & Wang, M. (2019). "Zanzibar: Google's consistent, global authorization system". USENIX Annual Technical Conference (ATC '19), 33–48. Relationship-based (ReBAC) global authorization with externally consistent decisions; bibliography-only. CITATION-FIX: original wrongly attributed first author as 'Pomerantz' and venue as 'USENIX Security'; correct lead author is Pang and venue is USENIX ATC 2019.

[9] Cloud Native Computing Foundation. SPIFFE — Secure Production Identity Framework for Everyone. Workload-identity standard (SPIFFE IDs / SVIDs) and the SPIRE runtime that issues them, underpinning service-to-service authentication referenced in the Broad Use section; bibliography-only, official project site linked.

[10] Chen, S., et al. (2014). "Eventual consistency and access control in wide-area systems." IEEE Transactions on Dependable and Secure Computing, 11(1), 76–88.