Every company has a governance structure it can describe. There is an org chart, a delegation of authority policy somewhere in a shared drive, a list of matters reserved for the board, and a general understanding of who is trusted with what.

Every company also has a second governance structure, which is what its systems will actually permit. Who can approve a purchase order above a certain value. Who can post a journal entry. Who can waive a fee, override a rate, add a vendor, create a general ledger account, release a payment, or approve a lease concession. This second structure is not a description of authority. It is authority, because it is the version that executes.

When the two disagree, the system wins. The written policy is a statement of intent. The configuration is what happens. And in most organizations, the configuration was set during implementation, by people optimizing for going live on schedule, based on an org chart that has since changed, and has not been reviewed as governance by anyone since.

Decision rights are taken seriously, in the abstract

There is a substantial body of management thinking about who gets to decide what, and it treats the question as consequential. Bain's RAPID framework, popularized in the 2006 Harvard Business Review article by Paul Rogers and Marcia Blenko, exists precisely because ambiguity about decision rights stalls organizations, produces rework, and generates conflict. The framework's central discipline is insisting on a single decider and making veto rights explicit rather than leaving them implied.

That thinking is applied, when it is applied at all, to strategic decisions discussed in rooms. It is almost never applied to the thousands of operational decision rights encoded in system configuration, even though those govern far more decisions per week than any governance forum does, and even though they are the ones with actual enforcement behind them.

A delegation of authority policy that says regional managers may commit up to a certain amount is a claim. The approval threshold in the system is the operative rule. One of those two documents is read at board level. The other is the one that determines what happens on Tuesday.

How that document got written

It is worth reconstructing the authorship, because it explains a great deal.

Most approval thresholds and permission structures were set during an implementation, in a configuration workshop, under time pressure. Someone asked what the approval limit should be. Whoever was in the room gave a number, often derived from what the old system did, or from a reasonable guess about the current team. The consultant recorded it and moved on, because there were forty more decisions to get through and a go-live date. The objective in that room was a working system, which is a legitimate objective and not the same as a governance objective.

Nobody in that workshop was asking the questions a governance review would ask. What level of commitment should require a second signature, and why that level. Which roles should be able to modify a master record. Where should segregation of duties be enforced rather than assumed. What should be impossible for anyone below a certain level, regardless of convenience.

And then the document was finished. Not reviewed, not approved as policy, and in most organizations not owned by anyone. Your written delegation of authority probably gets revisited when the business changes. Its operative twin, which actually controls the money, typically does not.

Two failure modes, one of them silent

Configuration drifts out of alignment in both directions, and the two are not equally visible.

Too tight is the loud failure. Thresholds set for a smaller, simpler company mean routine items escalate to people whose time is worth far more than the decision. Senior staff spend hours approving purchases they have no basis to evaluate and no intention of refusing. Everyone complains about it, which at least means someone knows it is happening.

The deeper cost is that the approvals stop being real. When a threshold generates a hundred approvals a week, the approver becomes a rubber stamp, and the control that existed on paper stops existing in practice while continuing to appear in the audit trail. This is the same structural problem examined in who owns a decision an AI helped make: approval without the capacity or time to evaluate is not accountability, it is a signature.

Too loose is the silent failure. Someone has authority nobody intended to give them, usually through accumulation rather than any single decision. A permission granted for a one-off project stays. A person changes roles and gains the new role's access while keeping the old one. A temporary elevation during someone's leave is never reversed. None of this is visible until an incident makes it visible, and by then the question is not what the policy said but what the system allowed.

The asymmetry matters: excessive tightness is felt daily and eventually corrected, while excessive looseness produces no friction at all and therefore no signal.

The invisibility is the point

The aging of approval chains is a familiar problem, and it is part of a broader pattern of structures built for a smaller company quietly constraining a larger one, covered in the operating model outgrows the systems.

The argument here is narrower and about something else. It is not that these rules become outdated. It is that nobody is reading them, so they become outdated unobserved, and more importantly, they were never read as governance in the first place. An outdated policy is something an organization can notice. An outdated configuration nobody has ever looked at as a policy is not even in the category of things being tracked.

Ask most executives what their company's approval thresholds actually are, across all the categories where money can be committed, and very few could tell you. Ask who owns that set of rules and you will usually get a pause, followed by a suggestion that it might sit with IT, or finance systems, or whoever ran the implementation. That pause is the whole problem.

The AI extension arriving now

This becomes considerably more urgent as AI agents begin acting inside operational systems, because they are about to be granted entries in the same unreviewed document.

The questions are immediate and mostly unanswered. What is an agent permitted to approve on its own? At what value? Does it inherit the permissions of the person who deployed it, which is the default in many systems and almost certainly wrong as policy? Can it create records, modify master data, or release payments? Is there a threshold above which a human must intervene, and was that threshold set deliberately or copied from a human role?

Most organizations are going to answer these the same way they answered the original configuration questions: in a workshop, under time pressure, optimizing for the thing working. That approach produced a governance document nobody read when the actors were humans whose judgment could be relied on to catch obvious errors. It is a considerably worse approach when the actor is a system that will execute exactly what it is permitted to execute, at machine speed, without the instinct to pause on something that looks wrong.

The honest part: not every permission needs a review

It would be a mistake to turn this into a mandate to audit every setting, because that produces bureaucracy without much benefit and the vast majority of configuration is unremarkable and fine.

There is also a real argument for functional looseness. Systems configured too rigidly get bypassed. When the approval path is genuinely obstructive, people route around it, approving things by email, using a colleague's access, or splitting a commitment into pieces below the threshold. A control that reliably generates workarounds is worse than a looser control that people actually operate within, because at least the second one produces an accurate record. Tightening thresholds without considering whether the resulting process is workable tends to move activity into places the system cannot see.

So the goal is not maximal control. It is that the rules with real consequences should be deliberate rather than inherited, and that someone should own them.

Read the document you already have

The practical step is straightforward and rarely done. Export the actual approval matrix and permission structure from your systems, put it alongside your written delegation of authority, and compare them.

The specific test worth running: if you asked who in your company can commit fifty thousand dollars without a second signature, would the answer from the policy and the answer from the system be the same? In most organizations they are not, and the gap is usually larger than anyone expects.

From there the discipline is unglamorous. Assign an owner for the configuration as a governance artifact rather than as a technical setting. Put it on a review cadence, even an annual one. Make permissions granted for exceptions expire by default rather than persist by default, which addresses most accumulation without any audit. And before granting an AI agent authority in a system, write down what it may do and at what threshold, as a policy decision rather than a configuration detail.

None of this is difficult. It is simply that the most operative governance document in most companies has never been treated as a document, and that remains true right up until the moment someone has to explain how a thing was approved.

FAQs

Q1. What do you mean by the configuration being a governance document?
Approval thresholds, permission sets, and workflow routing determine who can commit money, change records, and release payments. That is a statement of delegated authority, enforced automatically. Unlike a written policy, which describes intent, the configuration is what actually executes, so when the two disagree the configuration governs.

Q2. Why does it matter who originally set these values?
Because the objective in a configuration workshop is a working system delivered on schedule, not a considered governance structure. Values are frequently carried over from a prior system or estimated by whoever was available, then never revisited. The result is a consequential rule set produced as a byproduct of a technical project rather than as policy.

Q3. What is the risk of thresholds being too tight?
Beyond the obvious cost of senior time spent on routine approvals, the deeper problem is that high approval volume turns reviewers into rubber stamps. The control continues to appear in the audit trail while no longer functioning as a control, which is arguably worse than not having it, since it creates documented assurance that nothing was actually checked.

Q4. Why is excessive looseness harder to catch?
Because it generates no friction. Nobody complains about having more access than they need, so the signal never surfaces. Permissions accumulate through role changes, one-off projects, and temporary elevations that are never reversed, and the gap between intended and actual authority stays invisible until an incident forces someone to look.

Q5. How is this different from approval chains simply becoming outdated?
Aging is a related but separate issue. The argument here is that these rules were never reviewed as governance to begin with and have no owner, so they are not merely out of date, they are outside the set of things anyone is tracking. An outdated policy can be noticed. A configuration nobody has ever read as policy cannot.

Q6. What does this mean for AI agents in our systems?
That agents are about to receive entries in the same unreviewed document. Whether an agent can approve, at what value, whether it inherits its deployer's permissions, and where a human must intervene are all governance decisions currently being made as configuration details. The stakes are higher than with human roles, because an agent executes exactly what it is permitted to execute without pausing at something that looks wrong.

Q7. Should we audit every permission in our systems?
No, and attempting it produces bureaucracy with little return. Most configuration is unremarkable. The discipline should concentrate on the rules with real consequences: monetary commitment thresholds, master data modification rights, payment release, and segregation of duties. Everything else can reasonably be left alone.

Q8. What is the single most useful thing to do first?
Export your actual approval matrix and permission structure, place it next to your written delegation of authority, and find the disagreements. A useful specific test is whether the policy and the system give the same answer to who can commit a given sum without a second signature. The gap is usually wider than expected, and finding it is most of the work.