Introduction

Scenario: A coalition mission program needs to host SECRET data alongside material releasable to Five Eyes partners in one Foundry enrollment, so that cleared U.S. analysts and FVEY partners each see exactly what their classification and releasability allow — and nothing more.

This unit takes the mandatory-Marking foundation from Unit 4 and applies it to genuinely classified data using Classification-Based Access Controls (CBAC). CBAC is Foundry's purpose-built model for sensitive government information: classification markings are organized into named categories, and each category is configured to combine either conjunctively (AND) or disjunctively (OR). A clearance level such as SECRET is conjunctive — a user must hold it to see SECRET resources — while a releasability category such as RELEASE TO (REL TO) is disjunctive, where membership in any one releasability marking (for example, REL TO FVEY) is enough to satisfy that category. Modeling classified access correctly means knowing which categories are AND and which are OR, and granting eligibility through clearance-group membership rather than per-user grants.

It matters because classified programs cannot rely on discretionary Project roles alone. CBAC markings are mandatory controls: like Organizations and ordinary Markings, they override a user's Project role, so a SECRET-cleared Editor still cannot read a TOP SECRET resource. In a CBAC environment a Project carries a project classification, and datasets carry a file classification and a data classification — where the data classification is derived automatically from the file classification plus the classifications of upstream data dependencies, so a derived dataset inherits the sensitivity of everything that fed it. Your task is to confirm the classification scheme exists, confirm a CBAC-governed Project actually carries its classification as an access requirement, and map each category to the clearance groups that should satisfy it.

The single most important thing to internalize is that CBAC is not self-service. It is not enabled by default, and turning it on and configuring its categories (including whether a category is conjunctive or disjunctive) requires Palantir involvement — it is a platform-level capability your enrollment must have provisioned, not a toggle an org admin flips. That means parts of this unit are a documented design-and-attestation exercise rather than something you provision live, and the live checks reflect that honestly: some confirm artifacts that do exist (markings, access requirements, group membership), while the category-mode configuration itself is recorded as an attested plan because no READ API exposes it.

Capability focus: CBAC classification markings; conjunctive level vs disjunctive REL TO categories; file vs data classification; clearance-group grants. · Artifact: A CBAC-governed Project with a required file classification plus a category→clearance-group policy plan.

Key concepts

Companion video

1. 1

   Confirm CBAC classification markings exist in the environment

   Begin by confirming the classification scheme your CBAC plan references actually exists in this environment. CBAC builds on Markings, so the level and releasability markings are real Marking resources with a category. Use the Markings administration view (or Admin-v2 List Markings) to confirm two markings are present: a conjunctive clearance-level marking (for example, a SECRET level marking categorized as a classification level) and a disjunctive releasability marking (for example, REL TO FVEY, categorized as a releasability/RELEASE TO marking). The check here resolves each marking and confirms its category — the level marking under the classification-level category and the REL TO marking under the releasability category — so that the rest of your design rests on a provisioned scheme rather than on names you invented. If the markings are missing, that is a signal CBAC has not been enabled/configured for the enrollment, which is a Palantir-involvement dependency, not something you create yourself.

   not startedinstance check

   Run check

   Confirms the provisioned classification scheme: a conjunctive level marking and a disjunctive REL TO marking, each with its category.

2. 2

   Confirm the CBAC Project carries its classification as an access requirement

   Next, confirm a CBAC-governed Project actually carries its classification as an access requirement, proving a file classification was specified rather than merely planned. In a CBAC environment a Project requires a project classification, and that classification surfaces as a mandatory access requirement on the resource. Use the resource's access details (or Filesystem-v2 Get Access Requirements) on the CBAC Project to confirm the expected classification markings — your level marking and your REL TO marking — appear in its markings list. Note that this access-requirements read is a preview endpoint: when run against a live instance, the check may return blocked rather than silently passing, because the preview surface is not always available to the read-only runner. Treat a blocked result as 'could not confirm here', not as a failure of your configuration — and confirm the classification visually in Control Panel / the resource's security panel.

   not startedinstance check

   Run check

   Confirms a file classification was specified on the CBAC-governed Project resource.

3. 3

   Confirm clearance-group eligibility for a disjunctive (REL TO) category

   Now demonstrate disjunctive (OR) access by confirming that a coalition clearance group is a member of the REL TO releasability marking. Because REL TO is a disjunctive category, eligibility for it is satisfied by membership in a single releasability marking: a partner analyst who belongs to the FVEY coalition group, and is therefore a member of the REL TO FVEY marking, satisfies the releasability check without needing every other releasability marking. The check lists the marking's members (transitively, so nested clearance groups resolve) and confirms the expected coalition group is present. Be aware that listing marking members requires the api:admin-write scope — only marking administrators may view marking membership — so against a live instance this check may return blocked rather than passing. That blocked result is expected and honest: it means the read-only runner lacks marking-admin authority, not that the group is missing. Grant eligibility through the coalition group, never through individual users.

   not startedinstance check

   Run check

   Confirms a coalition group is a member of the REL TO classification marking (disjunctive OR access). Live: needs api:admin-write → blocked.

4. 4

   Document CBAC enablement dependency and conjunctive/disjunctive design

   Finally, record the design decisions that no READ API can confirm, because this is where CBAC is a documented and attested checkpoint rather than a live provisioning step. Write down two things explicitly. First, the enablement dependency: CBAC is not enabled by default and requires Palantir involvement to turn on and configure — it is a platform capability, not an org-admin self-service toggle, so your plan must name it as a prerequisite owned outside your control. Second, the category design: state which categories are conjunctive (the clearance level, AND — a user must hold the level) and which are disjunctive (RELEASE TO, OR — any one releasability marking suffices), and map each category to the clearance/coalition groups that should satisfy it. Also capture that a dataset's data classification is derived automatically from its file classification plus upstream data dependencies. This is attested because the category-mode configuration is not learner-provisionable and no READ API exposes which categories are AND versus OR — your written plan and the platform's enablement state are the record of truth.

   not startedself-attested

   Mark complete

   Self-attested: CBAC is not enabled by default (requires Palantir involvement); level=conjunctive (AND), REL TO=disjunctive (OR).