CIO.com: IT leaders draw agent autonomy lines per action, not per agent

IT leaders are building agents faster than they are handing them authority, CIO.com reported on 5 November 2026. The article cites a KPMG survey from July and August in which 62% of IT leaders said they were building, deploying or developing AI agents, up from 53% the previous quarter. It also reports that many of the same leaders remain uncomfortable letting agents run internal processes, with exceptions for low-risk work such as tier 1 IT support.

Where the executives draw the line

• Jim Olsen, CTO of governance vendor ModelOp, says restricted autonomy is already in use, for example processing customer refunds or credits without human intervention. He does not expect agents to get full autonomy in enterprises in the near future and recommends a strict sandbox with defined policies.
• Siroui Mushegian, CIO of Barracuda Networks, says the company has about 2,000 agents and still has humans checking their actions. Her rule: 'The consequences of a mistake should determine how much evidence you need before giving an agent more authority.'
• Joshua Rowe, co-founder and CTO of Taupia, says he would 'draw the line at the action rather than the agent'. His company is testing an agent that compares energy deals and takes steps toward switching a customer's provider, but the customer must still confirm the change.
• Maciej Walaszczyk, CTO at customer service platform provider Text, says an agent 'cannot have more authority than I do' and that oversight 'takes time and attention, and it means much more than clicking approve'.

Reversibility as the test

Rowe's argument is the most concrete in the piece. He says the timeline for autonomy over irreversible actions does not depend on models getting smarter. It depends on how quickly an organisation can make each action reversible or bounded, with spending limits, cooling-off periods, rollback and an audit trail good enough to undo a mistake. Where an action cannot be undone, such as signing a contract or moving money out of an account, he would keep a person approving it for the foreseeable future.

Mushegian offers a matching test for where to start: routine internal support requests where the answer is well documented, the action is limited and a mistake is easy to correct. She names changing access permissions or editing a production system as poor candidates.

Risks the article names

Olsen points to 'autonomy creep', where agents quietly take more authority than they were given, and to individuals who gave early personal agents full access to their email, which he says worked out for some people but was 'a large risk exposure'. The article also notes that human-in-the-loop checks do not always give employees the authority or time to fix agent errors. Olsen lists API gateways, OS-level enforcement and credential management as ways to hold agents to runtime policies, and says a more cohesive strategy is still needed.

What the article does not show

This is a set of opinions, not a measurement. It gives no data on how many agents run unsupervised, what mistakes cost, or how often human reviewers catch errors. Two of the four executives work for vendors of governance or customer-service agent products. The KPMG figures are relayed second-hand, with no sample size or definition of 'building, deploying or developing' given in the article.

The practical takeaway for a rollout: write the permission list per action, not per agent. For each action, record whether it can be reversed, what limit applies, who approves it and where the log lives. Then widen autonomy one action at a time as the evidence builds.