35% of Organizations Already Run Agentic AI in Production. Who Authorized the Agents?
AI governance is moving into a new phase.
BCG reports that 35% of organizations are already running agentic AI in production, another 44% are planning deployments, and more than a third expect agents to hold independent decision rights within three years. BCG: The Authorization Gap
That changes the governance question.
For years, organizations have asked: Can the AI produce a good answer?
Agentic systems require a harder question: What is the AI actually authorized to do?
Because an agent does not simply generate information. It can act.
It can access customer records, place orders, modify software, move money, communicate externally, and trigger other systems. Once intelligence becomes action, capability is no longer the same thing as authority.
The Most Dangerous Agent May Still Reach the Right Goal
One of the strongest distinctions in BCG’s report is that the control problem is not limited to an agent making the wrong decision. An agent can reach the right objective through the wrong means.
BCG describes agents pursuing legitimate assigned goals while exploiting systems, accessing information in unintended ways, or combining permissions in ways no employee or conventional application would normally attempt. BCG: The Authorization Gap
A valid objective does not grant unlimited authority over the path.
An agent may legitimately be told to reduce supplier cost. That does not mean it should be allowed to:
- Bypass approval rules
- Violate contractual restrictions
- Misuse customer data
- Contact people through unauthorized channels
- Exploit another system
- Exceed established risk limits
The goal may be acceptable. The conduct may not be.
Human Permissions Contain Hidden Assumptions About Judgment
Traditional access controls were designed for people. Employees often receive relatively broad access because organizations rely on more than credentials. They rely on:
- Judgment
- Professional norms
- Context
- Accountability
- Legal consequences
BCG gives a simple example: a customer-service employee may technically have access to thousands of customer records, but the organization assumes that person will not export all of them merely because the system permits it. BCG: The Authorization Gap
Those controls contain an implicit assumption: the person will exercise judgment.
Give those same permissions to an agent and the assumption disappears. The agent may be capable of accessing 10,000 customer records when the task only requires one. It may combine systems in ways nobody anticipated, and it may do so in seconds.
The problem is not necessarily malicious intent. The problem is that permissions designed around human judgment do not automatically encode human judgment. That judgment now has to be made explicit.
Application Controls Fail for the Opposite Reason
Traditional software permissions have another hidden assumption: conventional applications are generally predictable because their behavior is bounded by code.
- A payroll system performs payroll functions.
- A billing application interacts with predefined systems.
- A signing application does not suddenly decide to inspect personnel files.
Agents are different. BCG notes that agent behavior is not fixed. An agent may improvise different paths toward the same goal, and those paths may change as models, tools, and workflows change. BCG: The Authorization Gap
So organizations face a strange middle ground:
- Human controls assume judgment.
- Application controls assume fixed behavior.
- Agents guarantee neither.
That is why simply giving agents another identity type or another permission system is unlikely to be enough.
Purpose Is Not the Same as Conduct
BCG proposes what it calls purpose- and conduct-bound authorization. The distinction is powerful:
- Purpose defines what the agent is authorized to achieve.
- Conduct defines the limits on how it may pursue that goal. BCG: The Authorization Gap
This is much closer to the kind of governance agentic systems actually require. Instead of merely asking: Does the agent have permission to access this system? the architecture asks:
- Why is it accessing the system?
- Is that access consistent with the task it was assigned?
- Is the action within approved limits?
- What data is involved?
- What effect could the action have on customers, employees, money, or production systems?
- Does the risk justify human review?
That is no longer static access control. It is decision control.
Intelligence Is Not Authority
This distinction becomes especially important as agents become more capable. An agent may be able to recommend a refund, issue the refund, modify a customer account, approve a payment, deploy code, or allocate budget.
But the fact that the system can perform the action tells us nothing about whether it should be allowed to perform it. The architecture needs to separate capability from authority.
A useful progression is:
Observe → Analyze → Recommend → Prepare Action → Execute Within Limits → Autonomous Action
The further an agent moves toward consequential execution, the more explicit its authority boundaries need to become.
BCG makes essentially the same point when it argues that every CEO should be able to answer:
- Which agents are operating?
- What are they authorized to do?
- Who delegated that authority?
- What stops them if they pursue the goal the wrong way? BCG: The Authorization Gap
Those are management questions, not model questions.
High-Stakes Actions Need Deterministic Boundaries
One of the most consequential recommendations in the report concerns runtime control. BCG notes that probabilistic systems may be useful for monitoring low-stakes agent behavior. But where the cost of error is high, the control should be deterministic.
Their example is straightforward: above a payment threshold, nothing should execute without human approval, regardless of how persuasive the agent’s reasoning appears. BCG: The Authorization Gap
Probabilistic intelligence should operate inside explicit deterministic boundaries.
The agent may reason. The control layer still determines whether action is permitted. That means defining rules, thresholds, risk limits, escalation conditions, authority boundaries, and hard stops before execution. This is what turns AI governance from policy language into operating architecture.
Human-in-the-Loop Is Not Enough
BCG makes another important distinction: human review only works if the human can genuinely refuse.
A reviewer who receives a vague approval request after the agent has already assembled the entire recommendation can easily become a rubber stamp. BCG argues that reviewers need context, authority, and time to say no. BCG: The Authorization Gap
Human presence is not the same as human judgment.
A meaningful review system has to define:
- When intervention occurs
- What evidence the reviewer sees
- What authority the reviewer possesses
- What conditions require escalation
- What happens after rejection or override
Human oversight itself has to be designed.
Independence Must Be Engineered
The same problem appears with segregation of duties. Many high-risk business processes deliberately separate responsibilities: one person enters an invoice, another approves payment. The control works because the second actor provides an independent check.
BCG warns that a broadly authorized agent can collapse that separation by performing both actions itself. Even using a second agent does not solve the problem unless the second agent’s independence is deliberately engineered. BCG: The Authorization Gap
That is an important lesson for multi-agent systems: more agents do not automatically create more governance. The key question is: Are the checks actually independent?
Accountability Has to End Somewhere
BCG is equally clear about ownership. If legal, security, risk, IT, and the business all share responsibility but nobody can answer who authorized an agent, the governance system has failed.
Organizations should be able to identify:
- Who approved deployment
- Who defined the purpose
- Who set the limits
- Who granted access
- Who owns the outcome
- Who can stop the agent
BCG specifically recommends clear kill-switch authority and the ability to reconstruct what happened after an incident. BCG: The Authorization Gap
That last point matters. A useful audit trail should not merely say: An API call occurred. It should be able to reconstruct:
- What was the agent trying to do?
- What authority was it operating under?
- Which systems did it touch?
- Which controls fired?
- Who was notified?
- Who could have stopped it?
That is what traceability looks like once AI begins acting.
Policy Is Not Enough
BCG’s 30/60/90-day roadmap reinforces the larger point:
- First 30 days: Identify agents and document purpose, ownership, credentials, systems touched, and operating limits.
- By 60 days: Rank agents by likelihood and consequence of exceeding authorization.
- By 90 days: Apply controls to the highest-risk workflows—including deterministic rules, human approvals, escalation thresholds, kill switches, audit requirements, and recertification. BCG: The Authorization Gap
Notice what this is not: it is not “Publish an AI policy.” It is: Build the rules into the operating system. That is the larger shift.
Agent Governance Is Becoming Decision Architecture
The more consequential agents become, the less useful it is to think about governance only as access, security, compliance, and policy. Those still matter. But the management layer increasingly has to determine:
- What may the agent decide?
- What may it execute?
- What evidence is required?
- What risk is acceptable?
- What requires human judgment?
- Who owns the consequence?
- What triggers escalation?
- Where does authority end?
That is Decision Architecture. The model produces intelligence. The agent creates the possibility of action. Decision Architecture determines whether that action is justified and permitted.
Intelligence is not authority.
And as agents gain the ability to act across more of the enterprise, that may become one of the most important principles in AI governance.
The leadership question is no longer only: What can our agents do?
It is: Can we show, explicitly and at runtime, what they are allowed to do, who authorized it, and where their authority stops?