Keeping user identity through automated workflows

A workflow that chains several automated steps together tends to accumulate a quiet problem: each step was built by someone who only had to think about their own step, not the whole chain. That’s fine for logic. It’s a liability for identity, because identity is exactly the kind of thing that’s easy to drop when you’re only looking at one link.

The failure mode we kept running into while examining existing chains wasn’t malicious — it was architectural convenience. A step receives a request, does its job, and calls the next step using whatever credential it has on hand, which is often a service credential rather than the original requester’s identity. Nothing about that is wrong in isolation. Stacked across five or six steps, the original “who asked for this” has usually been replaced by “which service called which service,” and that’s a much less useful fact when something needs to be audited later.

The fix isn’t exotic, but it’s not free either: every step has to accept an identity context as an explicit input, not assume it, and pass it forward rather than substitute its own credential. That means the interface between steps has to carry more than the business payload — it has to carry who’s asking, consistently, the entire way through.

The part worth flagging honestly: this gets harder, not easier, as the chain gets longer, because every additional step is another place where someone could reasonably decide it’s simpler to just use the service account. Keeping identity intact through a long chain is less a one-time design decision and more an ongoing discipline every step has to maintain.