Delegation you can put a number on

Auth0 published a piece recently on the revenue potential of shared accounts, arguing that fine-grained authorisation turns a security problem - password sharing, blocked spending - into a monetisable relationship. Two of their examples stuck with me: a parent who currently blocks all in-game spending because there's no middle ground between "full access" and "none", and a family grocery app where a teenager either shares a login or relays every purchase request through a parent manually.

Every delegation in this series so far has been bounded by time - a not_expired condition checked against a valid_until timestamp. Neither of those two examples is really a time problem. In this post I will detail the model's other kind of bounded grant, spender, conditioned on an amount and, for the grocery case, a category as well - and where it turned up again, unexpectedly, in a completely different vertical about growing up rather than shopping.

Two conditions, one new relation

condition within_budget(amount: double, limit: double) {
  amount <= limit
}

condition within_allowance(amount: double, limit: double, category: string, allowed_categories: list<string>) {
  amount <= limit && category in allowed_categories
}

Milo's parent grants him spender on the family gaming account with within_budget capped at $20 - he can buy an in-game item for $12, and is denied at $45, in the same time-unbounded relationship the whole while. Theo's within_allowance grant adds a second dimension in one evaluation: $15 of snacks passes, $15 of electronics doesn't (wrong category), and $45 of snacks doesn't either (right category, over budget). Leo, the account owner in both cases, can always spend regardless of amount - an unconditioned role beats a conditioned grant, the same rule that let an unconditioned admin beat a time-bounded delegate for view access in the earlier posts in this series.

What the cap actually checks

Neither condition is a running total, and it's worth being honest about that rather than letting the diagram imply more than it delivers. Auth0 FGA holds nothing between checks - whatever amount the application passes into this specific check is compared against the limit written on the tuple. A per-purchase cap falls out of that for free. A monthly cap does not: the application has to add up what's already been spent this month and pass that running total in as amount itself. FGA can't infer a cumulative budget from anything it remembers, because it doesn't remember anything - every check is stateless by design, which is exactly what makes it fast enough to sit in the request path in the first place.

The same primitive, applied to growing up

I hadn't planned to reuse spender outside a shopping context, and then parental controls turned out to need the identical shape. Zoe (nine) has a gaming profile her parent owns outright - view only. Sam (fifteen) adds spender, capped at $15 per purchase - the same within_budget condition, unchanged. Alex (seventeen) is the interesting one: he already holds owner on his own profile, the way a real custodial bank or brokerage account often names the minor as the account holder from day one, with a parent or guardian holding supervisory admin rights only until majority.

That last detail - Alex being owner from day one rather than becoming owner "at eighteen" - comes directly from a limit worth flagging before anyone tries to build the opposite: this model's conditions only ever bound an end. not_expired is current_time < valid_until; there's no lower bound at all. There's no way to make an unconditioned grant switch on at a future date, which means whatever should exist before a threshold has to already exist as a tuple, and only what should stop at a threshold gets the condition. Leah's supervisory admin over Alex's profile carries not_expired set to his eighteenth birthday; Alex's own ownership was never going to need a start date at all.

Covering for someone on leave is a role, not a delegation

That same time-bounded-but-not-a-delegation shape showed up a third time, in a vertical about neither shopping nor children. When Brightco's IT administrator goes on leave, an ordinary staff member covers her admin duties directly - not on her behalf, in his own name, with not_expired attached to the grant. It looks like Felix's view-only delegation while a family's account owner travels, from earlier in this series, and it deliberately isn't one: nobody is acting for anybody else here, someone is just temporarily promoted. Once the leave period ends, the elevated admin lapses on its own and the employee is back to his ordinary role, without anyone writing a removal tuple.

Next Steps

Time-bounded, amount-bounded, and now time-bounded-but-not-delegated all turn out to be variations on the same handful of primitives rather than three separate features. A follow-up post pushes those primitives somewhere I hadn't originally scoped for this model at all: an AI agent as the thing being delegated to, and the gap between a delegation being requested and being approved.