A financial services company discovered the gap sideways. An agent running customer risk assessments flagged a high-risk account and the workflow automatically froze the customer's credit line. The agent had the right access. The decision was correct by the rules it was given. The postmortem found no permission violation.
But nobody had explicitly approved the agent to make that decision.
The access logs were clean. The permissions policy was tight. The agent executed exactly as designed. And somewhere between permission and execution, authorization disappeared.
This is not a visibility problem. This is not an access control problem. This is an authorization problem, and most teams conflate it with something else entirely.
Your agent's permission scope answers one question: what data can it reach?
Your agent's authorization answers a different question: who said it was allowed to decide?
You can lock down access perfectly and still have no answer to the second question. Teams do this constantly. They tighten the agent's data scope, assume that solves governance, and deploy. It does not.
An agent with perfectly scoped permissions can still take a consequential action without anyone having explicitly approved that class of decision beforehand. Not because access control failed. Because nobody designed for the authorization layer separately.
Permission governs what an agent can touch. Authorization governs what it is allowed to judge.
The mistake is treating authorization as a subcategory of permission. It is not. You need both. And they break independently.
When an agent takes a $2M decision and the postmortem starts, the first question is always: did it have access?
Yes. It did. The access logs prove it.
The second question is: who authorized it?
That question has no answer because authorization was never designed as a separate layer. It was assumed to be handled by access control. It was not.
Now the postmortem finds a gap with no blame assigned. The agent did what it was permitted to do. But nobody had explicitly authorized that class of decision. The workflow moved too fast. The authorization structure did not move with it.
The financial services company could not point to a human owner for the decision class. They could point to access permissions. They could not point to approval.
This happens because scaling agent counts outpaces the creation of decision rights. You deploy your first agent. Everyone knows what it does. You deploy your second. Still manageable. By your tenth agent across three teams, you have no unified way to know which human authorized which class of decision.
By your hundredth, the authorization layer is invisible and failing silently.
Before any agent that takes consequential action goes to production, do this: map every decision it can make and assign explicit authorization ownership.
What qualifies as consequential? Any action that changes state, costs money, flags a risk, or affects a customer. If you would need human approval to take that action today, your agent needs authorization assigned to it before deployment.
For each decision class, document three things:
The criteria the agent will evaluate. What conditions trigger this decision?
The threshold the agent will apply. At what point does it act?
The human owner who explicitly authorized the agent to decide when those conditions and thresholds are met. Not the person who built the agent. The person who said: "you may make this call."
Write it down. Make it visible. Version it. This document is not optional governance overhead. It is the record that proves accountability exists. Before the incident, not after.
The postmortem question "who authorized it?" should have a clear answer pointing to a specific person or team and a decision rights document. If it does not, you deployed without authorization mapping. That is a governance failure, not a permission failure.
At ten agents, you might remember the authorization implicitly. The team that built them knows what each one does. The decisions feel obvious.
At fifty agents across four teams, implicit knowledge breaks. At a hundred, it does not exist.
When agent counts pass the number of people who know every agent, authorization becomes the control that fails first. Not because teams are careless. Because they conflated authorization with permission and never built the authorization layer as a separate operational reality.
A telecom company running 100+ agents discovered this the hard way. They had permission scoping locked down. They had no unified authorization record. When an agent took an action that seemed wrong, the team could prove it had access. They could not prove anyone had approved that class of decision. The gap between "the access log is clean" and "who said this was allowed?" consumed a week of postmortem time.
That gap closes before deployment, or it opens in production. When it does, your post-mortem process won't find the answer because the authorization structure was never visible in the first place.
You assign authorization to a decision class. The person who authorized it leaves the company. The team that built the workflow gets reorganized. The agent gets updated to handle new criteria. The authorization document does not move with it.
Now an agent or a changed agent is executing under old authorization signatures. The decision rights look current but they are obsolete.
This is why authorization ownership cannot live in Slack history or in a one-off email thread. It has to live in your workflow governance structure. It moves with the agent through updates. It moves with the decision class through team changes.
If authorization ownership survives in a spreadsheet but not in your operations, you will find out in the next postmortem.
Permission and authorization are separate controls. You need both.
Permissions tell you what an agent can reach. Authorization tells you what it is allowed to decide. When an agent takes a consequential action and nobody can point to who approved that class of decision, you are looking at an authorization failure, not an access failure.
The permission scoping is tight. The access logs are clean. The authorization structure is missing.
This gets built before the incident or it gets diagnosed in the postmortem. There is no middle ground.
If you are running agents in production today and you have not mapped decision classes and assigned explicit human authorization to each one, that work is already overdue. Not because governance is fashionable. Because when something goes wrong, you need a clear answer to "who said it was allowed to do that?" If you do not have one, the blame loop is already open.
Acrein Group designs authorization into agentic workflows before they touch live work. Decision rights assignment, ownership continuity through team changes, and governance visibility that survives incidents. This is how the systems we operate across our portfolio avoid the authorization gap in the first place.
The right conversation at the right moment changes everything. Let's have it.
Talk to us