Turn classification into an enforced access decision

A classification can describe sensitivity, collection source, allowed projects, or other organizational handling requirements. Define the vocabulary and who may assign or change attributes. One label need not form a total severity ordering; a dataset can simultaneously have project, regional, confidentiality, and purpose restrictions that cannot be replaced by one numeric level. Derived embeddings, logs, temporary exports, and small lookup tables can retain relevant attributes even after direct identifiers are removed. Inheritance rules need to follow the actual transformation and policy rather than assume that aggregation or hashing automatically produces unrestricted data.

Attribute-based access control evaluates information about the subject, object, requested action, and relevant environment against a policy. A service account's ability to authenticate is not enough to decide that it may export a particular dataset for training. The purpose claimed in an arbitrary request header is also not automatically a trusted authorization attribute. Establish where project membership, service identity, approved workload identity, and policy versions come from. Missing or unverifiable inputs need defined behavior, commonly denial for a protected action, instead of silently turning unknown into an allow decision.

A policy decision point can answer whether an operation should be allowed, but a policy enforcement point must apply the answer before returning or modifying protected data. A notebook gateway check is incomplete if its credentials also permit direct object-store reads outside that gateway. Inventory alternate APIs, batch jobs, copies, caches, and administrative paths. An engine's row or column controls protect only the operations and identities covered by its documented semantics. For example, PostgreSQL row security has explicit owner and privileged-role behavior; enabling a feature is not proof that every application or administrative role is mediated identically.

Tie decisions to the requested dataset version and operation scope, and handle policy changes while requests or cached credentials remain active. A cached allow decision needs an expiration or invalidation policy appropriate to the requirement. Log enough decision context to reconstruct why access was granted without unnecessarily copying sensitive payload into the audit trail. If authorization and data retrieval occur separately, define how a version or policy change between them is prevented or revalidated. The objective is a reviewable enforcement contract, not a collection of labels whose authority disappears when data moves to another system.

Test denied requests as well as successful ones: wrong project, absent classification, unapproved export action, stale grant, revoked purpose, and access through an alternate endpoint. Use realistic identities and confirm the data operation itself fails, rather than testing only a policy helper's returned Boolean. Check that transformed training artifacts carry the required restrictions and that credentials issued to a job cannot bypass its intended dataset scope. An audit record of a denied gateway request does not show that an untested direct storage path was denied too.

The probability lab gives a narrow discovery thought experiment. For each separate view, Reset, set both p=0.05 and n to 20 or 30, predict the zero-discovery bar, then inspect. Success means a hypothetical independently selected test exposes one access-control defect. The instrument does not execute policies, authenticate identities, or establish coverage of bypass paths. An omitted path can have no chance of being exercised by the chosen test suite at all. Use deterministic boundary cases and actual resource-side checks to verify enforcement instead of translating a hypothetical test probability into a permission guarantee.