Managed autonomy: what agentic AI should mean for IT and security

An agent does more than recommend a next step. It can take that step. For IT and security teams, the useful question is therefore specific: which action may it take, on which systems, and under whose authority?

Managed autonomy starts with those boundaries. It gives routine work a clear path to completion while keeping sensitive changes under human control.

One loop, four responsibilities

A useful agent workflow connects four stages:

1. Observe: collect the signals relevant to an event, such as a sign-in, device state or service request.
2. Decide: assess the event in context and propose an action.
3. Check: compare the proposed action with the permissions and approval rules set by administrators.
4. Act: perform an allowed action, or wait for approval, and record the outcome.

Each stage matters. A strong decision without an authority check is incomplete. A successful action without an evidence record can be difficult to investigate later.

Set boundaries around actions

“Manage this device” is too broad to be a useful rule. Reading its inventory, applying a patch and isolating it from the network are different actions with different consequences.

For each action, define the systems it can affect, the conditions under which it is allowed, and the person responsible for reviewing exceptions. Keep the initial scope small enough that your team can understand the results.

A practical starting point: automate frequent, well-understood actions with a limited impact. Require approval where a mistake could interrupt a critical service or remove access.

Make approval useful

An approval request should help someone make a decision. Include the triggering event, affected systems, proposed change, expected impact and any recovery steps.

Decide what happens when the request is rejected, expires or reaches an unavailable approver. The absence of an answer should never silently expand an agent’s authority.

Keep evidence that explains the result

A useful record answers five questions:

• What started the workflow?
• What information was considered?
• Which policy allowed or blocked the action?
• Who approved it, where approval was required?
• What changed, and did the verification succeed?

That record supports day-to-day troubleshooting as well as later reviews. It should be understandable to an administrator who was not present when the event happened.

Expand gradually

Begin with one workflow and a small set of systems. Review normal outcomes, denied approvals, missing inputs and failed actions. Expand the scope only when the people operating the workflow understand its behaviour.

The aim is predictable operations: an agent that can act, and a team that can explain and control what it does.

For a worked example, read Plan an approval guardrail.