VentureBeat recently published research on enterprise agent reliability that should get the attention of anyone deploying autonomous AI. In its survey, 49% of organizations said they had deployed an AI agent or LLM feature that passed internal evaluations and still caused a customer-facing failure. Nearly a quarter said it had happened more than once.
What makes that finding more interesting is what happened next. These companies did not retreat from autonomy. In fact, many are moving faster toward it. VentureBeat found that 67% of organizations either already allow some zero-human-in-the-loop deployment or are engineering toward it within the next year. Among organizations that had already been burned by an agent that passed evaluation and then failed in production, that number was even higher.
That tells us something important about where enterprise AI is heading. Humans are not going to remain in the approval path for every meaningful AI action. The economic value of autonomous systems is too large, and the volume of actions will eventually make constant human review impossible.
The question is not whether enterprises will remove humans from routine execution. They will.
The real question is what replaces the control those humans used to provide.
This is where I think the industry is still mixing together several very different problems.
Evaluations matter. Security matters. Authentication matters. Permissions matter. Observability matters. None of those should be minimized. Enterprises need to know whether an agent is capable of doing its job, whether its identity is legitimate, whether its credentials are valid, whether its behavior is secure and whether operators can reconstruct what happened afterward.
But none of those questions is the same as this one:
Was the agent actually authorized by the enterprise to perform this specific action?
That distinction becomes critical once AI stops merely generating recommendations and starts producing real-world effects.
Imagine an autonomous coding agent working inside GitHub. It authenticates correctly. It has valid credentials. It has repository access. It passes its coding evaluations. Its proposed code is technically sound. Every automated test succeeds.
Now suppose its mandate was narrower than its technical permissions. Perhaps it was authorized to work only in one repository, on one development branch, creating new files and opening a pull request. During execution, however, the agent decides that the most efficient solution is to modify a production configuration file on the main branch.
Nothing necessarily failed technically. The authentication worked. GitHub correctly recognized the identity. The credentials were valid. The model may have reasoned perfectly. The code may be completely correct.
The problem is simply that the enterprise never authorized that action.
That is a very different failure.
At Authrizd, we have been working from a principle that I think will become increasingly important as agentic systems mature:
Authentication can be completely correct while authority is completely wrong.
The same principle applies to evaluation.
An agent can pass every evaluation and still lack authority for the action it is about to take.
Evaluations answer questions such as: Can the agent perform the task? Does it behave reliably under these test conditions? Is the output likely to be correct?
Authority answers a different question: Has the enterprise actually authorized this agent to perform this action, against this resource, for this purpose, under these constraints, at this moment?
Those are not interchangeable.
This problem becomes much harder as agents get better, not easier. A weak agent that constantly fails may never get trusted with consequential work. A highly capable agent that reliably completes complex plans will.
And that means a very capable agent can become extremely effective at doing something the enterprise never intended it to do.
This is also why traditional permissioning does not completely solve the problem. Permissions define what an identity can technically access. Authority should define what that identity has actually been empowered to do under the current mandate.
Those boundaries may be very different.
An agent might technically have access to dozens of repositories, several cloud services, customer records and financial systems because those permissions are necessary for its role. But the enterprise may only have authorized that agent to use a small subset of those capabilities for one objective.
Permission creates capability. Authority constrains the legitimate use of that capability.
That gap becomes even more complicated when autonomous systems start creating their own plans.
Suppose an agent receives the objective: “Resolve this customer issue.”
The agent breaks that objective into 14 steps. Thirteen of them are routine. The fourteenth issues a $25,000 credit.
Was that financial action implicitly authorized by the original objective?
Maybe it was. Maybe it wasn't.
But the fact that the agent arrived at that action as part of a rational plan cannot itself create authority.
The same applies to software and infrastructure. An agent told to “fix the production problem” may conclude that the fastest solution requires changing a security policy, accessing a credential store, modifying infrastructure or disabling a control. The objective may be legitimate, while one of the steps used to achieve it is not.
A legitimate objective cannot become a blank check.
This is where plan decomposition becomes an authority problem. Authority needs to survive the transition from a high-level objective into the lower-level actions an autonomous system chooses for itself. It should not silently expand just because the agent discovered a more powerful or convenient path.
The issue becomes even more important in multi-agent systems.
Agent A receives a mandate and delegates part of the work to Agent B. Agent B invokes Agent C. Agent C uses an MCP server. That server exposes a tool that changes something in a production system.
At the end of that chain, what actually authorized the effect?
The fact that Agent C had a token is not enough. The fact that the MCP server exposed the tool is not enough. The fact that Agent A originally received a valid objective is not enough.
There needs to be a continuous chain of authority from the original principal through the mandate, delegation, agent, tool and proposed effect.
That is one of the problems Authrizd is being built to solve.
Our premise is that the enterprise must remain the source of authority for the AI acting on its behalf. The model should not become the source of its own authority simply because it is capable. Neither should the agent framework, orchestration platform, application or tool.
Those systems should continue providing their native security, authentication, permissions, execution controls and policy systems. They are necessary and valuable.
But the enterprise still needs an independent authority layer that can carry the enterprise's mandate across all of them.
This week, Boston Consulting Group published a piece titled “The Authorization Gap: Why Yesterday’s Controls Won’t Work with Today’s Agents.” Their argument is closely related. BCG points out that traditional authorization systems were designed primarily for humans and deterministic software, while agents can interpret objectives, build plans, select tools, change approaches and delegate work.
Their conclusion is especially important: authorization increasingly has to govern not only the goal, but also the path used to achieve the goal.
That is exactly where this problem is heading.
As enterprises deploy more autonomous agents, authorization can no longer be treated only as a login-time or application-level decision. It has to become something that can be evaluated during execution, at the point where an agent is about to create an effect.
That does not mean putting a human approval box in front of every action. That would defeat much of the purpose of autonomous AI.
Instead, people define the authority and machines enforce it.
An enterprise might authorize an agent to operate within a specific repository, for a specific task, for a limited period, using designated tools, under defined financial or operational thresholds. Routine actions that remain within that authority can execute automatically. Actions that cross a boundary can be denied or escalated for additional approval.
That is how you remove humans from routine execution without removing human and institutional authority from the system.
Evaluations should also become part of this architecture, but they should be treated as evidence rather than as the source of authority.
An authority decision might consider model identity, evaluation results, security posture, historical behavior, risk classification, resource scope, time limits, delegated authority and the particular effect being proposed.
That makes sense.
What does not make sense is the assumption:
Eval passed, therefore execute.
A successful evaluation should never manufacture authority that the enterprise did not grant.
The VentureBeat research matters because it shows that enterprises are discovering the limits of evaluation at the same time they are moving rapidly toward greater autonomy. The BCG article matters because authorization itself is now becoming an explicit architectural topic in enterprise AI.
Put those trends together and the direction becomes fairly clear.
We are moving into an environment where enormous numbers of AI actions will happen without a human reviewing each one. Those actions will cross applications, platforms, agents and tools. Some will be initiated by humans. Others will emerge from plans created by the agents themselves.
The enterprise needs a way to answer a simple question at machine speed:
Is this particular effect actually authorized?
That question is different from whether the AI is capable of doing it, whether the credentials are valid, whether the platform permits it or whether the agent passed its evaluation.
And as autonomous systems become more capable, the distinction becomes more important.
The biggest risk may not be an incompetent AI agent that fails to complete its task.
It may be a highly competent agent that performs an unauthorized task perfectly.
That is the authority gap.
And it is the problem we are building Authrizd to address.
Enterprise Authority over AI.
Authrizd determines whether AI is authorized to act — before it acts.
VentureBeat research:
https://venturebeat.com/resources/agentic-reliability-and-evaluations-enterprises-that-got-burned-by-a-bad-eval-are-the-most-likely-to-remove-humans-from-the-loop-not-the-least
BCG — The Authorization Gap:
https://www.bcg.com/publications/2026/authorization-gap-ai-agent-governance
Authrizd:
https://authrizd.ai
#Authrizd #AgenticAI #AIAgents #AIGovernance #AISecurity #EnterpriseAI #AIAuthorization #AutonomousAgents #Cybersecurity #AIInfrastructure
NEXT STEP