Outcome
By the end of this lesson, you will be able to name the four policy families that are never auto-imported, explain why an account holding AdministratorAccess does not change that, and promote someone deliberately afterwards.
| Tier | Architect |
| JTBD | ”Make sure an import cannot hand anyone the ability to change our access model.” |
| Personas | Security/Compliance · Engineering Leader |
| Prerequisites | M3.9.L2 |
| Time | 9 minutes |
| Bloom verb | Name (Remember), Explain (Understand), Promote (Apply) |
1. Concept
Four policy families are never auto-imported, at any tier of the translation staircase, regardless of what the cloud grant says.
role:* create / update / delete rolesuser:* create / update / delete usersassignment:* assign roles to usersorganisation:* org administration
NOT IMPORTED. Ever. Not even for AdministratorAccess.Why AdministratorAccess does not change it
This is the case that makes the rule legible.
A PRINCIPAL WITH AWS AdministratorAccess CAN DO ANYTHINGIN THAT AWS ACCOUNT.
An obvious translation is "this person should be aZopNight Admin, including managing roles and users".
THAT TRANSLATION IS REFUSED, and here is why it has to be:
A tool that can import the ability to change the access model can import a WIDER access model on the next run.
The exclusion is what keeps the import from being able to escalate its own effects.Put differently: if org-management grants were importable, then a single mis-scoped cloud role could grant someone the power to reshape ZopNight’s entire RBAC configuration, and a subsequent import could inherit and widen that. Excluding the four families breaks that chain structurally rather than relying on the review step to catch it.
It is the same principle as everywhere else
You have now met this argument four times in this curriculum, in four different mechanisms. That repetition is deliberate.
M3.1 Editor cannot manage RBAC, so a compromised Editor cannot escalate itself to Admin.
M6.5 RBAC and user management are never exposed via MCP at any write tier, so an agent cannot widen its own caller's permissions.
M2.3 The Safety Gate fails closed on destructive levers, so absent evidence cannot authorise a delete.
M3.9 Org-management grants are never auto-imported, so an import cannot grant the power to reshape access.The common shape: the mechanism that bounds a capability is never reachable by that capability. If you can articulate that, you can predict this product’s behaviour in situations no lesson covers.
What happens instead
The import proposes everything else it can, and the org-management portion simply does not appear. There is no error and no Needs Attention entry: it is not an unresolved case, it is an excluded one.
SO A CLOUD ADMINISTRATOR ARRIVES AS a proposed ZopNight role carrying the operational and reporting policies their cloud grant implies
AND NOT AS someone who can create users, edit roles, assign roles, or administer the organisationPromoting deliberately
Promotion happens later, by hand, from Settings -> Roles.
That is a SEPARATE, EXPLICIT, AUDIT-LOGGED action takenby an existing Admin.The distinction is not bureaucratic. An imported grant carries the intent of whoever wrote the cloud policy, possibly years ago and for unrelated reasons. A promotion in Settings carries the intent of the person clicking it, right now, about ZopNight specifically. Those are different quantities of consent and the product treats them differently.
How to plan around it
BEFORE the import: decide who your ZopNight Admins are.It should be a short list, and it has nothing to do withwho holds AdministratorAccess in AWS.
AFTER the import: promote that short list by hand.
M3.1.L2's guidance applies: for each Admin, name thespecific Admin-only capability they need. If you cannotname one, they are over-permissioned.In practice the ZopNight Admin list and the cloud administrator list overlap only partially, and noticing that is one of the more useful outcomes of running an import at all.
2. Demo
An import into an org with four cloud administrators:
CLOUD SIDE 4 principals hold AWS AdministratorAccess devops-lead@ sre-lead@ platform-eng-01@ (holds it for a migration, temporarily, for 8 months now) terraform-ci (a service account)
WHAT THE IMPORT PROPOSED devops-lead@ role with operational + reporting policies sre-lead@ same platform-eng-01@ same terraform-ci -> Needs Attention (service-account-only, L2)
NONE of them proposed with role:*, user:*, assignment:* or organisation:*.
No error. No Needs Attention entry for the exclusion. Those policies simply are not in the proposal.
WHAT THE TEAM DID NEXT Asked the M3.1.L2 question for each: name the specific Admin-only capability this person needs.
devops-lead@ "connects cloud accounts, manages roles" -> ADMIN sre-lead@ "...nothing, actually. They operate schedules and read reports." -> EDITOR platform-eng-01@ "nothing. The migration ended." -> EDITOR (and someone opened a ticket to remove their AWS AdministratorAccess too) terraform-ci dropped
RESULT: 1 ZopNight Admin, from 4 cloud administrators.
THE SECOND-ORDER OUTCOME The import did not just populate ZopNight. It surfaced that platform-eng-01@ had held AdministratorAccess in AWS for eight months past a two-week migration, which nobody had reviewed.
Running an import is one of the cheapest ways to get a fresh look at your cloud access model, precisely because it forces someone to read the principal list with a specific question in mind.3. Hands-on (6 min)
1. Before importing, write your intended ZopNight Admin list: ______________________________________________ How many? ______
2. Now list who holds administrator-equivalent access in your cloud: ______ How much do the two lists overlap? ______
3. Run an import. Confirm that NO proposed role carries role:*, user:*, assignment:* or organisation:*. Confirmed? Y / N
4. For each person you intend to promote to Admin, name the specific Admin-only capability: ______________ needs: ________________________ ______________ needs: ________________________ Any you cannot name is not an Admin.
5. Note anything the exercise surfaced about your CLOUD access model rather than ZopNight's: ______________________________________________Step 5 is frequently the most valuable output.
4. Knowledge check
Q1
A principal holds AWS AdministratorAccess. The import proposes a ZopNight role that:
A. Includes both role and user management, exactly matching the cloud grant that it was originally derived from in the first place
B. Carries the operational and reporting policies their grant implies, and excludes role:*, user:*, assignment:* and organisation:* entirely
C. Is placed in Needs Attention so that a person has to resolve it manually afterwards, by hand, before it applies
D. Is rejected outright as being far too broad a grant to propose safely at all to a customer’s organisation
Show answer
Correct: B. Those four families are never auto-imported at any tier, regardless of the cloud grant. Note that this is an exclusion rather than an unresolved case: there is no error and no Needs Attention entry, because nothing is ambiguous. The org-management portion simply does not appear in the proposal.
Q2
The reason org-management grants are excluded is:
A. They are provider-specific and simply cannot be translated cleanly at all across the three clouds
B. They require an Admin approval, which the importer does not hold at the time it runs
C. Cloud IAM does not expose them reliably enough for the importer to read them back safely
D. A tool that can import the ability to change the access model can import a wider access model on the next run
Show answer
Correct: D. Excluding the four families breaks that escalation chain structurally, rather than relying on the review step to catch it every time. One principle runs through all of this: the thing that limits a capability is never reachable by that capability. You have met it three times already. Editor cannot manage permissions (M3.1). Permissions are not exposed to an assistant at any write tier (M6.5). The Safety Gate refuses by default (M2.3).
Q3
Promoting an imported user to Admin afterwards is:
A. Automatic, once the import has been applied for a second time in succession later
B. A separate, explicit, audit-logged action from Settings → Roles, taken by an existing Admin
C. Done by re-running the import with a deliberately wider scope
D. Not possible at all for users who arrived through an import
Show answer
Correct: B. An imported grant carries the intent of whoever wrote the cloud policy, possibly years ago for unrelated reasons; a promotion carries the intent of the person clicking it, now, about ZopNight specifically. The two are different quantities of consent, which is why the product treats them differently rather than treating promotion as a convenience the import could have saved you.
5. Apply
Write your intended ZopNight Admin list before running an import, and compare it against who holds administrator-equivalent access in your cloud. The overlap is usually partial, and the gap in both directions is informative.
Then promote by hand, applying M3.1.L2’s test: name the specific Admin-only capability, or do not promote.
Related lessons
- L2: The translation staircase
- L4: Emails, groups and re-import (next)
- T3.M3.1.L2: System roles
- T6.M6.5.L1: The tiered write surface
Glossary terms touched
Org-management grant · AdministratorAccess · Privilege escalation · Promotion