Who Actually Authorized That?

Your system can probably tell you exactly who approved a payment. It knows when they did it, which account they used, and which permission allowed the transaction. If you've invested in good security and audit tools, you may even have a beautiful report to show for it.

Now ask one more question: Who gave that person the legal authority to approve it?

That's where things get interesting.

I'm not knocking authentication or access control. They're essential, and we've spent decades getting better at them. But knowing who someone is and knowing what a system lets them do doesn't necessarily tell us whether they had the legal right to do it.

Those are three different questions. Most enterprise systems are pretty good at answering the first two. The third is where we still rely heavily on contracts, lawyers, and people piecing together what happened after the fact.

Let's follow a payment

Imagine a company where the board has authorized the CFO to approve certain vendor payments up to $1 million. The CFO gives a regional director authority to approve up to $100,000, including the right to delegate some of that authority. The director gives a manager permission to approve up to $10,000.

The manager approves an $8,000 invoice.

The accounting system checks the manager's identity, sees an approval limit of $10,000, and processes the payment. Everything looks fine.

But what if the CFO's original authority covered only a particular class of vendors? What if the regional director's delegation applied only to California, and this payment was for an office in New York? What if the director's authority expired last month? What if the CFO never gave the director the right to delegate at all?

The manager's role in the accounting system won't necessarily answer any of those questions. That role may say the manager can approve $10,000. It doesn't tell us whether the people who granted that permission were entitled to do so.

In the previous article on the six limits of authority, I explained that a grant needs to define what someone can do, how much, for what purpose, where, when, and with what assets or resources. Those limits let us test a particular request against the authority granted.

There's another part to this problem, though. We also have to establish where the grant came from.

You can't give away authority you don't have

This should be obvious. If I can approve a $10,000 payment, I can't give you permission to approve $100,000. And if I don't have permission to delegate my authority in the first place, I can't create a new grant just because a software interface gives me an Add User button.

Lawyers understand this. Corporate officers and boards understand it. Yet most of our software has no idea whether the person assigning a permission actually holds the underlying authority.

We typically manage access through roles and policies. Someone decides that a department manager can approve invoices up to $10,000, adds that rule to the system, and moves on. The software evaluates future requests against that rule.

There isn't anything inherently wrong with roles. They're useful. The problem starts when we treat the role as the source of authority instead of a way to express it.

Think back to the payment example. There should be a way to start with the $8,000 approval and work backward:

1. The manager approved the invoice under a specific delegation.
2. The regional director issued that delegation, within the authority the CFO gave them.
3. The CFO received authority through a board resolution or another valid corporate instrument.
4. The board or other governing authority had the legal power to establish that approval structure.

Every step needs to be valid. Each new delegation has to fit within the limits of the one before it, including whether further delegation is allowed.

That's the chain of delegation. It isn't a blockchain, and it isn't just an org chart. It's the actual trail of legal authority from the action back to the people or governing body entitled to authorize it.

If one link doesn't hold up, the software shouldn't treat the rest of the chain as valid just because the manager still has the right role assigned.

Permissions have a nasty habit of outliving their authority

Here's a practical problem anyone who has managed enterprise software will recognize.

People change jobs. Contracts expire. A board changes an officer's mandate. A company revokes a delegation. Meanwhile, the permissions granted months or years earlier are still sitting in an access-control system.

In theory, somebody updates those permissions when something changes. In practice, we're counting on the right person knowing which systems to update, having access to them, and remembering to do it.

That's not a great foundation for legal authority.

I'd rather have the underlying grants be the source of truth. When someone requests an action, the system should be able to establish that a grant covers the request and that the chain behind it is still valid. If the CFO's authority has been revoked, every dependent delegation should stop being usable without someone having to hunt through a dozen applications for stale permissions.

That doesn't mean we have to throw out role-based access control or make every application read a stack of legal documents for every API request. Roles, indexes, and caches can still make the system efficient. They just can't be allowed to turn an expired grant into an active permission. If we cache authority, we have to account for amendments, expiration, and revocation too.

For me, this is the important distinction: A role describes what the software will let you do. A valid grant establishes why you have the authority to do it.

Check the delegation before it's used

There are two points where a system needs to make that distinction.

The first is when someone delegates authority. Before the system accepts a new grant, it should verify that the person issuing it holds the rights they're trying to pass on, that they have permission to delegate those rights, and that the new grant stays within the original limits.

In our example, the regional director shouldn't be able to assign a manager a $250,000 payment limit if the director's own limit is $100,000. The system should reject the delegation when the director tries to create it. We shouldn't have to wait for the manager to attempt an oversized payment to discover the problem.

The second check happens when someone actually takes an action. For the $8,000 payment, the system needs to confirm that the amount, purpose, location, timing, and other conditions fit the manager's grant, and that every grant above it remains valid.

If the system can't establish both, the answer is no, or at least not without further review.

This reverses an assumption that's common in software. We often ask whether a policy prohibits an action. Here, we ask whether valid authority positively permits it.

That's a big difference.

Yes, this is a hard engineering problem

I can already hear the developers asking how we're going to evaluate a chain of grants for a high-volume transaction system. It's a fair question. I would ask the same thing.

Validating a chain will require more work than reading a permission from a role table. We have options for structuring grants, indexing relationships, verifying signatures, and managing cached results. But the implementation has to preserve the legal meaning of the grants, especially when something changes.

There's a harder challenge too. Contracts aren't written for computers. They contain exceptions, ambiguous language, references to other agreements, and terms that can mean different things under different laws. We can't pretend that turning those documents into computable rules is a trivial exercise. Some questions will still require legal interpretation and human judgment.

None of that changes the problem we're trying to solve. It just means we need the lawyers and the engineers working on the same model of authority, with clear boundaries for what the software can verify and what it cannot.

At Conduit, that's the direction we're working toward. We want an authorization decision to carry its supporting evidence: the grant that covered the action, the delegations behind it, and the legal instruments that gave those delegations their authority.

In other words, when a system says yes, it should also be able to explain why.

Try this in your own organization

Pick one important permission. It could be an employee approving payments, a procurement manager signing contracts, or a service account executing transactions on behalf of a company.

Now try to trace that permission all the way back to the legal authority behind it.

Who granted it? What allowed that person to grant it? Did they have permission to delegate? Are all the relevant agreements still in force? Does the action fit within the conditions of each grant?

If you can answer those questions with a clear chain of evidence, great. If you need three departments, two lawyers, and a week of digging through email, you've just discovered the gap between your system's permissions and your organization's legal authority.

And consider when that gap usually gets noticed: during an audit, an investigation, or a lawsuit, when everyone is trying to reconstruct something that happened months or years earlier.

I'd much rather answer those questions when the transaction happens.

The system already knows who clicked Approve. I want it to know who gave them the right.