Introduction

Scenario: You are the platform administrator standing up a Foundry enrollment that will host several distinct defense programs side by side, and your first job is to confirm the mission Organization is a hard silo and to put the right administration roles in the right hands.

This unit establishes the top of Foundry's administrative model: the enrollment, the Organizations inside it, and the Control Panel roles that govern them. An enrollment is a single instance of the Foundry platform, and it is made up of one or more Organizations. An Organization is not a cosmetic grouping — it is an access requirement applied to Projects that enforces a strict silo between groups of users and resources, and every user has exactly one primary Organization (with optional guest access to others). For a multi-program defense deployment this is the first line of separation: it is what keeps one program's people and resources from bleeding into another's by default. Critically, each Organization is backed by an underlying Marking, which is why an Organization behaves as a mandatory control rather than something an over-eager Project owner can grant around.

Why this matters to the admin and security problem: in Foundry, mandatory controls (Organizations and Markings) always win over discretionary controls (Project roles). A user can hold an Owner role on a Project and still see nothing if they are not eligible for the Organization that gates it. Getting Organizations right at the top therefore prevents the most expensive class of misconfiguration — accidental cross-program disclosure — before any group, Project, or dataset is created downstream. Control Panel is Foundry's centralized interface for administering all of this, and it manages permissions at two strictly independent levels: the Enrollment level and the Organization level. A role at one level says nothing about authority at the other, and that independence is deliberate.

By the end of the unit you will produce a documented Control Panel administration plan and make at least one real organization-level role assignment. The roles you work with are the Enrollment administrator (the top enrollment role), the Organization administrator (the top role within an Organization), and the Technical Compliance Officer (TCO) that each Organization should designate, plus custom roles assembled from individual workflows. You will also learn the honest limits of verification: some of these facts (the enrollment-versus-organization permission matrix, the TCO designation) live only in Control Panel and your written plan, because no public read API exposes them — so part of doing this well is attesting to what you configured, not pretending an API confirmed it.

Capability focus: Control Panel role model (enrollment vs organization administrators, Technical Compliance Officer, custom workflow roles); Organizations as mandatory marking-backed silos. · Artifact: A documented Control Panel administration plan plus an organization-level role assignment.

Key concepts

Companion video

1. 1

   Confirm the target Organization exists and is backed by a Marking

   Confirm that the mission Organization actually exists as a marking-backed silo rather than just a label someone typed. Using Admin-v2 Get Organization (GET /api/v2/admin/organizations/{rid}, scope api:admin-read), resolve the Organization by its rid; the response returns the rid, name, an optional description, an optional host, and — the part that matters here — the Organization's underlying markingId. A non-empty markingId is the proof that this Organization is enforced as a mandatory control: that backing Marking is what makes Organization membership silo users and resources regardless of any Project role. In practice you are confirming two things at once: the Organization resolves, and it carries a backing Marking. If the markingId came back empty you would treat that as a configuration problem to fix before proceeding, because an Organization without its mandatory marking is not the hard boundary a multi-program deployment depends on.

   not startedinstance check

   Run check

   Confirms the mission Organization resolves and carries an underlying mandatory Marking.

2. 2

   Confirm an organization-level role assignment was created

   Make and then confirm a real organization-level role assignment so administration of this silo sits with the right group, not a single person. In Control Panel, at the Organization level, grant the Organization administrator role to the mission security admins group (grant to a group, not an individual, so the authority survives staffing changes and stays auditable). To verify the grant exists, call Admin-v2 List Organization Role Assignments (scope api:admin-read) for the Organization rid; each assignment comes back as a principalId, a principalType (USER or GROUP), and a roleId. Note that the read returns the roleId, not a friendly name — so you confirm the grant by matching the expected group principal and the expected role's ID (using your roleId-to-label crosswalk to read it back in human terms). The check here is existence of the grant: the expected group/principal appears with the expected roleId at the organization scope.

   not startedinstance check

   Run check

   Confirms a group was granted the Organization Administrator role at the org level.

3. 3

   Enumerate the roles available in the Organization for the role plan

   Ground your role plan in the roles that actually exist in this Organization rather than ones you assume are available. Call Admin-v2 List Available Roles (Organization) to return the Organization's role catalog, then confirm that the roles your plan references appear in it — here both the built-in Organization administrator and the custom, organization-specific Mission Security Officer workflow role you intend to use. Because Foundry returns role IDs (not names), enumerating the catalog is how you bind your written plan to real roleIds and catch a typo or a role that was never created. This is also where the distinction between built-in and custom roles becomes concrete: the Organization administrator is a standard top-level role, while a Mission Security Officer is a custom role assembled from individual workflows for this Organization. The assertion is simply that the expected role IDs are present in the available-roles catalog so the plan can reference them safely.

   not startedinstance check

   Run check

   Confirms the role catalog exposes the Organization Administrator and the custom Mission Security Officer role the plan references.

4. 4

   Document enrollment-vs-organization permission separation and TCO designation

   This step is a documented, self-attested checkpoint — record it in your Control Panel administration plan rather than expecting an API to confirm it. Write down two things explicitly. First, that the Enrollment and Organization permission levels are strictly independent: a role granted at the enrollment level conveys no authority at the organization level and vice versa, so your plan must state who holds Enrollment administrator separately from who holds Organization administrator. Second, name the Technical Compliance Officer for the Organization, and note that if none is named the role defaults to the Organization administrator. The honest reason this is a manual attestation: no public read API exposes the enrollment-versus-organization permission matrix or the TCO designation, so there is nothing to query and a verifier can only confirm that you recorded it. Treat the written plan as the artifact of record here, and be precise — this is a checkpoint that depends entirely on your accuracy, not on a machine check.

   not startedself-attested

   Mark complete

   Self-attested: enrollment and organization permission levels are strictly independent; a Technical Compliance Officer is designated.