Who Authorized the Agent? Executive Accountability When Enterprise AI Can Act
AI agents can access data, call APIs, execute workflows, and act with limited human involvement. Learn how enterprises should govern agent authority and accountability.
Lewis Ho
Most companies are still early in their AI governance journey.
During the past year, enterprises have adopted AI assistants for drafting, summarizing, translation, research, coding, customer support, and internal knowledge management. In many cases, these tools produce information for employees to review. The employee remains the person who decides what happens next.
That arrangement is beginning to change.
Enterprises are now connecting AI systems to internal databases, business applications, workflow platforms, customer-service tools, payment systems, development environments, and external APIs. Some systems can retrieve information, select tools, execute multiple steps, update records, initiate workflows, and communicate with third parties.
The system may still be described as an “assistant.” Operationally, however, it may be acting more like a software agent with delegated authority.
That creates a new governance question.
It is no longer enough to ask whether the enterprise has approved an AI tool or classified its use case. Senior management must also ask:
Who authorized the agent to act, and what limits were placed on that authority?
This article follows LexGuard’s practical enterprise AI risk-tiering framework. The earlier framework explains how organizations can distinguish Limited Risk, Controlled Risk, High Risk, and Critical or Prohibited AI use cases. The next governance challenge is more specific: ensuring that an approved AI system does not receive more operational authority than the organization intended.
The First AI Settlement May Not Be About A Bad Answer
Imagine an employee asks an AI system to resolve a customer account issue. The agent searches internal records, checks a policy database, calls a billing API, changes the customer’s account status, initiates a refund, and sends an email confirming the outcome. However, the customer was not eligible for the refund.
The immediate question is whether the system made an error. The more significant question is how the system acquired the authority to perform each step.
Who approved the business purpose?
Who connected the agent to the billing system?
Who issued the credentials?
Who decided the agent could modify customer records?
Who determined that the employee’s review was meaningful?
Who could have stopped the process?
These questions move the discussion away from the prompt and toward the enterprise’s operating design.
The employee may have entered the final instruction, but the organization created the conditions that allowed the instruction to become a financial and operational action.
That is the central governance issue for autonomous AI:
Enterprise exposure is shaped not only by what an AI system is told to do, but by what the organization allows it to access, change, and execute.
From AI Output To AI Authority
There is a meaningful difference between four types of AI involvement:
The system generates information.
The system recommends an action.
The system prepares an action for human approval.
The system performs the action independently.
These categories can look similar from a user-interface perspective. They are very different from a governance perspective.
Many enterprise controls are designed around output quality. They ask whether the AI’s answer is accurate, useful, or compliant with a policy. For autonomous agents, that is only part of the problem. The enterprise must also evaluate the action path:
What information did the system retrieve?
Which tools did it use?
Which permissions did it exercise?
What decisions did it make along the way?
Which actions required approval?
Which actions were blocked?
Could the system have continued without the initiating employee?
Could it have produced a different result by taking another route?
An apparently reasonable final output does not prove that the process was properly authorized.
The Authority Stack
A useful way to examine an autonomous AI system is to analyze its authority stack. The authority stack consists of seven connected layers.
1. Objective
What has the organization asked the agent to accomplish?
Broad objectives create more room for interpretation than narrow tasks. “Resolve the customer’s issue” gives the agent considerably more discretion than “draft a response using the approved refund policy.”
The objective should be specific enough to identify what the system may and may not do.
2. Identity
Whose identity does the agent use?
An agent may operate through:
an employee’s account;
a shared service account;
a dedicated machine identity;
a vendor-managed credential; or
a combination of identities across connected systems.
Identity matters because it determines how actions are attributed and what permissions are inherited. Shared or poorly governed credentials can make it difficult to determine who authorized an action or which system component performed it.
3. Permissions
What can the agent access?
Read-only access, write access, deletion rights, administrative privileges, and the ability to create new credentials carry different levels of risk.
The agent’s permissions should reflect the approved purpose. If the system is designed to draft customer communications, it may not need the ability to alter billing records. If it is reviewing code, it may not need deployment access.
4. Tools
Which applications, connectors, APIs, code environments, and external services can the agent use?
Every tool expands the agent’s operational reach. A connector may introduce a new data source, a new set of permissions, a new vendor relationship, or a new route through which information can leave the enterprise.
Tools should therefore be approved as part of the use case, not added informally after the original review.
5. Execution environment
Where does the agent operate?
An isolated testing environment is different from a production system. A restricted sandbox is different from a general-purpose server with network access and stored credentials.
The execution environment determines how much damage an agent can cause if it behaves unexpectedly, misinterprets instructions, or encounters malicious or misleading content.
6. Human intervention
When must a person review, approve, challenge, or stop the agent?
A human review point is meaningful only if it occurs before an irreversible action and the reviewer has enough information, time, competence, and authority to make an independent decision.
The existence of an approval button does not, by itself, establish human control.
7. Evidence
Can the organization reconstruct what happened?
The enterprise should be able to identify the objective given to the agent, the data it accessed, the tools it called, the actions it attempted, the approvals it received, and the changes it made.
Without reliable evidence, the organization may be unable to determine whether the agent acted within scope or explain the incident to customers, regulators, insurers, auditors, or a court.
The authority stack provides a practical way to identify where risk is created. The earlier risk-tiering framework determines how much governance the use case requires. The authority stack helps determine whether the system’s actual capabilities are consistent with that decision.
Prompts Express Intent. Architecture Enforces Limits.
Organizations often begin AI governance with policies and instructions.
A system prompt may say:
do not disclose confidential information;
follow company policy;
do not access unauthorized systems;
request approval before taking consequential action; or
use only approved sources.
These instructions are useful. They establish intended behavior and may support user training, testing, and accountability. They are not, however, a substitute for technical restrictions.
A prompt does not remove excessive credentials. A policy does not block an outbound API call. A contract does not isolate a code-execution environment. A disclaimer does not prevent an agent from changing a production record.
This distinction can be summarized through three control layers.
Governance controls
Governance controls define the approved business purpose, ownership, risk tolerance, escalation process, and review requirements. They answer:
What is the system permitted to do?
Who owns the use case?
When is executive approval required?
Which actions are prohibited?
What triggers reassessment?
Legal controls
Legal controls allocate obligations and responsibility. They address:
privacy and confidentiality;
contractual commitments;
vendor responsibilities;
indemnities and warranties;
customer and employee disclosures;
incident notification;
regulatory obligations;
insurance;
and evidence preservation.
Legal controls are essential, but they generally determine what happens after a failure or who bears responsibility for it. They do not necessarily prevent the failure.
Technical controls
Technical controls constrain the system’s actual capability. They include:
least-privilege permissions;
network segmentation;
API allowlists;
isolated execution environments;
credential expiration;
secrets management;
data masking;
transaction limits;
logging;
anomaly detection;
rollback procedures;
and independent shutdown mechanisms.
The enterprise needs all three layers.
A policy defines the expected boundary. Technical architecture makes the boundary harder to cross. Legal documentation determines how obligations and consequences are handled when something goes wrong.
Legal Ops and Data Ops Solve Different Problems
The distinction between Legal Ops and Data Ops is particularly important for autonomous AI.
Legal and compliance teams should determine whether the organization is permitted to use the system for its intended purpose. They should assess the data, affected parties, jurisdictions, contractual commitments, regulatory obligations, vendor relationship, notification duties, and residual legal exposure.
Technology, security, infrastructure, and data teams should determine whether the system is technically constrained to that purpose. They should control its identity, permissions, tools, execution environment, network access, monitoring, and shutdown mechanisms.
The two functions are connected, but they are not interchangeable.
Legal Ops can answer:
“What risk is the enterprise willing and permitted to accept?”
Data Ops must answer:
“What can the agent actually reach, change, disclose, or execute?”
A vendor indemnity cannot prevent unauthorized data access. A privacy assessment cannot revoke an active credential. A secure sandbox cannot decide whether an automated employment decision is lawful.
The practical rule is:
Legal Ops can allocate risk. Data Ops must constrain the system that creates it.
When “Human In The Loop” Becomes a Rubber Stamp
Human oversight is often presented as the solution to autonomous AI risk. Sometimes it is. Sometimes it is only a description of the workflow. A human approval process may be ineffective when the reviewer:
sees only the final answer;
does not see the tools or data used by the agent;
lacks the time to evaluate the proposed action;
reviews too many decisions to challenge them meaningfully;
lacks authority to reject or modify the output;
assumes the system is more reliable than it is;
cannot reverse the action after approval; or
receives no record of what the system did before requesting approval.
In these situations, the person may be present but not genuinely in control.
This risk is particularly serious when an agent operates faster than ordinary human review, performs a series of actions before requesting approval, or makes decisions that are difficult for a non-specialist to understand.
A meaningful human-oversight process should identify:
the point at which human intervention occurs;
the information presented to the reviewer;
the decisions the reviewer must make;
the consequences of approval;
the reviewer’s authority to reject or override the agent;
and the evidence retained after the decision.
The important question is not whether a human clicked a button but whether the human could reasonably understand, challenge, and stop the action before harm occurred.
Who Will Be Questioned After An Incident?
When an autonomous AI system causes harm, an investigation is unlikely to focus only on the person who entered the final instruction. Responsibility may be traced through a chain of organizational decisions.
The business owner may have defined the objective. The technology team may have integrated the agent. The data owner may have approved access. Security may have configured the credentials. Legal may have reviewed the vendor terms. Procurement may have accepted the supplier’s conditions. A senior executive may have approved deployment and accepted the remaining risk.
The relevant questions may include:
Who approved the use case?
Who understood the agent’s capabilities?
Who authorized the data and system access?
Who decided that production deployment was appropriate?
Who determined that human review was sufficient?
Who was responsible for monitoring?
Who had authority to stop the system?
Who accepted the residual risk?
Did the system remain within its approved purpose?
This does not mean that an individual executive is automatically personally liable because an AI system failed. Liability depends on the facts, applicable law, corporate structure, contractual relationships, and the person’s actual role. It does mean that enterprises should not assume responsibility will be assigned solely to the employee who typed the prompt.
The exposure may have been created much earlier, when the organization decided what the agent could access and what it could do.
The Autonomous Agent Authority Audit
Before moving an agent from pilot to production, the business owner and relevant control functions should complete an authority review.
This audit should not be treated as a replacement for the enterprise’s risk-tiering framework. It is a focused control review for systems that can act.
A use case may be classified as High Risk because of the people affected or the consequences of error. The authority audit then determines whether the agent’s permissions, tools, oversight, and evidence controls are adequate for that classification.
When Should An Enterprise Escalate an AI Agent?
An AI use case should be reassessed when the agent receives new authority or when the consequences of its actions increase. That may occur when:
a read-only system receives write access;
a recommendation system gains the ability to execute;
an internal tool becomes customer-facing;
a pilot is connected to production data;
sensitive or regulated information enters the workflow;
a new external API or connector is added;
a vendor changes the model or system architecture;
the agent is permitted to operate without continuous human involvement;
the affected population expands;
human review becomes faster, less frequent, or more procedural;
the agent can initiate transactions or modify access;
or an incident, complaint, or near miss occurs.
The system does not need to be redesigned from the beginning every time a change occurs. But the organization should be able to identify which changes require reapproval, additional testing, or movement to a higher governance level.
The critical point is that authority changes should trigger governance changes.
Why Pilots Become Governance Problems
Many enterprises begin with a controlled pilot. The tool may initially be used by a small group, with non-sensitive data, limited permissions, and close supervision. That can be an appropriate starting point.
The governance problem arises when the pilot becomes embedded in everyday operations without a formal decision to expand its authority.
Users may begin relying on the system for more purposes. New data sources may be added. An employee may connect an additional application. The vendor may release a new model or tool capability. A workflow may be automated because the manual process appears repetitive.
Over time, the system may move from:
assisting one employee;
to supporting a department;
to influencing a business process;
to performing actions on behalf of the organization.
The formal documentation may still describe the original pilot. That gap between documented purpose and actual use is one of the most important warning signs in autonomous AI governance.
Executive Accountability Is An Operating Issue
While not approving every low-risk AI experiment, senior management needs visibility into systems that can affect customers, employees, financial records, regulated data, production environments, or external communications. Executives should be able to answer:
Which AI systems can act without reviewing every individual step?
What is the most consequential action each system can perform?
What data and systems can it access?
Who approved that authority?
How is human intervention implemented in practice?
Can the organization stop the system within minutes?
Can the company reconstruct its actions?
What changes require reapproval?
Which executive or committee accepts the remaining risk?
These questions create a practical connection between business growth, legal accountability, technology governance, information security, and board oversight.
They also reinforce a principle from LexGuard’s broader AI governance approach:
AI risk is not only a technology issue. It is an enterprise operating issue.
Conclusion: Govern the Authority, Not Only the Model
Enterprise AI governance begins with classification. Organizations need to know which use cases are limited, controlled, high risk, or unacceptable.
But classification is only the beginning.
Once an AI system can access data, call APIs, execute workflows, modify records, or communicate externally, the organization must govern the authority that surrounds the model. That requires a clear objective, controlled identity, limited permissions, approved tools, an appropriate execution environment, meaningful human intervention, reliable evidence, and an independent ability to stop the system.
LexGuard’s risk-tiering framework helps enterprises determine how much scrutiny an AI use case deserves. Authority governance addresses the next question:
Does the system’s actual capability match the level of risk the organization approved?
The answer should be documented before the agent is connected to production systems.
The future of enterprise AI governance will not be defined only by which models companies use. It will be defined by how carefully they delegate authority to those models.
The organization that governs the model but ignores its permissions is not governing the system.
1. Who is responsible when an autonomous AI agent takes unauthorized action?
Responsibility may involve several parties, including the business owner, technology team, data owner, security team, vendor, and executive who approved the system’s deployment or accepted its residual risk. The person who entered the final prompt is not necessarily the person who authorized the agent’s access, permissions, tools, or ability to act.
2. Are AI prompts and company policies enough to control autonomous AI agents?
No. Prompts and policies express the organization’s intended rules, but they do not replace technical controls. Enterprises should also use least-privilege permissions, restricted API access, isolated execution environments, activity logging, human approval gates, monitoring, and independently tested shutdown procedures.
3. When should an enterprise move an AI agent to a higher risk category?
An enterprise should reassess an AI agent when it gains new permissions, accesses sensitive data, connects to external APIs, modifies records, initiates transactions, affects customers or employees, operates with less human review, or moves from a pilot into production. Any significant change to the model, vendor, data, geography, or level of autonomy should also trigger a governance review.