Introduction

Scenario: Your defense enrollment now hosts several distinct mission programs in one Foundry instance, and a new coalition intelligence program needs its own walled workspace where only its cleared team can find or touch its resources. As the platform/security admin you must stand up that program as a Project, grant the right Unit 2 groups the right roles, and prove the boundary holds even against an over-privileged user.

Unit 3 establishes the Project as the primary security boundary in Foundry and the place where you turn the groups you built in Unit 2 into actual access. Organizations (Unit 1) silo whole populations of users and resources, and groups (Unit 2) bundle people, but neither one grants access to mission data by itself. A Project is the container that holds related resources for a single mission program, and it is where you attach discretionary role grants — Viewer, Editor, Owner, and Discoverer — to those groups. Carving each program into its own Project is how you keep one program's analysts out of another program's workspace while still letting both live in the same enrollment.

This matters because in a multi-program defense instance, access mistakes are not inconveniences — they are spillage. Project roles are inherited: a grant on the Project cascades to the resources inside it, so granting the program-team group Editor on the Project means they can edit the datasets, pipelines, and applications beneath it without you wiring up each resource individually. Equally important is what a Project does NOT do: it is a discretionary control. A role grant says a principal MAY access a resource, but it can always be overruled. That is the layering you must internalize — discretionary roles sit underneath mandatory controls.

The hard, defense-relevant lesson of this unit is the mandatory-over-discretionary rule. Organizations and Markings are mandatory controls that ALWAYS prevent an ineligible user from reaching a resource regardless of any Project role they hold. An Owner grant is meaningless to a user who is not in the resource's Organization or who lacks a required Marking. You will confirm the Project exists in the correct Space, confirm role grants landed on the expected groups, confirm the Project's structure by resolving a child resource by path, and then document — because no API exposes it — how the mandatory layer overrides the discretionary one.

Capability focus: Projects as the primary security boundary; role grants to groups; mandatory-over-discretionary layering. · Artifact: A mission Project with role grants to the Unit 2 groups, in the correct Space/Organization.

Key concepts

Companion video

1. 1

   Confirm the mission Project exists and its Space

   Stand up the mission program as its own Project in the correct Space, then confirm it. In Foundry a Project is the primary security boundary, and every Project lives inside a Space tied to its Organization — putting the program in the wrong Space would place a coalition workspace alongside the wrong program. The check resolves the Project by its resource identifier (RID) using Filesystem-v2 Get Project (GET /api/v2/filesystem/projects/{rid}), which returns the Project's spaceRid, creator, and timestamps. Your goal here is to produce that artifact: a real mission Project that resolves and whose spaceRid matches the expected mission Space. If Get Project returns the wrong space, the boundary was created in the wrong place and must be moved before any roles are granted.

   not startedinstance check

   Run check

   Confirms the mission Project resolves in the correct Space (the primary security boundary).

2. 2

   Confirm Project role grants to the expected groups

   Grant the Unit 2 groups their Project roles and confirm the grants landed on the right principals. Roles (Viewer, Editor, Owner, Discoverer) are discretionary and should be granted to groups, not individuals, so that Unit 2 membership changes flow through automatically; a grant on the Project inherits down to the resources inside it. Here you grant the mission program-team group the Editor role on the Project, then verify with Filesystem-v2 List Resource Roles on the Project RID, which returns role grants as principal + role pairs. Two honesty caveats apply: this is a preview endpoint (subject to change), and it returns role IDs, not human-readable role names, so the check crosswalks the returned roleId to Editor rather than matching a name. The check confirms the expected group holds the expected role; it does NOT confirm that the user can actually reach any specific marked resource — that depends on the mandatory layer covered in the final step.

   not startedinstance check

   Run check

   Confirms the program-team group holds the expected Project role (Viewer/Editor/Owner via the roleId crosswalk).

3. 3

   Confirm a resource resolves by its expected Project path

   Confirm the Project's internal structure by resolving a child resource at its expected path. A Project is only useful once it contains the resources the program works on, and a stable path is how teammates and downstream checks reliably locate the same item. The check uses Filesystem-v2 Get By Path to resolve the expected resource path inside the Project — here the mission roster dataset — to a resource RID of the expected type (DATASET), confirming both that the resource exists where it should and that the Project's folder structure is in place. Produce the artifact by creating (or placing) the roster dataset at the documented path under the Project. If Get By Path does not resolve, either the resource is missing or it sits at a different path than the program agreed on, which will break every downstream reference.

   not startedinstance check

   Run check

   Confirms the Project's child resource resolves at the expected path (Project structure in place).

4. 4

   Document mandatory-control override of discretionary roles

   This is a documented, self-attested checkpoint, not an automated API check — and that is the point. Record in your administration plan that Organizations and Markings are mandatory controls that ALWAYS block an ineligible user regardless of any discretionary Project role: a user granted Owner who is outside the resource's Organization, or who lacks a required Marking, still cannot access it. No READ API returns a given principal's effective, layered access, because that combined verdict (discretionary role AND Organization eligibility AND every conjunctive Marking) is computed at access time, not stored as a readable field — so there is nothing for a check to query and confirm. Your attestation should state the rule in your own words and name a concrete example from your instance (e.g., an Editor who is not in the coalition Organization sees nothing), demonstrating you understand that the discretionary roles you granted in the prior steps can only operate inside what the mandatory layer already permits.

   not startedself-attested

   Mark complete

   Self-attested: Organization and Marking eligibility always override discretionary Project roles.