Scoping What an AI Agent May Do Alone

Can I trust an AI agent to grant access? Not as a general yes or no: the answer is written per action. Several vendors let an admin give each action or tool the agent can call one of three modes: it runs alone, it waits for a human approval, or it is not exposed. Freshworks names them Always allowed, Approval required and Blocked. A team chooses the mode for each action with a few questions. Who asked, and how was that checked? What does the action open, to whom, for how long? Can a human undo it in a few minutes, without data loss and without a second approval? A no keeps the action behind approval. A yes only makes it a candidate, because an undo does not erase what happened in between: Okta documents that an MFA reset can’t be undone. In the cautious policy proposed here, privileged access, spend above a written threshold and the decision to remove someone stay off the unattended list at first.

Why “routine requests only” is hard to audit

The sentence most teams write first: the agent handles routine requests, and anything sensitive goes to a human. It reads as a policy and behaves as an opinion, because routine is a judgment rather than a value any system stores, so it is hard to show that anyone broke or followed it.

The unit that can be checked is the action type, at the granularity the product exposes. Siit’s IT Agent page prints its actions one per line, with the slash command a playbook writer types: twenty-two in all, including /okta reset password, /okta reset multi-factor, /okta add to group, /google add to group, /slack add user to channel and /webhook. Freshservice sets its Copilot Agent permissions on each action of each connected app. Each line either belongs on your unattended list or does not, and the boundary is the document that says which, with a reason.

Vendor guidance stays one level above that vocabulary. Siit’s rollout checklist says to “Require approvals on any action that changes identity, security, or data”, and Zendesk advises marking actions that write data, such as a refund, as agent-approved. Both are sound, and neither says whether adding an employee to a Slack channel changes security. Mapping a named action onto a category is the work, and the list records it. The settings each procedure then runs under belong to what autonomy means for an IT agent.

Is the gate enforced by the platform or by the instructions?

An approval written into the agent’s instructions and an approval enforced by the platform are not the same control. Console states that approval checks can be attached to all of its actions and are enforced by backend logic before execution, and that the AI agent “doesn’t determine whether approvals are required”. Serval states that its help desk agent only gets the tools a team explicitly turned on, mainly published workflows that run as written.

Zendesk documents the other side for its own feature: an auto assist action marked pre-approved runs without a human agent’s approval, may run in a different order than the procedure specifies, and auto assist “may execute the action without satisfying its prior conditions”. A condition written in prose is an instruction to the model, not a gate.

Confirmation is a third thing. Ravenna separates a tool that requires confirmation, where the requester confirms in the conversation and no approval round is created, from one that requires approval, which opens a round with separate approvers. A requester confirming their own access request is not someone else authorizing it. Check which of the three a product means before writing “approval” on a line.

What does the undo question settle, and what does it not?

An action that fails any of the three conditions of the undo question stays behind approval. That is the question’s real use: it vetoes quickly. In this method it does not release an action on its own, because it measures the configuration and not the exposure. Group membership shows the difference. The state is easy to restore, since the removal exists. What cannot be restored is the interval: whatever the group opened was open, and anything read from behind it was read. A removal is not an undo but a second change in the opposite direction.

The same reasoning applies to credentials. Okta’s pages describe the admin actions; the reasoning about exposure is this page’s, not Okta’s. Its Classic Engine page for resetting a password notes that admin-initiated flows ask for no further factor, and its page for resetting authenticators says the user must enroll again and “This action can’t be undone.” Re-enrollment restores a factor. It does not restore the period during which the account was reachable by whoever asked for the reset, nor tell you who that was. A reset is therefore only as safe as the check on the requester. Harmony documents one such check for its password reset agent, a one-time password or an Okta Verify push in place of an approval; the channel an employee typed into is not a check of that kind.

Which action types start unattended, and which behind approval?

The cards below apply the line to the actions most teams meet first. They are a starting point written for a first deployment, not a validated security procedure, and none of them replaces your identity provider’s own controls.

• 01

  Password reset: approval by default

  Okta's Classic Engine admin reset emails a link, and the password is immediately reset, or sets a temporary password, with no other factor asked. Harmony's reset agent uses a one-time password or Okta Verify push instead of approval. A chat channel alone is neither.

• 02

  MFA reset: approval, and no undo

  Okta states that resetting authenticators cancels the enrollment and that the action can't be undone. Re-enrolling is a new enrollment, not a restore, and the gap in between is exposure. The check on who asked carries most of the risk.

• 03

  Group membership: approval by default

  A safe threshold is hard to state in advance, because it depends on what the group opens. What it opened may already have been used, and undoing it starts by finding why the person has the access at all.

• 04

  Time-limited app access: judged on five axes

  Rights, sensitivity of the application, recipient, duration and consequences are separate questions. An expiry ends the grant, not what was read during it, and a group can grant the same access. Until each is written down for the application, it stays behind approval.

• 05

  Ticket creation: a candidate, with side effects named

  Closing a ticket does not undo what its creation set off, such as notifications or a webhook. It is a reasonable first unattended action once those side effects are written on its line.

• 06

  Anything attached to a departure: separate three things

  Authorization of the change, a reliable trigger, and execution are different steps. A departure already authorized upstream can be executed by a process. Letting the agent decide who is removed stays off the list.

Two points follow. The undo question appears in only some cards, because verification and sensitivity decide more of the outcome. And since a group membership can deliver the same access as a time-limited grant, a team that refuses group additions but allows time-limited access has drawn two lines for one risk.

Which three categories stay off the list at first?

This is a proposed policy for a first deployment, not a property of the tools; a team can write a different one, with the reason next to it.

Privileged access. On privilege, the policy proposed here is an approval step, not an easy withdrawal. Microsoft Entra Privileged Identity Management shows why “privileged” needs splitting before it goes on a list. An assignment is eligible or active: an active member holds the role’s privileges without doing anything, an eligible member must activate the role first. Separately, an assignment is permanent or time-bound, with start and end dates. Activation is a third step: the member picks a duration within a maximum set by administrators, and the role can require multifactor authentication, a justification or an approval before it activates. Microsoft describes approval as enabled for specific roles, so whether a human signs each activation depends on the tenant’s settings.

Spend above a written threshold. The undo question measures what an action does to a system, not what it commits on your behalf, so here it can answer wrongly with confidence. An assignment that consumes a paid seat is easily reversible as a state change and not as a decision. The threshold works best as a number stored where the agent reads it at runtime.

The decision to remove someone. Three things are easy to run together: authorizing the change, a reliable trigger for it, and executing it. A departure already authorized by an HR process can be executed by a process. What stays off the list is the agent deciding who leaves, or acting on a conversation rather than on that authorization. The published sequences at both ends of employment, and what each leaves to a human, are in automating onboarding and offboarding IT tasks.

Where do thresholds live for self-service access requests?

On the access policy attached to an application or role, not on the request. Ravenna publishes the shape of one: eligible and ineligible groups, where deny wins over allow, a flag that requires a business justification, a duration mode that is chosen by the requester from set options, fixed, or none, which means permanent access, and approvers who can be users, groups or roles resolved at request time.

Two details of that page are worth testing in any product. If the approver set resolves to nothing, the request auto-approves rather than blocking, and a level with no policy falls back to auto-approval. And a requested duration that is not among the options snaps to the closest allowed option rather than being accepted as-is, for API and MCP submissions, and is rejected if no option resolves. Both are documented behaviors of one product, not defects of the category. The connection to the directory those policies rely on is covered in the identity provider profile.

What the list does not settle

A line moves. An action type earns unattended running by behaving predictably across a period agreed in advance, in a pilot audience first. Siit’s page describes one such sequence, publishing playbooks as Draft, then Pilot audience, then Live, with a simulate mode to validate before actions are allowed, and every step logged and replayable. A line loses that standing when an incident shows the threshold was wrong.

A run log records what the agent did, not what a team decided about it. The decision belongs beside the changed line, with two fields: the date and the reason. That holds in both directions, including for an action pulled back after an incident.

No method settles whether a line sits in the right column: that depends on which applications sit behind which groups, the incident history, and how quickly somebody would notice. A list only makes each argument about a named action rather than about the word sensitive.

Which vendors document what an agent may run alone?

Listed here: vendors whose public documentation states, per action or tool, whether their AI agent or copilot runs it alone, after an approval, or not at all.

• Console: Console’s approvals and MFA article states that all actions support approval checks, enforced by backend logic before execution rather than by the AI agent.
• Freshworks: Freshservice’s Copilot Agent page, a copilot for human agents, lets an admin set each app action to Always allowed, Approval required or Blocked, the approval coming from the human agent using it.
• Harmony: Harmony’s Password Reset Request agent page states that no approval is required and that the agent verifies identity instead.
• Ravenna: Ravenna’s agent configuration page sets an execution policy per tool, Auto-execute, Requires confirmation or Requires approval, with write and delete tools defaulting to confirmation.
• Serval: Serval’s product security page states that the help desk agent only gets the tools a team explicitly turned on, and advises approvals for sensitive grants.
• Siit: its IT Agent page describes a running mode set per action, Auto-run or Approval required, and states that only whitelisted actions are available to the agent.
• Zendesk: Zendesk’s page on actions for auto assist, a copilot for human agents, lets an admin mark each custom action in a procedure pre-approved or agent-approved, and notes that actions don’t work on AI agent tickets.