You must set one estate-wide rule for which downstream systems mint per-consumer credentials — what makes a system qualify, and what makes you keep a shared credential there?

## Why this needs a rule rather than a case-by-case instinct Once one team demonstrates per-consumer issuance against one system, the question arrives for every system in the estate, and the default answer becomes "generated is better". It usually is — but it is not free, and applied indiscriminately it produces standing privileged identities in systems nobody examined. A written rule does two things: it makes the capability test explicit, and it makes the cost visible to the people who operate the far side. ## The capability gate: three questions, all of them yes 1. **Can a principal be created programmatically**, with a name the store chooses and a value it can read back once? If accounts are created by a person, or arrive by synchronisation from somewhere else, the answer is no and the rest is moot. 2. **Can rights be attached narrowly, per principal, at creation?** If every account the system can create ends up with the same broad rights, minting buys attribution and nothing else — sometimes worth it, but it must be claimed as *that* and not as a reduced blast radius. 3. **Can the store remove a principal without a human?** This is the one most often waved through, and it is the clearest disqualification. A system that creates and cannot remove leaves you accumulating access you cannot end, with a population that only rises. That is a worse position than one shared credential whose existence everyone knows about. ## The cost gate: what the store must hold there The second half of the rule is about the minting identity the design requires: - **Bounded, or unbounded?** Where the system enforces that a grantor may hand out only rights it holds itself, you can deliberately hold a weak identity and cap everything it will ever create. Where it does not, the narrowness of each account rests entirely on the store's rules being right. - **Does it need rights to the data itself?** Where creating and granting is possible without reading, arrange that; it makes a compromise of the minting identity a route to access rather than access itself. - **Who operates the system?** A minting identity in a system another team runs is a standing negotiation: their limits, their upgrades and their idea of who may hold an administrator become your dependency. That is not a reason to refuse, but it is a reason to agree it in writing rather than by ticket. If the only path to create-and-grant is an unrestricted administrator, name the trade plainly: **a shared read credential has been exchanged for a standing administrator**. Sometimes that is still right, because the shared value had copies nobody can find while the administrator is one identity you can watch and remove. Sometimes it obviously is not. ## The value gate: where it is worth doing | Situation | Value of minting per consumer | |---|---| | Many consumers reading a system that holds a lot | Highest — blast radius and attribution both improve | | One consumer, one dataset, one credential | Low — you have added a dependency to save little | | A credential already copied into several places | High — the copies stop being the unit of risk | | A system that cannot attach narrow rights | Attribution only; say so | | A system with a hard principal cap near your fleet size | Conditional — budget the population first | The driver is **how much one credential reaches**, multiplied by how many holders it has. A widely-held credential to a system holding many datasets is where this design pays for itself; a single job reading a single table is where it mostly adds moving parts. ## Writing the rule down A usable estate rule is short and testable: - **Qualifies** when the system supports programmatic create, narrow grant and remove, *and* the minting identity can be bounded to the rights the template produces. - **Qualifies conditionally** when it supports all three but caps the principal population — subject to a budget for live accounts and an alarm on the fraction of that cap consumed. - **Does not qualify** when removal is not programmatic, or when the minting identity would be an unrestricted administrator in a system whose owner has not agreed to that. - **Where it does not qualify**, the system keeps a shared credential with a named owner, a recorded list of holders, and an honest statement that this is a residual risk rather than a decision quietly left unmade. ## The judgment an interviewer is listening for The weak answer is "generate everywhere, static credentials are bad". The strong answer accepts that this design concentrates power in the store, tests the far side's capability before promising anything, quantifies the win by what one credential reaches, and can name the systems in the estate where the honest answer is *no* — together with what is done instead so that "no" does not mean "forgotten".