2 min lesson
Friction is a security risk too
Talk this through in your own words: "In a JIT access design, why is it dangerous to implement grant expiry as a background job that periodically removes expired role bindings?" Finish with the next move.
Step 1 of 3
Friction is a security risk toodeveloper empathy is in the JD for a reason
A control that is annoying enough gets routed around. Engineers share a long-lived key in Slack because the JIT flow took four minutes and they were in a hurry. Now you have a worse problem than you started with and you can't even see it. The role explicitly asks for frictionless security, so treat speed as a requirement, not a nicety.
- Low-risk, read-only scopes
- Auto-approve, sub-second grant, no human in the loop. Make the paved road faster than the workaround.
- Write or destructive scopes
- Require a reason and maybe a second approver; this is where a few seconds of friction buys real safety.
- Renewal
- One click to extend an active window, so people don't pre-request huge durations "just in case."
- Discovery
- Make it obvious what you can request and how; hidden permissions get hoarded.
When they hand you the JIT design prompt, state the loop first (request, approve, time-box, revoke, audit), then immediately name the two failure modes that make it real: expiry that doesn't depend on a healthy background job and a break-glass path that is loud and TTL'd rather than a standing backdoor. Close by naming developer friction as a security risk. That arc shows you've built this, not just read about it.