Why AI agents need clear authority before workflows scale

AI governance changes when AI can act

An AI agent that drafts a customer message creates an output to review. An agent that sends that message, changes a campaign, triggers a workflow, or accesses an enterprise system raises a question of authority. Leaders need to know what the agent may do, which systems and data it may touch, where a person must intervene, and who owns the outcome. These questions become part of the business process when software can act with limited human intervention.

Accuracy, hallucination controls, and output review still matter because they determine whether an AI system produces trustworthy content. Autonomy creates a separate risk: an incorrect judgment can directly trigger an action that reaches a customer or changes a workflow before human review. For CMOs, CDOs (Chief Digital Officers), and customer-experience leaders, governance becomes part of operating design. The scope of delegated decision-making must be clear before autonomous workflows scale.

The preparedness gap is already visible

Research from AI governance platform Optro suggests a gap between confidence and dedicated safeguards. Optro reports that 58% of business leaders believe their governance controls are evolving alongside AI adoption, while only 18% report having dedicated AI risk safeguards in place. The two figures differ by 40 percentage points. Because Optro sells AI governance technology, it has a commercial interest in the need for stronger governance.

Optro also reports that one in three organisations are already using AI in critical resilience workflows, while 30% have never tested for potential agentic AI failure. This raises a practical question: whether controls have been tested where AI is involved in critical work. Optro reports broader AI problems as well, although these findings do not establish that autonomous agents caused the events or exceeded their permitted authority.

The distinction changes the control response. Misleading outputs call for accuracy controls and review. Data breaches call for information-security controls, while regulatory scrutiny calls for legal and compliance oversight. Authority-based controls address a different capability: software that can execute actions after reaching a conclusion.

Governance must define delegated authority

Traditional approval processes place consequential decisions with people. Agentic AI changes that chain when a system can move from recommending an action to triggering a workflow or interacting with a customer with limited human intervention. Reviewing generated content then covers only part of the process. Leaders also need to define which actions the system may execute.

Guru Sethupathy, GM of AI Governance at Optro, describes autonomous systems as requiring a different governance model. “The reality today is that agentic AI adoption is fast outpacing governance. To harness its potential responsibly, leaders must recognise that governance models designed for static manual processes cannot keep pace with autonomous systems of action.” Optro benefits commercially when organisations invest in AI governance, so Sethupathy’s statement is a vendor position rather than independent evidence about the prevalence of governance failures.

Sethupathy’s phrase “systems of action” captures the change. When AI generates a campaign recommendation for a marketer to assess, the marketer decides whether to act. When an agent can execute campaign activity or communicate with customers, software receives some decision-making authority. Governance must specify the scope and conditions of that delegation.

Mark Taylor, Director of Information Security Risk Management at Newell Brands, frames the issue around behavior and access. “The teams that get agentic compliance right will build governance and accountability frameworks for how an agent behaves and what it’s able to touch. Establishing that structure proactively positions organisations to scale AI safely, prevent future incidents, and execute with either humans in the loop or on the loop where appropriate.” His emphasis on what an agent can “touch” gives leaders a concrete way to examine permissions.

Four dimensions make that authority explicit. Permitted authority covers the decisions and actions an agent may execute without further approval. Its access and action boundary covers the data, systems, channels, workflows, and changes available through its intended permissions. Together, these choices define which business actions the organisation deliberately exposes to autonomous execution.

Human intervention is the third dimension. A human “in the loop” participates in the decision process. A human “on the loop” supervises a system that can operate and intervenes under defined circumstances. Executives need to choose between these models based on the consequences of an action and the discretion delegated to the agent, then define what triggers escalation.

Accountability is the fourth dimension. When software selects or executes an action, the organisation still needs an owner for the business consequences. That owner needs authority to change the workflow, restrict permissions, or stop operation when controls prove inadequate. For a customer-facing agent, this means specifying which customers it may contact, which information it may use, which communications it may send autonomously, and which conditions force escalation.

Bounded autonomy makes the trade-off explicit

Requiring human approval for every consequential action sharply limits delegated authority. Bounded autonomy offers a different design: an agent operates independently within defined permissions and escalates when predefined conditions occur. A marketing agent, for example, could access approved data and specified customer channels while remaining limited to defined actions. Higher-risk actions could require human intervention based on their consequences.

This design forces leaders to decide which activities they are prepared to delegate. They must define the agent’s permissions, escalation conditions, and the human owner for decisions outside those boundaries. They must also choose where a person participates directly in a decision and where supervision is sufficient. Those choices establish how much autonomy the system actually has.

The trade-off is concrete. Broader permissions expose more actions to autonomous execution, while tighter permissions send more situations to escalation or prevent the agent from acting. Governance makes that choice explicit before deployment. Business owners can then see whether the intended permissions and discretion match what they approved.

Agent governance is an operating-model problem

An agentic workflow can cross boundaries that organisations often assign to separate functions. A customer workflow may combine marketing objectives, customer experience, IT systems, security controls, legal obligations, and risk decisions in one chain of actions. Each function has a distinct question to answer about the authority being delegated. Governance must connect those decisions into rules that apply to the agent’s behavior.

Marketing and customer-experience leaders can define the intended customer outcome and the actions they are prepared to delegate. IT and security can define permitted systems, identities, and data access. Legal and risk teams can set constraints where obligations or consequences require escalation. This division of work turns a broad demand for “AI governance” into specific decision rights.

Cross-functional participation still requires clear accountability. A committee that reviews a workflow does not by itself determine who can approve deployment, change permissions, set intervention thresholds, or halt operation. Those decision rights need named owners. Otherwise, several functions can participate while responsibility for the agent’s conduct remains unclear.

Agent governance therefore reaches beyond compliance processes and technical permission systems. Security controls can enforce defined access, while compliance processes can assess defined obligations. Executives still have to decide how much business authority the organisation will delegate to software and under which conditions. That operating decision determines what the technical and compliance controls must enforce.

Key takeaways for leaders

• Govern actions: As AI agents move from generating content to executing actions, leaders need controls for what agents may do, which systems they may access, and when people must intervene.
• Test governance against actual AI risk: Reported gaps between AI adoption and dedicated safeguards suggest leaders should verify that controls work in critical workflows rather than relying on governance confidence alone.
• Define delegated authority before deployment: Set explicit limits for agent permissions, access, human intervention, escalation, and accountability. Every autonomous workflow should also have a named owner who can restrict or stop it.
• Use bounded autonomy to manage risk: Give agents independence only within defined permissions and require escalation for higher-risk actions. Broader autonomy should reflect an explicit business decision about acceptable consequences.
• Treat agent governance as an operating-model decision: Marketing, CX, IT, security, legal, and risk teams may all shape agent controls, but decision rights must remain clear. Executives ultimately determine how much business authority software receives.