Security & access
WARRANT
Access gets granted once and never revoked. Someone needs admin for a one-off migration and still has it eighteen months later.
Click to preview · 2× speed
Stack/Tools
What it does
Borrow access, not own access. Every grant expires by default, whether it was given to a person directly or inherited through a group. If you still need it when it runs out, you ask again.
Users request a role on a resource with a reason and a duration. Owners approve manually, or set policy rules that auto-approve low-risk requests within a role ceiling. A background job sweeps expired access and flags grants nobody has used in days.
And for any user and resource, the system explains exactly why they do or don't have access: a direct grant, an inherited group grant, or nothing at all.
The hard part
An access check that can't trust its own data.
A cron job sweeps expired grants on a schedule, which means there's always a window between a grant's real expiry and the next run. If access decisions read the cached status field, they'd wrongly grant access inside that window.
So every check re-derives validity from the timestamp, live, every time. The cron job's job is narrower than I first assumed: flip status, write the audit entry, send the notification. It's the janitor, not the source of truth.
That distinction reshaped how I thought about every background process in the system afterwards.
A decision I'd defend
PostgreSQL over MongoDB. Access control is inherently relational. Grants reference resources, roles, users and groups, and the correctness of the whole system depends on those relationships actually being enforced.
Postgres gives real foreign keys and referential integrity, and Prisma's `include` performs actual SQL joins rather than the multiple round trips `.populate()` needs in Mongoose. For a system whose entire premise is reasoning correctly about who has access to what, that mattered more than familiarity.
Selected screens
Where it stands
Shipped and live with a public demo login, so you can see the whole system rather than a scoped-down guest view.
Distinct audit actions covering every way access can begin, change hands or end. Requests must escalate rather than duplicate, and a higher grant supersedes lower ones automatically.
What's still missing
Auto-approval caps the role but not the cumulative duration, so someone could split one long access need into several short auto-approved requests to avoid manual review.
The group branch of the access check runs one query per group the user belongs to. It's an N+1 that hasn't mattered at this scale and would need collapsing at any other.
Surrendering a group grant writes an audit entry but notifies nobody, so members lose access without being told.
Full reasoning for all three is in the README.
I wrote up the whole build: the design decisions, the bugs that actually taught me something, and what I'd do differently.
Demo loginadmin@warrant.devadmin12345