Foundry combines mandatory and discretionary access controls to govern who can interact with what data. These two families differ in a property that is critical to designing a secure pipeline or application: propagation. Mandatory controls travel with data through derivation and downstream consumption. Row and column access controls (including restricted views, object security policies, and property security policies) filter what a user can read. These controls do not extend beyond that read.
This page describes the propagation behavior of each control family, identifies where the distinction matters, and provides guidance for choosing the right control for a given goal.
This page is a reference for how access controls propagate. For an overview of the security model as a whole, see Security and governance. For a list of terms used here, see the Security glossary.
Mandatory controls are enforced by the platform regardless of any user's role or any application's logic. The mandatory controls are:
Mandatory controls propagate through derivation. For example:
Propagation means that no derived artifact can expose data to a user who lacks the required marking, classification, or organization membership. The control evaluates against the running user's identity at every point of access.
Discretionary controls grant access to specific users or groups on specific resources. The discretionary controls relevant to row and column protection are:
These controls filter what a user can read. The platform compares the user's attributes and group memberships against the policy and returns only the rows or fields the user is authorized to see.
After the read, the rows that the user did receive are ordinary data. They carry no metadata, classification, or tag that subsequent code can use to re-apply the policy.
Row and column access controls filter what users can read. The following operations do not carry the source policy:
In each case, the running user could not have read what they were not authorized to read; the access guarantee holds. What does not hold is propagation: the constraint that protected the source data does not constrain what happens with that data after the read.
Use the following guidance when choosing access controls for a data product:
For stronger protection, apply a marking to a restricted view's backing dataset. This ensures that any consumer building further derivations is still governed by the marking, including consumers who read from a sibling restricted view or bypass the view entirely.
The following questions address common points of confusion about how mandatory and discretionary controls differ in practice.
The read-only property of a restricted view prevents its schema and columns from being altered. This is an integrity property of the restricted view as a resource, not a confidentiality guarantee on the rows a user can read.
A marking on the resource provides a propagating mandatory control. A granular policy on a restricted view provides a non-propagating discretionary filter. Removing the marking trades a control that travels through derivation for one that does not. To keep data protected through downstream outputs and exports, keep the marking.
Applications that "respect the security model" read data under the user's permissions. This guarantees that a user cannot read what they are not authorized to read. It does not guarantee that what the user reads remains under the source policy after the read. User-permission inheritance provides the access guarantee; it does not provide the propagation guarantee.
Projects are the primary container for discretionary role grants. Mandatory controls (markings, CBAC, organizations) remain in force across projects and through derivation. When the protection goal requires a hard boundary that derived artifacts cannot escape, mandatory controls provide that boundary; projects provide role-grant convenience.