Every step of a data-export workflow shares one execution role. How do you rate and fix that?

## The structural claim In a managed cloud workload the execution role is the perimeter. There is no host to compromise and no network position to earn: code that runs holds credentials, and what those credentials reach is what an attacker who reaches that code can reach. It follows that **two steps sharing one role are one element in the threat model**, no matter how many boxes the workflow diagram draws, and the blast radius of either is the **union** of every permission the role holds. That sentence is the whole answer, but it has to be said in a way that survives contact with a room that does not want to hear it. ## The scenario A data-lake export runs as an orchestrated sequence: read a raw customer extract, transform and de-identify it, write the result to a partner-facing store, then send a completion notification. It was built quickly, so the orchestration was given one execution role covering everything any step needs - read on the raw extract, write on the output store, publish on the notification topic. The attacker position that makes this bite is not an outsider on the internet. It is a **compromised third-party library** pulled into the notification step - the least scrutinised, most trivially-reviewed dependency in the workflow, in the step nobody thinks of as sensitive. At runtime that library holds the shared role, and the shared role reads the raw extract. The asset at stake is personal data for every customer in the export. ## Rating it honestly Risk is a rated consequence, and the mistake teams make is to rate per box. The notification step gets a low rating because it *only sends a message*. The correct rating uses two facts: - **Consequence** is set by the widest grant the role holds, because that is what the compromised code can use - here, bulk read of personal data. - **Likelihood** is set by the most exposed step, not the average one. A step pulling third-party dependencies, or parsing input from outside, is where compromise starts, and the sharing means the entry does not have to happen at the sensitive step. Combining the *widest* consequence with the *weakest* entry is the whole reasoning, and it inverts the intuition that a notification step is boring. Presenting it as a picture helps more than a score does: draw the four steps, then draw one ring around all of them labelled with the role, and let the room see that they built one element. ## The fixes, in the order I would spend on them 1. **Split the role per step.** The default should be one role per step with only that step's permissions - the notification step gets publish only. This is the change that makes the diagram's boxes mean something. 2. **Split first where exposure meets reach.** If you cannot do all of them this quarter, do the steps that combine untrusted input or third-party code with proximity to the widest grant. Splitting two low-exposure steps that both need the same permission buys nothing. 3. **Narrow the data, not only the permission.** A step that receives the raw extract as its input payload holds that data no matter how small its role is. Pass identifiers or an already-de-identified payload, so the sensitive bytes stop travelling through steps that have no business seeing them. 4. **Make the sensitive grant conditional where the platform allows it.** Scoping the read grant to a specific prefix or resource, rather than the whole store, shrinks the union even where a role must be shared. ## The tradeoff to own Per-step roles are not free. There are more roles to define, review and keep in step with code changes; a step that gains a new dependency needs a permission change and therefore a deployment; and teams under delivery pressure route around that friction by widening a role *temporarily*. A lead who mandates per-step roles without making them cheap to create and change gets one wide role again within two quarters, just with more paperwork. So the strategy has two halves: the rule that the role is the unit of the threat model, and the plumbing that makes a narrow role the path of least resistance. There is also a genuine limit to be honest about. Splitting roles reduces what one compromised step reaches; it does not stop the step from doing its own job maliciously. The notification step with publish-only permission can still publish a false completion. That is a different threat - integrity of the signal - and it is fixed by what consumers of the notification are allowed to conclude from it, not by the role split. ## What a strong answer sounds like Name the role as the perimeter, rate by the union, identify the most exposed step as the likely entry, propose per-step roles with a stated first cut, mention narrowing the payload as the fix the role split does not cover, and be explicit about the operational cost you are asking the organisation to carry.