Skip to content
redactsure
Book a demo

Explore.

Guide · By Chris Sowa · Published
Last updated

How to Secure AI Agents That Act Without Human Approval

Grant autonomy per task for low-consequence steps, keep six action categories with a named person, and hold the grant in an environment you own; 23% of organizations scale agents.

Application tasks cross a sequence of control panels with a separate activity ledger.

62% experimenting · 23% scaling · 1 named person

Most organizations are experimenting with AI agents and few are scaling them, 62% against 23% in McKinsey's 2026 survey (CX Today, 2026). The gap is not the model. It is the question nobody wants to answer on the record: who let the agent do that? An agent can be set to act on its own in one click, and cannot be set to answer for itself. Rome met the same problem with the dictator: full power for one task and six months, then handed back; the Senate kept the grant, the term and the name. An agent's autonomy needs the same shape: a scope, a term, a name, and a place where the grant is written down.

Secure an agent that acts without approval by deciding, in advance and in writing, which steps it may take alone, which actions wait for a named person, and where that decision is kept. A rule you wrote, or a model the vendor runs, can stand in for the person on reading, sorting and drafting. For a payment or a record change, a rule decides what the agent may try; only a person can answer for what it did.

Four agents ship four different answers to who is absent when the agent acts

The standard to hold each against is Supervised Delegation: a named person grants the access, chooses the applications, confirms what is tokenized, can watch and pause the run, and approves every consequential action, on the record. OpenAI's dots take Custom Rules for what a dot may do alone, do "proactive research" in read-only mode when the user is away, and run Auto-review on planned actions; "Custom Rules cannot override mandatory confirmations" (OpenAI, 2026). Claude in Chrome defaults to "Automatically approve" with a pause on risky actions; "Manually approve" is the other setting (Claude Help Center, 2026). Copilot Studio's computer-using agents run unattended on built-in credentials "never exposed to the AI model" (Microsoft, 2026) and email a reviewer when harmful instructions are detected, stopping the run if no response arrives within the configured time (Microsoft Learn, 2026). AgentCore governs actions through Policy, set before the run (AWS, 2026).

Property Rule the user wrote Vendor's reviewing model Reviewer notified after Named person in an environment you own
Who decides a consequential action The rule's author, in advance The vendor's model, at run time The reviewer, or the run stops at the configured time The person, as it is proposed
What the model reads The page in full The page in full The page in full The task's fields, identifiers as tokens
Where the grant sits Vendor settings Vendor settings Vendor settings The per-task policy you hold

Six categories of action stay with a person, and OMB M-24-10 says why

Consequential means anything that leaves the organization or changes its records: a payment, a submission to another party, a change to a record of account, an external message, a key created, and anything made public. Cloud spend is a payment; an open port is public exposure. Each task adds its own, a reserve change or a prior authorization, named by the person who confirms the policy.

Regulators drew this line first. OMB M-24-10 sets minimum practices for rights- and safety-impacting AI, human oversight and monitoring among them (OMB, 2024). The NAIC Model Bulletin addresses insurers' use of AI systems (NAIC, 2026), and 24 states had adopted it by March 2025 (Quarles & Brady, 2025). The NIST AI Risk Management Framework opens with Govern, which is where the name goes (NIST, 2023).

OpenAI's advice for dots is to "always review consequential work" (OpenAI, 2026). The disagreement is whether the person sees the specific action on the specific record as it is proposed, or a summary later.

A rule holds only as far as the page the agent read, which Greshake showed in 2023

2023 first demonstration · 4,000+ apps one agent reaches · 0.08% attack success one vendor reports

A Custom Rule is a sentence about the future. A page is the present. Greshake and colleagues showed in 2023 that instructions planted in observed content can redirect an application (Greshake et al., 2023), and OWASP lists prompt injection first among LLM risks (OWASP, 2025). An agent that can connect to more than 4,000 apps (The Next Web, 2026) reads pages nobody you employ wrote. One vendor reports attack success under 0.08% in internal testing (Claude Help Center, 2026); the remaining fraction, over an overnight run, is the action the rule did not anticipate. Microsoft's AI Red Team catalogs the agent failure modes an approval step catches (Microsoft AI Red Team, 2025).

Render-layer tokenization is replacing sensitive values with consistent stand-in tokens at the point where a screen is rendered, before any AI model reads it, so the model works with SSN_001 and ACCT_001 and real values resolve only at approved destinations at the moment of action. A planted instruction then collects tokens, and the consequential action still stops for the person.

Autonomy is granted per task, not per product, as Gartner argued in May 2026

Gartner argued on May 26, 2026 that uniform governance across AI agents leads to enterprise AI agent failure (Gartner, 2026). A product-level grant, "the browser agent may auto-approve," covers every screen the agent will ever read. A task-level grant names the task, the applications, the actions and the person.

Property Grant per product Grant per task No grant, every action approved
Scope Every screen the product can reach The applications chosen for one task The same applications
Actions covered Whatever the classifier does not flag Reading, navigating, drafting, filling fields a person reviews None
Consequential actions Depend on the classifier Always stop for the person Always stop for the person
Withdrawal For every task at once For that task only Not applicable

The grant covers only the low-consequence steps, only after the record shows clean runs with every action approved. It is a dated document in your per-task policy, and an examiner's evidence.

Three places a grant can sit, and only 1 of them survives a vendor release

A grant sits in the employee's own browser, in a vendor's cloud computer, or in an environment you own. In the first two it is withdrawn in the vendor's settings, which the next release can redefine. A dot's Activity View lets the user follow, redirect or stop work (OpenAI, 2026); the view and the record behind it are the vendor's. Muse keeps its activity log in a VM Meta runs, with a Sentinel approving every network egress (Meta, 2026).

Separation of model and control is the principle that the environment deciding what an AI agent sees and who approves what it does is owned by the customer and independent of whichever model performs the work. There the agent is a tethered agent: an agent that works only inside the governed environment a named person connected it to, on the applications that person chose. Permissions do not change; what changes is what the model can see. The grant and the withdrawal sit where you can read them, and the model swaps without moving either.

Eight steps take an agent from every action approved to bounded autonomy

  1. Read the agent's autonomy setting and write down who is absent.
  2. Connect the agent to the governed environment on the task's applications and nothing else.
  3. Have the planner write the per-task policy: fields in clear, fields as tokens such as KEY_001, actions that stop. The person confirms it.
  4. Run the task with every action approved while the person watches the tokenized stream.
  5. When the record shows clean runs, grant autonomy for that task's low-consequence steps, naming task, applications, actions and person.
  6. Keep the six categories with the person. Propose a test payment; the agent stops.
  7. Export the record to the SIEM.
  8. Review on a cadence and withdraw on the first problem.

Every screen, action and approval lands in the AI Control Record: the record of every screen the agent saw as tokens, every action, every approval with a name, exported to the customer's own monitoring. The SIEM copy answers the regulator; the withdrawal lands there too, named and dated.

6 Rules for granting an agent bounded autonomy

Name the person before the first run

The grant, every approval and the review of the record carry one name, the workflow owner's, not the platform team's or a vendor's. No name, no autonomy.

Test: Pull the per-task policy. A name field reading "admin", "IT" or a vendor fails.

Write the six categories into the policy, then add the task's own

The list is written before the run and confirmed by the named person, not inferred by a classifier during it.

Before: The agent runs on "Automatically approve" and a classifier decides what is risky.

After: The policy lists the six categories plus the task's own, each stopping for the named person.

Build the record before the grant

No autonomy on the first run. Every action is approved by name until the record shows the task completed cleanly, several times over.

Grant granted Grant refused
Clean, fully approved runs on the record One run, or none
Every screen on the record as tokens A screen carrying a real SSN
A name on every consequential action Approvals reading "auto"

Grant steps, never the task

The grant covers reading, navigating, drafting and filling fields a person will review. A task-wide grant covers whatever the agent decides the task requires, and a planted instruction decides that for it.

Test: Read the grant aloud. Actions pass; an outcome fails.

Treat the classifier as a layer, not an approver

A vendor's reviewing model is a useful control, not a name on the decision. Claude in Chrome runs one classifier that screens content for injection and one that evaluates each action (Claude Help Center, 2026); the fraction they miss is the action you answer for.

Before: The incident report says Auto-review did not flag the step.

After: The incident report says who approved it, what the model received, and when.

Keep the grant where you can withdraw it

The grant sits in your per-task policy, not on a vendor's settings page. Withdrawal takes the same person the same effort, and the first problem in the record ends it.

Signal in the record Response
A wrong value filled Withdraw, review, regrant
A screen outside the chosen applications Withdraw and tighten the connection
A consequential action outside the six Add it to the policy

How to choose where the approval of a consequential action sits

  • If the agent runs in an employee's browser on "Automatically approve," move consequential actions to "Manually approve" until you own the environment.
  • If the task touches money, records of account or anything public, keep all six categories with a named person.
  • If the work is reading, sorting and drafting only, grant autonomy per task once the record shows clean runs.
  • If the run is overnight, grant read-only steps and queue every consequential action for the morning.
  • If an examiner can ask who approved, hold the grant and the record in your SIEM, not a vendor's activity view.
  • If you expect to change models, keep the grant in an environment with separation of model and control, so the policy stays put.

The checklist

Check Pass Fail
Name on the grant A workflow owner's name in the per-task policy "Admin", a team, a vendor
Six categories in the policy All six, plus the task's own A classifier decides what is risky
Record before grant Several clean, fully approved runs Autonomy on the first run
Scope of the grant Named steps on named applications, one task "The browser agent may auto-approve"
Test payment The agent stops; the request reaches the person The payment runs or queues silently
Test injection A planted instruction collected tokens and the action stopped The planted action ran
SIEM export One run from the SIEM shows screen, action, name, timestamp The record exists only in a vendor's view
Withdrawal Same person, same effort, dated on the record A vendor ticket or an outside admin

Questions

Is read-only autonomy safe?

Safer than write autonomy, and not safe by itself. A read-only agent still reads every page in full, planted content included, and still holds working credentials for every site it reads, overnight and unwatched. It is the right first grant when the model receives identifiers as tokens, a named person chose the applications, and every screen is on the record.

Can an agent run overnight unattended?

Yes, for the steps a named person granted and nothing else. Copilot Studio's unattended runs and dots' read-only research are built for that (Microsoft, 2026; OpenAI, 2026). The overnight run cannot pay, submit, change a record, send a message, create a key or open a port. Those queue for the named person in the morning, screens as tokens on the record.

Can Custom Rules replace a human approver?

For low-consequence steps, yes; a rule and a human grant do the same job there. For consequential actions, no, and the vendor's own design agrees: "Custom Rules cannot override mandatory confirmations" (OpenAI, 2026). Prompt injection lets the content decide the action, so an action the rule did not anticipate runs. The approver sees the action on the record as it is proposed.

What counts as a consequential action?

Anything that leaves the organization or changes its records: a payment, a submission, a record change, an external message, a key created, anything made public. Domain-specific actions such as a reserve change join the list per task, named by the person who confirms the task's policy. Reading, navigating, drafting and filling a field a person will review are the low-consequence steps.

Does an approval step slow the work?

It moves the person's time from doing the task to approving its result. As an illustration, a claims examiner who worked three systems by hand now reviews one proposed payment with the evidence assembled; approving ten submissions is faster than preparing ten. The slow version is a reviewer who was not watching being asked to verify a blocked step later.

What does the regulator expect to see?

A name and a record. OMB M-24-10 asks for human oversight and monitoring of rights- and safety-impacting AI (OMB, 2024); the NAIC Model Bulletin addresses insurers' use of AI systems. An examiner asks who approved the action and what the model received, with evidence you hold. A grant with a name, a scope and a withdrawal date is that evidence.

Is the vendor's Auto-review an approver?

No. Auto-review checks a dot's planned actions against instructions, Custom Rules and safety requirements and blocks a step it rejects (OpenAI, 2026). It is a control the vendor runs on the vendor's agent: it reads the page in full and its name is not on your incident report. Keep it on, then put a named person on the six categories.

Methodology

What this page rests on. Vendor documentation read as of October 9, 2026 and quoted with its date: OpenAI, the Claude Help Center, Microsoft and Microsoft Learn, AWS and Meta. Research cited for the finding each is known for: Greshake et al. (2023), Microsoft's AI Red Team (2025). Regulation cited from the text: OMB M-24-10, the NIST AI RMF, OWASP LLM01:2025, the NAIC Model Bulletin. McKinsey figures via CX Today, and Gartner's May 2026 release.

What was not tested. No hands-on testing of any named product was performed for this page. Autonomy settings change with releases, and the page carries its date. The 0.08% figure is a vendor's internal result. No specific organization is described.

Whose determination it is. Whether a grant of autonomy satisfies OMB M-24-10, the NAIC bulletin or a state examiner is for the organization's counsel, its assessor, and its security and compliance officers to determine. This page describes a design.

How RedactSure does this

62% experimenting · 23% scaling · 1 name on every grant (CX Today, 2026)

RedactSure runs the agent inside a governed environment the customer owns: a secure virtual machine on hardware-encrypted enclaves, with keys the customer holds and ciphertext RedactSure cannot decrypt. The render layer replaces every sensitive value chosen by policy with a consistent token before any model reads the screen; the model receives the task's fields with identifiers as SSN_001 and ACCT_001, and real values resolve only at approved destinations at the moment of action. The Planner writes the per-task policy; a named person confirms it before the run and approves every payment, submission and record change while it runs. The grant of autonomy for low-consequence steps is written into the same policy, with the person's name, where that person can withdraw it.

Every screen as tokens, action and approval lands in the AI Control Record and exports to the customer's SIEM. Models swap without moving the controls, and permissions do not change. Prompt injection that succeeds against a RedactSure agent collects tokens, and the consequential action still stops for the named person. Deployments are in pilot.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.