What Autonomy Means for an IT Agent

Autonomous AI agents for IT are agents that carry out IT work, not only answer questions about it, within limits an administrator sets and can read back. Autonomy is therefore a configuration, not a property a product has or lacks. What bounds a single action is concrete: the tool the agent may call, the destination it reaches, the arguments it may pass, the credential behind the call, whether a person must approve first, and whether the result can be taken back. Publishers place these controls differently. Ravenna sets an execution policy on each tool an agent may use, Serval limits its help desk agent to published workflows, which can require approvers, and Microsoft’s Privileged Identity Management, outside AI, makes approval one optional step in activating a role. Reversibility is the one bound no setting provides: it depends on the action and on the target system. The useful question is which of these controls a publisher documents, and whether its logs let you check them.

Autonomous AI agents for IT are configured, not adopted

Autonomy is easily read as a yes or no. The documentation read for this guide describes a decision attached to a unit of work, and the unit differs by publisher.

Ravenna attaches it to the tool. Each tool referenced in an agent rule can carry an execution policy: Auto-execute, Requires confirmation or Requires approval. Read-classified tools default to the first, write- and delete-classified tools to the second, and “Admins can override either default per rule”. Serval attaches it to the workflow: its help desk agent can only invoke published workflows, and approval procedures are “hard-coded into the workflow, not optional at runtime”. Siit attaches it to the procedure: its AI trust model sets one of three levels per playbook, Suggest only, Execute with approval or Auto-execute.

A second control is often read as a level when it is not. Ravenna deploys an agent to channels, and each channel has at most one agent. Channel deployment controls where the agent is exposed; the execution policy on each tool controls whether an action may proceed. Deciding which procedures belong at which setting is a separate exercise, set out in scoping what an agent may do alone.

What bounds a single action?

A closed action list limits which tools exist, not what each tool can do downstream. That is set by the tool, its destination, the arguments it accepts and the rights of the credential behind it.

Serval documents the argument and credential layers: the model cannot alter a published workflow and “can only invoke it with the parameters you defined”, and an integration’s scopes form a ceiling that “is set at setup and no workflow on the team can exceed it.” Ravenna lets a rule pin a tool input to a fixed value, stripped from what the model sees and injected at execution, which is how a destination or an account can be fixed rather than chosen by the model. Siit’s trust model lists “parameter whitelists” among its extra controls and reaches third-party systems through “dedicated, scoped service accounts or OAuth scopes”; the page does not describe a destination setting.

A short list of narrow actions with fixed parameters and a scoped credential is a small surface; a short list with one action taking a free destination or body is not. The credential itself is granted on the connected system’s side, a separate check covered in security and compliance of an IT agent.

Can I trust an AI agent to grant access?

Granting access is answerable through three settings: who has to say yes, what happens when nobody does, and whether the access has an end.

Two kinds of yes appear in the documentation, and they are not interchangeable. A confirmation asks the person using the agent. Atlassian’s guidance for Rovo agents says that in interactive use “there’s always a human in the loop to review and approve an action”. Freshworks’ AI Agent Studio offers an Ask for confirmation option on an API action, so the agent confirms with the employee before running it. An approval asks someone else. Ravenna draws the line itself: confirmation is “a soft guardrail when the requester is also the person authorized to take the action”, while approval opens a round with separate approvers. For an access grant, the requester confirming their own request is not an approval.

Approval designs differ in what they can express. Siit names an assignee, team lead or manager. Serval documents individual approvers, groups with an optional quorum, managers, multi-step chains and rule-based logic. Moveworks’ approvals engine runs sequential or parallel steps that advance on one approver, N of M or all, and a single denial denies the whole request. Console states that its agent “doesn’t determine whether approvals are required, who is authorized to approve, or whether approval conditions have been met”: the backend checks before execution. Microsoft PIM, outside AI, describes activation actions that “might include” a multifactor authentication check, a business justification or approval from designated approvers.

What an approval does when nobody answers is the part to check. Harmony lets an administrator require approval from all approvers, from one of them, or escalate when the first approver does not respond, with a wait of one to seven days before timeout or escalation.

Access that is granted can also be given an end, and the schedule and the outcome are two different facts. PIM assigns time-bound access “using start and end dates” inside the Microsoft services it manages. For an agent granting access in another application, an end date is a scheduled removal that has to execute and be confirmed there, with a visible failure when it does not complete.

How do you test an agent before it acts?

Several publishers document a trial mode; three of them define it by what it suppresses. Ravenna’s Testing Mode is “a sandboxed chat that runs the agent end-to-end without writing tickets or sending messages.” Serval’s Simulations, in beta, run saved scenarios on isolated tickets, and “workflow calls and access requests are simulated by default, so nothing changes in your connected systems unless you explicitly allow it.” Siit’s shadow mode tests playbooks with “simulate” to log what would have happened without making changes.

Ravenna’s agent upgrade creates a new copy connected to no channel while the current agent “keeps running unchanged”, so a new version is reviewed before traffic moves to it. Siit’s rollout checklist starts in a pilot channel in shadow mode.

What can be stopped, and what cannot be taken back?

At Atomicwork, if an AI coworker is unpublished mid-run, “that specific in-progress run will still finish” and no new runs start until it is republished. Siit’s kill switch pauses an agent or a single playbook instantly, with requests falling back to humans. Three cases need telling apart: blocking new runs, interrupting a run already active, and canceling actions waiting in a queue. Atomicwork’s unpublish is the first case, with the active run left to finish; check separately, for any product, whether a pause also interrupts an active run or cancels queued actions. Effects already produced are a separate question: a pause does nothing to an action that has already completed.

Siit’s trust model, under human in the loop, describes overriding or rolling back through a paired playbook. A paired playbook is a compensating action: it can reverse a change where someone has built and tested the reverse, such as removing a group membership that was added. It cannot recall a message already sent, restore a record the target system did not retain after deleting it, or undo access already used before a revocation took effect. Serval states the same boundary for its simulations: once live calls are allowed, “a live workflow that ran in an earlier turn can’t be undone, even if you stop the run.”

What does a log have to contain before it counts as evidence?

Serval logs every workflow run step by step with inputs, outputs and status, and tracks each published workflow version with timestamps and authors. Atomicwork’s run detail lets an administrator expand each tool call to inspect “the exact request and response payloads”, and its run statuses include Paused for Approval. Siit logs every answer, decision and external action in the request timeline with who, what and when, inputs, outputs and the playbook used. Ravenna classifies each agent conversation with a result type, such as Answered, Ticket Created or Missing Knowledge. PIM lets an administrator download audit history.

Who, what and when establish that something happened. The inputs and the version of the procedure that ran establish why, which separates a wrong procedure from a right one fed bad inputs. The approver’s decision, recorded with the action, shows who authorized it.

• 01

  Where does the decision live

  On a level per procedure, a policy per tool or the publication of a workflow. Where the agent is deployed is a separate control: it decides where the agent listens, not whether an action may proceed.

• 02

  What can an action be called with

  A closed list limits which tools exist, not what each one does. Look for fixed or pinned arguments, a fixed destination and a scoped credential, such as the ceiling Serval sets when an integration is connected.

• 03

  Who says yes, and when nobody does

  A requester's confirmation and a designated approver's decision are different controls. Ask which one applies to which action, and what a pending approval does when nobody answers.

• 04

  What does the trial suppress

  Siit's shadow mode logs what would have happened. Ravenna's Testing Mode writes no tickets and sends no messages. Serval's Simulations simulate workflow calls by default. Each covers different side effects.

• 05

  What cannot be taken back

  A pause may block new runs, interrupt an active run or cancel queued actions; a product may do only some of these. Effects already produced are separate: a compensating action exists only where built, and a deletion, a sent message or access already used is not undone.

What none of this proves

Autonomy is also assessable only from what a publisher documents: one that publishes neither its settings nor its log leaves the question to a security review. And an autonomy setting describes how one action or procedure runs; it does not measure how much of an IT function has been handed over. What the category covers is set out in what an AI service desk agent is, and is not.

Which vendors document how an agent’s autonomy is set?

Atlassian’s Rovo and Freshworks’ AI Agent Studio, cited above, document a confirmation by the person using the agent, not a designated approver, in the pages read for this guide.

Listed here: publishers whose public pages show how an administrator sets what the agent may do alone, by action, tool or level, when a designated approver must sign off before it runs, and what log records what was executed.

• Console: its approvals article says all actions support approval checks, enforced by Console before execution rather than by the AI agent, and its audit article traces an action from the request through the approval steps to the resulting change.
• Harmony: its agent configuration page sets, per agent, auto-approval for app access or who must approve and how, and its page on working with agents shows each run step by step with inputs, outputs and errors.
• Ravenna: its agent configuration page sets an execution policy per tool, Auto-execute, Requires confirmation or Requires approval, and its trust and privacy page describes an audit trail of “AI interactions, tool executions, and configuration changes”.
• Risotto: its Okta integration product page says role-based access controls define “which actions require manager or admin approval before proceeding”, and that every action is logged with requester, workflow, approvals, result and timestamp.
• Serval: its product security page says the help desk agent can only invoke published workflows, that a workflow can require approvers, hard-coded rather than optional at runtime, and that every run is logged with inputs, outputs and status.
• Siit: its AI trust model sets one of three levels per playbook, Suggest only, Execute with approval or Auto-execute, and logs each external action in the request timeline with inputs, outputs and the playbook used.
• Zendesk: its article on advanced action flows, in early access, says its AI agents can select and run a published flow autonomously, that a flow can create an approval request for a set approver, such as a manager, and pause until it is decided, and that a paused flow can be resumed from its execution history.