I built our JIT access system in a day
We wanted just-in-time permissions at Oscilar.
The rules are simple: everyone gets read-only by default. If you need to change something, you ask for higher access for a short time. When the time is up, the access ends.
I looked at two vendors. Both were about $1000 per seat per year. We have 60 people. That’s $60K a year. If we double headcount, it becomes $120K.
For what we needed, that felt wrong. This kind of tool should do three things: take a request, add a user to a group, and remove them later. It should log what happened. It should not be a big system.
So I built it with Claude. It took a day of focused work.
At Segment, when I was single and childless, I would’ve done it in a few late nights. At Confluent, we might’ve paid. Now I’m married with two kids. I don’t have those nights. AI doesn’t give me more time, but it makes the time I have go further.
The system
It’s a Slack app backed by a small service called admitter.
People request access like this:
/access <group> <duration> <reason>We have three permission sets:
- Viewer (default)
- Developer (auto-approves)
- Administrator (requires approval in Slack)
When a request is approved, admitter adds you to the right Google Group. That group syncs to AWS Identity Center in about a minute. When the timer ends, admitter removes you.
Admitter logs every request, approval, and revocation. It also supports manual revocation.
If Slack is down, we can still operate:
- there is an admin CLI
- worst case, we edit the Google Group directly
The full path:
Slack (/access) -> admitter -> Google Group -> AWS Identity Center -> AWS roles
\-> audit logThat’s the whole thing. One day of work. Low compute. Low upkeep. It saves about $60K a year today.
The sharp edges
- Revocation is not always instant. Removing someone from a group stops new access quickly, but it does not necessarily kill an active session. In practice, access ends after propagation delay plus the session lifetime. On AWS and EKS, the shortest practical session durations are typically 15 minutes, so that becomes the lower bound. If you care about this, you have to set those limits explicitly and test them.
- Auto-approval only works if the role is genuinely low risk. Developer is safe only if it cannot touch prod, read sensitive data, or mint credentials. If it can, it needs the same controls as admin.
- Slack is only the front end. The real identity is your SSO or Google Workspace user. The service must map Slack users to that identity and refuse requests it cannot map.
- Small code can still be powerful. This service can grant access into AWS. It needs the usual hardening: verify Slack signatures, use least-privilege credentials, rate-limit abuse, alert on odd use, and log everything.
Why build beat buy here
A lot of B2B software is annoying but not hard. For years, buying won because building took too long.
I wouldn’t trust AI to replace judgment or experience. I could have built this without Claude and kept it secure. It just would have taken long enough that we would have delayed it or bought a tool instead.
This worked because the parts were familiar. Google Groups is the control point. SSO syncs to AWS Identity Center. Slack is the request and approval front-end. Claude helped write the glue, but the design was already clear.
AI cut the time. It didn’t remove thinking. It multiplied it. That was enough to change the math.