Introduction

Scenario: Your enrollment now hosts several mission programs that share an instance, and new analysts, cleared personnel, and a coalition partner cell are all arriving at once. Before anyone touches a Project or a Marking, you must stand up the Foundry Group hierarchy that every downstream grant will reference.

Unit 2 establishes the unit of access in Foundry: the Group. In Unit 1 you separated enrollment-level from organization-level administration and confirmed that each Organization is a mandatory, marking-backed silo. Now you build the principals that live inside those silos. The temptation on a fast-moving multi-program enrollment is to grant access directly to individuals as they show up, but that produces an access model no one can audit, that drifts the moment someone transfers programs, and that has to be re-done for every Project, every Marking, and eventually every CBAC classification. Modeling access through Groups instead is the prerequisite for every grant you will make for the rest of this course.

A Foundry Group is a named set of principals, and groups can contain other groups. That nesting is what makes the model scale: a parent program-team group can include a clearance group as a member, and a user placed in the clearance group is then a transitive member of the program team without ever being added to it directly. When you ask Foundry who is effectively in a group, you can resolve membership transitively, so the answer reflects the full nested chain rather than just the names added at the top level. This is the difference between the direct members you typed in and the effective members the platform actually grants through.

The artifact for this unit is a mission group hierarchy: a program-team group, a clearance group (for example, cleared-secret personnel), and a coalition group (for example, a FVEY partner cell), with users seeded into the right groups so that nested membership resolves to the intended effective access. You will verify each layer with the Admin v2 API at the api:admin-read scope: that the expected groups resolve by ID, that transitive membership produces the right people, and that a representative user lands in the parent groups you designed. The closing step is a documented design decision rather than a machine check, because the most important rule in this unit, grant to groups and not to individuals, is a discipline you commit to rather than a flag any read API can return.

Capability focus: Provisioning users; Groups, nested groups, transitive membership; grant-to-groups-not-individuals. · Artifact: A mission group hierarchy (program-team + clearance/coalition groups) with seeded members.

Key concepts

Companion video

1. 1

   Confirm the expected mission groups exist

   Start by confirming the mission group hierarchy actually exists as designed. A Foundry Group is the unit of access: roles and grants will target these groups, not the individuals inside them, so they must be in place before any Project or Marking work begins. Using Admin v2 Get Group (or List Current Groups) at the api:admin-read scope, resolve each expected Group by its ID, the program-team group, the cleared-secret clearance group, and the coalition partner group, and verify each returns its name and metadata. This check confirms the three layers of the hierarchy were created; if a Group ID does not resolve, the group was never provisioned and every downstream grant that depends on it would fail or have to be made to individuals instead.

   not startedinstance check

   Run check

   Confirms the program-team, clearance, and coalition groups were created.

2. 2

   Confirm group membership resolves transitively (nested groups)

   Now verify that nesting produces the effective access you intended. Foundry Groups can contain other Groups, and a user placed in a nested clearance group becomes a transitive member of the parent program-team group without being added to it directly. Call Admin v2 List Group Members on the program-team group with transitive=true at the api:admin-read scope, and confirm the returned principals include the analyst users who reach it through the nested clearance group. This is the distinction between the direct members you typed in and the effective members the platform grants through: only the transitive resolution reflects the full nested chain. If an expected user is missing, the nesting is wrong, the user belongs to a sibling group rather than a member group, or the membership was added to the wrong level.

   not startedinstance check

   Run check

   Confirms the program-team group's transitive membership includes the nested clearance group's users.

3. 3

   Confirm a seeded user's group memberships

   Confirm the model from the user's perspective, the inverse of the previous step. A correctly placed person should resolve to exactly the parent groups your design intends, never to access granted to them as an individual. Call Admin v2 List Group Memberships for a seeded user at the api:admin-read scope and verify it returns the expected parent groups, the clearance group they were added to directly and the program-team group they reach transitively through it. This proves the user is positioned entirely through group membership, so that when you later grant a Project role or Marking access to those groups, this user inherits it automatically. If the user instead appears with no group memberships, they were likely granted access directly, which is exactly the anti-pattern this unit exists to prevent.

   not startedinstance check

   Run check

   Confirms a user resolves to the expected parent groups (placed via groups, not individual grants).

4. 4

   Document the grant-to-groups-not-users principle

   This final step is a self-attested design checkpoint, not a machine check, because the principle it captures is a commitment rather than a flag any read API returns. Document why every downstream grant in this course, Project roles in Unit 3, Marking access in Unit 4, and CBAC classification eligibility in Unit 5, will target Groups rather than individual users: nested and transitive membership means a single group change propagates to every place the group is granted, the access model stays auditable, and you avoid the per-resource individual-grant clutter that is unreviewable at multi-program scale. Record the intended mapping (which groups will receive which kinds of grants) so reviewers can confirm the design intent. No READ API exposes 'this grant was made to a group on purpose,' which is why this is attested here and verified by inspection in the units that follow.

   not startedself-attested

   Mark complete

   Self-attested: Project/Marking grants target groups, not individuals, to keep access auditable.