Every Grant Carries Six Limits, Whether or Not Anyone Wrote Them Down

A thief with your card has power over your account. Your treasurer has legal authority over it. The bank's system treats the two identically.

That's not a bug in the bank's system. It's the one thing the system was built to check: can this request get through? The line between those two, between power and the legitimate right to exercise it, is one Max Weber drew a century ago.

I've written about the permission that outlives its grant, the leaver whose access is still working months after their right to act ended. The fix I pointed at was a grant that a machine can measure a request against, instead of a configured copy that drifts. That sentence is easy to write and hard to mean, because it assumes the grant says enough to be measured against. Most of them, as written, don't. Or rather, they do, but only in the heads of the lawyer who drafted them and the manager who signed them, and that part never reaches the system.

So this piece is about what a grant has to say. Two things make a grant real: it has to say how far it goes, and it has to say where it came from. Let's focus on the first, which is composed of six things.

The example, which is invented

Take a treasury mandate, for example. A board authorizes the treasury desk to settle supplier invoices for the third quarter. Here's what that grant actually says, once you write all of it down.

1. What may be done, and how much of it. Move funds, up to two million. The verb and the quantity. A system permission usually has the verb. It almost never has the quantity, or if it does, the quantity is a transaction limit configured by an administrator, not the figure in the resolution.
2. What for. Settle the third quarter supplier invoices, and nothing else. This is the limit people are most tempted to treat as a label, a description of why the grant exists. It's not a label. It's a constraint. Two million to settle Q3 invoices doesn't authorize two million to prepay Q4, and the person who signed the resolution would say so instantly if asked. The system can't ask.
3. Where it holds. Under Delaware law, from the treasury desk. Jurisdiction decides which rules were in force when the act happened, which makes it part of the grant rather than a footnote to it. Location decides which desk, which entity, which regulatory perimeter. An approval that's valid from the New York desk may not be valid from the Singapore one. It's the difference between a permitted act and a breach.
4. When. Until the thirty-first of December. Every grant has a term, and the leaver is what happens when the term ends in the document and not in the system.
5. On what. Only from a production system meeting the controls the agreement named. The grant was made on the assumption that the act would be taken through a particular kind of system, with particular safeguards, and a request from a laptop over a coffee shop connection was never inside it, whatever the credential says.

Six limits in total: what, how much, what for, where, when, on what. A real grant carries all six whether or not anybody wrote them down. The board that signed the invented resolution above would recognize every one of those limits as part of what they meant, including the ones the resolution never spelled out. The limits aren't an addition to the grant. They are the grant. What the system currently uses is a one-bit shadow of it.

Why a shadow

It was never asked to use more. Authentication wants to know who you are. Authorization wants to know whether this role may call this function. Both of those have a standard encoding, both travel between systems, and both can be checked in microseconds. A role is a word and a scope is a list, and the whole of modern access control is built on how cheap that makes the check.

Time, jurisdiction, location, purpose and amount don't have a standard encoding. Every system that has tried to carry them has invented its own private language for doing so: a custom claim here, a policy attribute there, a transaction limit in a different product's admin console. None of it travels. A grant encoded in one bank's policy engine means nothing to the counterparty's, so the counterparty asks for a letter, and the letter is prose, and we're back to a lawyer reading it.

So today the six limits live in two places. The full set lives in language, in the mandate or the resolution or the employment agreement, readable by a person. A fragment of it lives in the system, as whatever the system had a field for, configured by somebody working from a summary. The request is checked against the fragment. The full set is consulted later, by argument, when something has gone wrong.

What the limits buy, and what they don't

So what changes when a grant carries its limits in a form a machine reads? It's less than people expect and also more.

The answer to a request is still yes or no. Nobody's proposing that a system return a legal opinion. What changes is how the answer is arrived at and what it carries with it. Today a request is judged: a person configured a rule, and the rule either fires or doesn't, and if you want to know why, you ask the person. With the limits in the grant, a request is measured. Two million, Q3 invoices, Delaware, the treasury desk, before December, from a controlled system. A request for one point five million to a Q3 supplier from the desk in November is inside all six. A request for the same amount to the same supplier in January is outside one. Nobody judged it. It was measured, and the answer arrives carrying the limits it was measured against.

A yes that carries its limits is a yes that can be shown to a counterparty, an auditor or a court without reconstruction. It says: this act was inside this grant, on these six dimensions, at the moment it happened. The reconciliation that today happens in discovery, years later, happens at the act, because the act was never separated from the grant that permitted it.

At Conduit, the way we build it, a grant carries all six limits in a form a lawyer reads as the agreement and a machine reads as the permission, and every request is measured against them at the moment of the act. Getting a grant into that form isn't a small job. Writing legal limits so precisely that a machine reads them the way a lawyer does is the part of this whole problem I think is most underestimated. The six limits are the easy half of it to explain. The hard half is doing it faithfully, so that the computable grant means what the signed one means and not something narrower or wider.

The limits say how far. They cannot say where from.

Despite how well we design the grant grammar, a grant that says how far it goes is still only a claim. Two million, Q3, Delaware, December, from a controlled system. Says who? A grant with six beautifully specified limits, issued by someone who had no right to issue it, is worth exactly nothing, and a system that measures requests against it is measuring against a forgery.

So the six limits answer the first question a grant has to answer, how far it goes. They can't answer the second, where it came from. That one needs a chain of delegation, and that chain is where the leaver in March finally gets a clean answer.

For now, the test is simpler:

1. Pick any standing permission in your organization: a role, a signing limit, a delegated approval.
2. Write down the six limits the person who granted it would say it carries.
3. Count how many of them the system actually holds.

My bet is one, maybe two. The grant has six.