You own a self-service platform where product teams write their own permission documents; what standard keeps a team from granting itself administrator?
answer
- the verbs are ones teams legitimately need
- classify by class, not by action name
- cap it where the team cannot write
- review reach, not documents
- an exception route with an owner and expiry
basics
~20 sName the verb classes that are administrator regardless of how narrow they look — writing permissions, attaching an identity, issuing credentials, taking on an identity — cap every self-service principal with a ceiling it cannot write past, and review reachability rather than documents.
solid answer
~40 sThe trade-off is real: teams must write their own grants to move, and every one of the escalating verbs is something they legitimately need. So the standard has three parts. First, a named list of verb classes treated as administrator whatever resource they point at: writing or attaching permissions, attaching an identity to a workload, issuing credentials for a principal, taking on an identity. Second, a ceiling applied to every self-service principal at creation, in a place the team has no write action against, so a grant they write cannot exceed it. Third, review as reachability over the grant graph rather than document by document, run automatically, because the pairs grow faster than anyone reads. Then an explicit exception path, because a standard with no exception route gets worked around instead of followed.
code
pseudocode · 17 linesESCALATING = [permissionWrite, identityAttach,
credentialIssue, identityTakeOn]
function reviewChange(proposedGrants, principal):
findings = []
for each grant in proposedGrants:
if classOf(grant.action) in ESCALATING:
targets = resolve(grant.targetPrincipals)
if any target is stronger than principal:
findings.append(grant, target)
if grant.condition names no target set:
findings.append(grant, "unbounded target")
if findings is empty:
return approve
if principal has ceiling and ceiling covers findings:
return approveWithNote(findings)
return refuse(findings)go deeper
Understand the goal before the mechanism: teams write their own permissions to move quickly, and the platform's job is to make sure what they write cannot exceed a limit somebody else set.
Be able to name the verb classes that are administrator whatever resource they point at, and explain why an action-name list goes stale while a class definition does not.
Show how you would operate it: reachability computed over the grant graph in the change pipeline and on a schedule, with the difference between reach and direct grant reported per principal.
Own the trade-off out loud — the ceiling will block something urgent, the report will breed false confidence, and the separation between who sets the cap and who is capped is what the whole standard rests on.
## What you are actually trading Self-service permission writing exists because the alternative — every grant queued behind a central team — is the bottleneck that made platform teams unpopular in the first place. So the goal is not to take the capability away. It is to make the set of grants a team can write have a ceiling, and to make the escalating verbs visible as what they are. The distinctive difficulty is that none of the escalating verbs is exotic. Teams attach identities to workloads because that is how anything deploys. They write permission documents because that is what self-service means. They issue credentials for outside integrations. They take on identities across environments. A standard that forbids the verbs forbids the platform. ## Part one: name the classes, not the actions Publish a short list of **verb classes that count as administrator regardless of how narrow the resource looks**, because they change either what a principal may do or who may be that principal. These four account for most of what is found in practice: 1. Writing, attaching or detaching a permission document, and editing a trust condition. 2. Attaching an identity to a workload, where the caller also controls the workload's code. 3. Issuing authentication material for a principal — a static credential, a login secret, an additional factor, a bound key. 4. Taking on another identity. The value of the list is that it is a *class* list rather than an action list. Action lists go stale the week the platform adds an action; a reviewer who has internalised *does this let the team change what a principal may do, or who may be that principal* classifies the new action correctly on sight. ## Part two: a ceiling the team cannot write past Every self-service principal gets a cap attached when it is created, by the process that creates it, owned by a function the team cannot act as. Whatever the team writes into its own documents is then bounded: the grant they authored is evaluated against the ceiling, and anything above it simply does not take effect. This is the part that makes the rest survivable, because it converts every escalation path from *administrator* into *administrator within the cap*. It also has a real cost. The cap will block a legitimate change at some point, usually urgently, and if raising it is undocumented the team will find a principal without one. Platforms differ in whether a construct like this exists and how it composes with the documents below it — where it does not, the honest fallback is to keep the escalating verbs out of self-service entirely and accept the queue. ## Part three: review reachability, not documents Document review finds badly written grants. It does not find escalation, because escalation is a property of the set: an attach action pointing at a strong identity, a chain of hops, an issuing grant naming a principal nobody expected. Run the graph — an edge per escalating verb — on a schedule and in the pipeline that applies permission changes, and report, per self-service principal, the difference between what it may do and what it may reach. | Control | Kind | What it is for | |---|---|---| | Verb-class list | Standard | Makes the escalating grants recognisable at authoring and review time | | Ceiling on every self-service principal | Preventive | Bounds the outcome of every path at once, including ones nobody enumerated | | Reachability report in the change pipeline | Preventive, at change time | Refuses or flags the change that creates a new edge into a strong identity | | Alert on use of an escalating verb against an unexpected target | Detective | Tells you a path was walked; does not stop it | | Exception route with an owner and an expiry | Process | Keeps the standard honest instead of routed around | ## What the standard is worth, and where it is weakest It is worth the fact that no single grant has to be perfect. Nobody authors a correct permission document every time, and a ceiling plus a reachability check means a mistake is bounded and found rather than catastrophic and quiet. Its weakest point is confidence. A team that passes the reachability report concludes it has no escalation paths, when what it has is no escalation paths *among the verb classes on the list, toward the identities the report considers strong*. Keep the definition of a strong identity explicit and revisit it, because the identity a new platform component runs as becomes a prize the moment it is created, and nothing in the report notices that by itself. The other weakness is organisational rather than technical: the ceiling is only as good as the separation between the function that sets it and the teams it constrains. If the same group can both attach the ceiling and detach it on request without a record, the standard is advice.
- A team argues the ceiling blocks a legitimate change and asks for it to be removed for a week. What do you do?Use the exception route rather than the removal: a narrower ceiling for that principal, owned by a named person, with an expiry the platform enforces rather than a calendar reminder. A ceiling removed for a week is a ceiling removed, because nobody reattaches it, and the team learns that asking works.
- How do you keep the definition of a strong identity current?Tie it to the verb classes rather than a hand-written list: any identity holding a permission-writing, identity-attaching, credential-issuing or identity-assuming grant is strong by construction, and new platform components inherit the classification when their grants are authored. Then review the resulting list rather than maintaining it.
- Is the reachability report better run on a schedule or in the change pipeline?Both, for different failures. In the pipeline it refuses the change that creates a new edge, which is the cheapest moment to fix it. On a schedule it catches paths created by changes elsewhere — a new strong identity, a trust condition edited by another team — that no single pipeline run could have seen.
saying these in an interview costs you the question
- Proposes banning the escalating verbs, which stops teams deploying
- Maintains a list of dangerous action names instead of verb classes
- Relies on document review to find escalation paths
- Sets a ceiling the same team is allowed to detach
- Treats a passing reachability report as proof no path exists
- Writes a standard with no exception route and expects compliance