Stop Asking Whether Your AI Agent Is Autonomous. Ask Who Owns Its Actions.
Calling an enterprise AI agent autonomous sounds like progress. It is also a convenient way to make accountability disappear.
This week, MIT Sloan Management Review and BCG put a useful stake in the ground: operational autonomy is not moral or legal autonomy. An agent can plan, call tools, route work, and act without a person approving every click. It still cannot explain itself to a regulator, absorb a loss, or sit across the table from a customer after a bad outcome.
That distinction is more than semantics. It is the dividing line between an AI program that can scale safely and one that turns every incident into a blame hunt.
The dangerous sentence in an incident review is not "the agent made a mistake." It is "the agent decided." Software does not get to own a decision. The people who chose its goal, granted its access, connected its tools, and accepted its output do.
The autonomy debate is pointed at the wrong target
The recent discussion about agent autonomy can become abstract very quickly. The practical question is simpler: what is the agent allowed to do when nobody is watching?
An agent that drafts an internal meeting summary and an agent that can approve a refund, update a supplier record, or query a production system may use the same model. They should not receive the same governance treatment.
MIT Sloan's panel makes the key point well: agents are autonomous in an operational sense. They execute delegated work within a system humans designed. That means the right unit of governance is not a fictional digital employee. It is the whole operating environment around the agent:
- the business owner who defined the outcome;
- the team that connected data and tools;
- the identity and permissions the agent received;
- the approval and exception paths available at runtime; and
- the people accountable for monitoring and stopping it.
This matters because most enterprise failures do not begin with a spectacular model hallucination. They begin with an ordinary automation being given a little too much context, a little too much authority, or no clear owner. A policy that says "use human oversight" does not resolve any of that.
Accountability has to be designed into the workflow
The Australian Institute of Company Directors made the board-level version of the same argument this week. Its guidance asks boards to see purpose, validation, exceptions and overrides, and accountability in the systems shaping the information they receive. Those are the right questions for every agentic workflow too.
For an enterprise security leader, the useful test is not "Do we have an AI policy?" It is whether each meaningful agent action has a visible chain of responsibility.
Start with a simple action register. For every agent use case, document the action, the data it can touch, the systems it can call, the business owner, the technical owner, the approval threshold, and the emergency stop mechanism. If any field is blank, the agent is not ready for production.
Then calibrate autonomy to consequence, not novelty. Low-impact, reversible tasks can run with lighter controls. An agent that sends a draft for review is different from one that changes a customer record. An agent that recommends a remediation is different from one that deploys it. The higher the impact, the harder the controls must be to bypass.
That last point is often missed. Approval gates, scoped permissions, and hard stops must exist in the architecture, not only in a prompt or wiki page. A prompt can be ignored, misinterpreted, or defeated by a malicious instruction. A narrowly scoped service identity and a runtime approval gate are much harder to wish away.
Shadow AI makes the ownership problem worse
Formal agent programs get most of the attention. Shadow AI is where accountability usually breaks first.
A department may connect an unapproved assistant to a shared drive, give a browser agent access to a finance portal, or enable an AI feature inside a SaaS tool without telling security. The business sees a productivity win. The security team sees it only after sensitive data has crossed a boundary or an action has already been taken.
That is why discovery is a governance control, not just an inventory exercise. You cannot assign an owner, apply a data rule, or set an approval threshold for an agent you do not know exists.
A mature program combines continuous visibility with a path to safe adoption. Find the tools and connections people are already using. Classify the risk based on data, permissions, and actionability. Then give teams an approved route that is easier to use than workarounds. Blocking everything drives the activity further underground; allowing everything turns governance into a postmortem function.
Four controls to put in place now
1. Name an accountable owner before deployment. Every agent needs a business owner accountable for outcomes and a technical owner accountable for its integration, identity, and controls. "The AI team" is not an owner.
2. Use action-level permissions. Give agents the smallest possible authority for the narrowest possible time. Read access is not write access. Drafting is not sending. Recommending is not executing.
3. Build meaningful approvals and stops. Require human approval for consequential or hard-to-reverse actions. Make the approval context-rich, and make it possible to revoke access or stop a running workflow quickly.
4. Log the decision path, not just the chat. An audit trail should show the trigger, inputs, tools called, permissions used, human approvals, final action, and any exception. Conversation history alone will not explain an operational incident.
The governance standard is becoming clearer
Boards, regulators, customers, and incident responders will not accept "the agent did it" as an answer. They will ask who authorised the use case, who supplied the data, who granted the access, and who was expected to intervene.
That is not a reason to avoid agents. It is a reason to deploy them as accountable systems rather than magical coworkers.
Aona helps enterprises discover Shadow AI, understand where sensitive data and risky permissions are exposed, and put practical controls around AI use before an incident makes the gaps obvious. See how Aona approaches AI security and Shadow AI discovery and start with the agent workflows already operating inside your business.
