Back to Blog
authoritylegalauthorizationcompliancedispute-resolutionai-agentsseries-legal-authority

The Permission That Outlived the Grant

Someone leaves your company in March. Their legal right to act for it ends that day. Their access is still working in August. Those two things were meant to be one fact written down twice, and nothing in the modern stack was ever asked to check one copy against the other.

ByKen Anderson
Published
Read time7 min

Someone leaves in March. Their access is still working in August.

That's the whole problem, and you can check it inside your own company this afternoon. When the employment agreement terminates, the legal right to act for the company terminates with it: to approve an invoice, to sign a purchase order, to instruct a bank. In law, that right ended cleanly on their last day. There's nothing left of it.

Now go look at the systems. The account's still open. The role's still assigned. The shared drive still works. The approval workflow still lists them as a signer on the second tier, because nobody thought to remove them and nothing prompted anyone to. In plenty of companies it's still working in August, and in some it's still working the following March.

Most people file this under IT hygiene, a leaver process that needs tightening. I think that reading is wrong. The right to act and the ability to act were meant to be one fact, written down twice. Once in language, in an employment agreement or a mandate or a board resolution. Once in a system, as a role or a scope or an entitlement. Nothing checks either copy against the other. So they drift apart, quietly, and nobody finds out until somebody asks.

Two checks run on every request. Legal authority isn't either of them.

Why does nothing catch it? Because nothing was ever asked to. Almost every request in a modern system passes two checks.

The first is authentication. It establishes who you are: a password, a key, a cryptographic signature, checked against something that already knows you. It answers that one question. The second is authorization. It establishes what this particular system will let you do: a role, or a scope of the kind you know from OAuth, configured by whoever set the system up and checked on every request.

Neither of them was asked whether anybody had the right to grant that permission in the first place, and whether they still do. Authorization checks a request against a rule. It doesn't check the rule against the agreement that was supposed to justify it, because the rule is a copy of that agreement, typed in by an administrator, and the system has no idea where the copy came from. When the agreement ends, the rule doesn't know. When the agreement is amended, the rule doesn't know. The rule only changes when a person changes it, and a person only changes it when something reminds them to.

That missing question has a name: Legal authority is the right to act, as granted by someone who held that right and could pass it on. Think of a building. Authentication is the badge reader: it knows who's at the door. Authorization is the access list: it knows which doors the badge opens. Legal authority is the question of whether anyone was entitled to put that name on the list at all.

It's not because a machine can't check it. It's because nothing made it cheap, and because writing a legal grant so that a machine reads it the way a lawyer reads it is genuinely hard. The two checks we have are the two that were easy to specify. The third is the one that was not.

The cost isn't paid continuously. It's paid all at once, later.

If this drift cost something every day, somebody would own it and it would get fixed. It doesn't. The leaver's open account costs nothing in April, nothing in May, nothing in June. The permission that's wider than its grant sits there doing no harm, until the day it does, or until the day somebody asks about it.

And somebody does ask. An auditor, a regulator, a counterparty in a dispute, a litigator working through a transaction that went wrong. The question is always the same one, in one form or another: who permitted this, and were they entitled to permit it?

Answering that question means discovery. Rebuilding the order of events out of email threads, signed documents, system logs and people's memory of what they believed at the time, and then proving that reconstruction to a court or a regulator. That takes months, often years, and it's done by the most expensive people in the building. One large payments company has recently produced more than six million documents to answer about two hundred questions about its own past conduct, and this is the same mechanism at a smaller scale, running inside every institution. The reconciliation between the legal grant and the system permission does happen. It just happens by hand, years late, in the most expensive room available.

So when I say the leaver in March isn't an IT hygiene problem, this is what I mean. The leaver is the visible instance of a structural fact: the thing that decides whether an act was permitted is a document, and the thing that decides whether the act goes through is a system, and the two were never bound together. Every stale role, every over-broad delegation, every approval that nobody can trace to a mandate, is the same gap. We notice the leaver because the date is clean. The rest of the drift has no date.

Why this stops being a governance topic

For most of the history of computing this was tolerable, because the acts in question were taken by people, at the speed of people, and the courtroom reconciliation was rare enough to absorb. That's changing, and it's changing in a way that makes the gap much harder to live with.

Software is beginning to act on delegated authority. An agent gets handed a credential and a mandate and told to go do something: pay the suppliers, rebalance the book, renew the contracts. Whatever the credential can do, the agent can do, at machine speed, in volume. Nothing anywhere wrote down what it was actually allowed to do, as opposed to what the credential happened to permit. The permission that outlived its grant is no longer one person's account sitting idle. It's a process executing thousands of times before anybody asks the question.

Tightening the leaver process isn't wasted effort. Do it. But notice what it is: a better schedule for manually copying one representation into the other. It makes the drift shorter. It doesn't touch the reason the drift exists, which is that the legal grant and the system permission are two objects, kept in step by people, and checked against each other only in a courtroom.

What closing the gap takes

The alternative is to stop keeping two. A grant that's written once, in a form a lawyer reads as the agreement and a machine reads as the permission, and a system that checks each act against that grant at the moment of the act rather than against a configured copy of it. When the grant ends, the permission ends with it, because the permission was never a separate thing. There's nothing left behind to go stale.

At Conduit, that's the way we build it. Legal authority isn't a policy applied to a transaction after the fact. It's a property the transaction either has or doesn't, checked at the moment of the act, with the grant it was checked against attached to the answer. That sentence hides two hard problems. The first is what a grant has to say for a request to be measured against it. The second is how you know where a grant came from, and whether the person who gave it was entitled to. Both are harder than they sound, and neither is new. Max Weber drew the distinction between power and legitimately held authority a century ago. What's new is the need to make it computable.

Until then, here's the test you can run this afternoon:

  1. Pick someone who left in March.
  2. Find out what they can still do.
  3. Ask who, in your organization, would have known.

(If the answer to the third question is "the person who left", you've found the gap.)

Nothing keeps the two copies in step. Nothing was ever asked to.