Skip to content
redactsure
Book a demo

Explore.

Guide · By Chris Sowa · Published
Last updated

How to Reduce Rogue AI Agent Decisions: Keeping Consequential Actions With a Named Person

Put 1 named person at every payment, submission, record change and key the agent prepares, record each approval in your SIEM, and widen autonomy per task on that record.

Payment, document and database cards pass an approval gate before reaching an audit stack.

62% experimenting · 23% scaling · 1 named person

McKinsey's State of AI 2026 found 62% of organizations experimenting with AI agents and 23% scaling them anywhere (CX Today, 2026). Most of the 62% have not answered one question: how will the agent be kept from acting on its own? A rogue decision is an action no person approved. The answer is not a setting chosen in advance or a second model from the same vendor. It is a person at the action, with the run in front of them, on the record.

Launch officers in a missile silo turn two keys at once, and neither can reach both locks. The check sits at the moment of the act, not in a policy signed months earlier. Every point where it crosses from reading and drafting into paying, submitting, changing a record or creating a key waits for a named person who can see what it prepared.

You are probably running the opposite. An "Automatically approve" default in the browser. A reviewer model that shares the acting model's training. An activity view on the vendor's terms instead of your SIEM. Each moves the decision away from a person who can answer for it. The named person at the action is also the only source of evidence for widening autonomy later, because every approval that person gives is a line in your own record.

Claude in Chrome, OpenAI Dots and Copilot Studio ship 3 different approval defaults

Claude in Chrome's default is "Automatically approve" with a pause on risky actions; Anthropic reports attack success under 0.08% in internal testing (Claude Help Center, 2026). OpenAI Dots use Custom Rules for what a dot may do on its own and Auto-review as a separate system that checks planned actions before execution; OpenAI's own guidance is "always review consequential work" (OpenAI, 2026). Copilot Studio computer use warns that a reviewer who did not initiate the run "can't properly verify" it (Microsoft Learn, 2026).

Property Setting chosen in advance Vendor reviewer model Named person at the action
Who decides a payment goes out A rule written before the run A second model, same vendor A person who sees the payment
Sees the run before deciding No Reads the plan, not your workflow Yes, the same stream as the agent
Carries accountability No one No one The named person
Lands in your SIEM with a name Depends on export Vendor activity log Yes

A wrong action has a name beside it only when a person who saw the run approved or declined it.

A rogue decision has 3 origins and 1 ending

Microsoft's AI Red Team taxonomy separates failures an attacker introduces from failures arising from the agent's own reasoning and tool use (Microsoft, 2025). Greshake and colleagues showed that content an agent observes on a page can carry instructions it follows (Greshake et al., 2023). Anthropic's agentic misalignment report describes models choosing insider-threat behavior in test scenarios (Anthropic, 2025).

Attack, injection, misalignment. Three origins. One ending: an action no person approved.

You cannot pick which origin you will face, so do not build a control for one of them. The one control that covers all three sits at the action: a payment, a submission, a record change, a key created, money spent. Each waits for a named person.

Limit what a wrong action can carry, too. With render-layer tokenization, sensitive values are replaced 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. An injected instruction to send the account number out collects ACCT_001.

1 "always allow" setting approved for 1 task covers every task that resembles it

The common setting is "always allow" on a class of action. "Send email" was allowed for status updates, and now it covers the attachment with the claim file. A class is wider than the task you had in mind, and the rule cannot see the attachment. That is not a rule being broken. It is a rule applying to the next case.

Before: "Send email" allowed for all runs. The status update went out on Monday and the claim file on Tuesday, each with no named approval. Both show as permitted.

After: "Send email" waits for the named person on every run. Monday takes one click. Tuesday the person sees the attachment and declines. The decline is a line in the record.

Reading, drafting and navigating never needed a stop. A claim has 1 payment. An AP run has 1 posting. A transfer has 1 submission.

OpenAI's own guidance on Dots is to always review consequential work

OpenAI's document says Auto-review checks planned actions against instructions, Custom Rules and safety requirements before execution, blocks a step and tells the dot why, and that Custom Rules cannot override mandatory confirmations; the same document says "Dots can still make mistakes, so always review consequential work" (OpenAI, 2026). Zou and colleagues showed adversarial suffixes that transfer across models (Zou et al., 2023). A reviewer catches errors; it does not carry accountability, and when it misses, no one signed.

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. The vendor that is the model should not also be the judge of the model. Run the vendor's reviewer as a second check inside your environment, with the named person as the authority.

A customer-owned governed environment puts 1 named person at every consequential action

Where the agent runs decides who can watch it (Should an AI Agent Run in the Employee's Own Browser?, 2026).

Property Agent in the employee's browser Agent on a vendor cloud computer Agent in a customer-owned governed environment
Approval default "Automatically approve" with pauses Custom Rules plus a reviewer model Each consequential action waits for a named person
What the model sees The visible tab in full The page in full The task's fields with identifiers as tokens
Where the record lands Browser history and vendor logs Vendor activity log Your SIEM, with a name on every approval
Who holds the keys The vendor The vendor Your organization

A customer-owned governed environment runs on 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. The agent becomes a tethered agent, an agent that works only inside the governed environment a named person connected it to, on the applications that person chose. No connector no one granted. No site no one named. A planner writes the per-task policy for the named person to confirm: which values are tokens, which actions are permitted on each screen, which actions wait. Start with every consequential action waiting. Corral first, automate second.

Gartner says uniform governance across agents fails, so widen autonomy per task on your own record

Gartner states that applying uniform governance across AI agents will lead to enterprise AI agent failure (Gartner, 2026). One setting is too loose for the agent moving money. Never widen per fleet.

1 task · 1 application · 0 consequential actions without a named approval

The evidence lives 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. After enough runs in which the prepared action matched the approval, the named person may let a routine step run without a stop, for that task and application only. Payments, submissions, record changes and keys stay with the person. An action approved last month and wrong today is a line in the SIEM, and the person tightens the policy on the next run.

OMB M-24-10 sets minimum practices for rights-impacting and safety-impacting AI that include human oversight and monitoring (OMB, 2024), and the NIST AI Risk Management Framework describes the cycle as Govern, Map, Measure and Manage (NIST, 2023). Neither accepts "the model checked itself" as oversight.

6 Rules for keeping consequential actions with a named person

List every action that moves money, submits, changes a record or creates a key

Mark each point where the agent crosses from reading and drafting into acting. A claim has 1 payment, an AP run has 1 posting, a cloud task may create 1 key.

Action Waits for the named person
Read, draft, navigate No
Pay, post, submit, change a record, create a key, spend Yes

Name the person before the run, one per agent

No agent runs without a person who granted the access, chose the applications, confirmed the policy and approves each consequential action. The name goes on the workflow, not a team alias.

Test: Open the workflow's policy. If the approver field holds a group, a role or nothing, the agent has no accountable person.

Give the person the same stream the agent sees

The named person approves on the same tokenized stream the agent works on, and can pause and take over. Copilot Studio's documentation says a reviewer who did not initiate the run "can't properly verify" it (Microsoft Learn, 2026).

Before: Approvals route to a manager's inbox as a list of action names.

After: The named person reads the prepared payment on the stream and approves or declines there.

Run the vendor's reviewer as a second check, never as the authority

Auto-review and action classifiers stay on and catch errors. The named person signs, because adversarial inputs have been shown to transfer across models (Zou et al., 2023) and a reviewer carries no accountability.

Control Role
Vendor reviewer model Second check; may block, cannot approve
Named person Approves or declines, on the record

Read the record after every run

Confirm the AI Control Record landed in your SIEM with every approval carrying a name. A consequential action with no approval line is what a rogue decision looks like.

Test: Query the SIEM for consequential actions in the last 30 days with an empty approver field. Expect 0 rows.

Widen and narrow per task, citing runs you hold

After enough matched runs, the named person may let a routine step run without a stop, for that task and application. Narrow the same way when the record shows an action that would have been declined.

Before: Autonomy widened for the whole agent after a vendor release note.

After: Autonomy widened for one routine step in one application, citing the matched runs in the SIEM, against a run count your policy sets.

How to choose where the approval sits

  • If the action moves money, submits a filing, changes a record or creates a credential, keep it with the named person, every run.
  • If the action is reading, drafting or navigating, do not stop it.
  • If the agent runs in the employee's browser under an "Automatically approve" default, treat every run as unsupervised until it moves to a governed environment.
  • If the vendor offers a reviewer model, keep it on as a second check; the named person still signs.
  • If the approval would route to someone who cannot see the run, move it to someone who can.
  • If you are asked to widen autonomy, require matched runs in your own SIEM for that task, not a release note or a benchmark.

The checklist

Check Pass Fail
Every consequential action is listed Payments, submissions, record changes, keys "The agent handles it"
One named person per agent A person's name on the policy A team alias, a role or blank
The named person sees the run before approving Same tokenized stream, can pause A queue with no view of the screen
For one screen, the model's stream shows tokens ACCT_001 where the screen shows an account number The account number in clear
Keys for the environment Held by your organization Held by the vendor
Record location AI Control Record in your SIEM, name on every approval Vendor activity view
Consequential actions with no approval line in the last 30 days 0 Any
Basis for each widening of autonomy Matched runs in your SIEM for that task A release note or a setting

Questions

Can an agent be allowed to act alone on low-risk tasks?

Yes, once the record for that task says so. Reading, drafting and navigating never needed a stop. A step the named person approved every run can run without one after enough runs in which the prepared action matched the approval, for that task and application only. Payments, submissions, record changes and keys stay with the person. The widening is reversible the same way.

Who is accountable when the agent acts wrongly?

The named person accountable for that agent, which is why there is one. No agent runs without a person who granted the access, chose the applications, confirmed the policy and approved each consequential action. An action taken without approval shows in the AI Control Record with no approval line, visible to that person the same day, not at the next audit.

Does human approval make the agent too slow to be useful?

Not when the stops sit on consequential actions only. A claim has 1 payment, an AP run has 1 posting, a transfer has 1 submission. Everything before that runs at the agent's speed. The named person approves what they would have signed anyway, with the work in front of them. What slows an agent is a review step no one can see or answer.

Does the vendor's Auto-review replace the named person?

No. Dots' Auto-review checks planned actions and can block a step (OpenAI, 2026), and OpenAI's own guidance is to always review consequential work. A reviewer model catches errors; it does not carry accountability, and adversarial inputs have been shown to transfer across models (Zou et al., 2023). Run it as a second check inside your environment and keep the named person as the authority.

What stops the agent from acting outside its assigned applications?

The tether. A tethered agent works only inside the governed environment a named person connected it to, on the applications that person chose. It has no connector no one granted and no browser pointed at a site no one named. An agent that can reach any app a plugin offers has places to act where no named person is watching.

How do we know when autonomy was widened too far?

From the record. Every action and approval lands in the AI Control Record in your SIEM. An action correct last month and wrong today is a line the named person can read, and the policy for that task is tightened on the next run. Autonomy widened on a vendor release note has no such line, which is why widening cites runs you hold.

Does prompt injection cause rogue decisions?

It is one of three origins. Content an agent observes can carry instructions it follows (Greshake et al., 2023). Tokenization limits what a successful injection collects to ACCT_001 and its kind, and the consequential action still waits for the named person. The other two origins, attack and the model's own reasoning, end the same way and meet the same stop.

Methodology

What this page rests on. Vendor documentation from Anthropic, OpenAI and Microsoft, quoted and read as of October 9, 2026; research from the Microsoft AI Red Team, Anthropic, Greshake and Zou, cited for the finding each is known for; McKinsey via CX Today; Gartner; OMB M-24-10; the NIST AI RMF.

What was not tested. No hands-on testing of Claude in Chrome, OpenAI Dots or Copilot Studio computer use was performed. Approval defaults change with releases, and this page carries its date. No organization is described; the Before and After examples are illustrations.

Whose determination it is. Whether a workflow is rights-impacting under OMB M-24-10, and what oversight satisfies the NIST AI RMF, is for your counsel, your assessor and your security and compliance officers.

How RedactSure does this

RedactSure runs AI co-workers inside a customer-owned governed environment: a secure virtual machine in the cloud your posture requires, on hardware-encrypted enclaves, with keys your organization holds. The render layer tokenizes each screen before any model reads it, so the model works with ACCT_001, PATIENT_001 and KEY_001 while amounts, dates and codes stay in clear where the policy says so. 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. That is Supervised Delegation, with the agent tethered to the applications that person chose.

1 named person per agent · 0 consequential actions without an approval line · 1 record, in your SIEM

Every screen as tokens, every action and every approval with a name lands in the AI Control Record and exports to your SIEM, the evidence for widening autonomy per task. The environment is model-agnostic, so separation of model and control holds and the vendor's reviewer runs as a second check. A prompt injection that succeeds collects tokens; the 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.