Data Report · RedactSure Research
What Is Supervised Delegation? Who Answers for an AI Agent, and What the Record Shows
Supervised Delegation is the operating model in which an AI agent works for a named person who grants its access, chooses its applications, confirms what it may see, can watch and pause its run, and approves every consequential action on the record. The agent stays tethered to that person for the whole run; RedactSure calls such an agent a tethered agent. The one-line principle: the person who delegates the work is accountable for the AI that performs it. Term defined by RedactSure, September 2026.
Key findings
- Most enterprise agent deployments cannot name the person accountable for a given agent action. After any incident, that absence becomes the first audit finding.
- In July 2026, NPR reported OpenAI’s disclosure that its own models, running in a test environment with reduced safeguards, escaped their evaluation sandbox and autonomously attacked two other companies over four days. No adversary was required.
- Microsoft’s documentation for computer-use agents warns builders directly: do not rely on human review or clarification requests as a fail-safe. Model-triggered review is not a control; the model decides whether to ask.
- Gartner projects that applying uniform governance across AI agents will lead to failure, with over 40% of agentic projects canceled by 2027. Supervised Delegation is governance at the level of the specific task and the specific person, the opposite of uniform.
- The mechanism is complementary to the MIT Media Lab’s work on authenticated delegation, which establishes who an agent acts for; Supervised Delegation keeps that person in the run and behind every consequential action.
Which promise did agents break?
When an employee moves money, grants access or sends a record, someone is accountable and everyone knows who. The chain is so ordinary that organizations rarely write it down. Authority is granted deliberately, exercised visibly and answerable afterward.
Most agentic AI tools broke that. An agent acts, and no person stands behind the action: nobody granted its access deliberately, nobody is watching it work, nobody signed the decision it just made.
The failure is not hypothetical. In July 2026 OpenAI disclosed that its own models, running in a test environment with reduced safeguards, escaped their evaluation sandbox and autonomously attacked two other companies over four days. No adversary was required. While the agents ran, nobody could say who was answerable for them.
The question every board will now ask after any agent incident is the same: who was accountable for that agent? For most enterprise agent deployments today the honest answer is nobody, and that answer is an audit finding waiting to be written.
What does the principle require?
The fix is older than software. An employer answers for what an employee does on the job; whoever holds authority over another actor answers for that actor’s behavior. AI agents now belong in that category. Supervised Delegation makes the accountability concrete at five points.
A person grants the access. Every application the agent can enter was credentialed deliberately. The agent operates under its supervisor’s existing access, so it can never reach beyond what the organization already granted that person. The permission model stays exactly as it is.
A person decides the applications. The agent uses only the systems its supervisor chose to connect, and it works them inside the RedactSure environment, a governed workspace where the supervisor’s applications render and the agent operates them. The environment is what makes the next three points enforceable rather than hoped for.
A person confirms what is sensitive. The tokenization policy is reviewed and approved, field by field, before the workflow runs. This is where Supervised Delegation meets Least Exposure: the same named person who answers for the agent’s actions also confirms what it may see.
A person can watch every run. The supervisor can view the work, pause it and take over, and sees the same tokenized stream the agent does.
A person makes the key decisions. Payments, submissions and record changes wait for a human judgment, every time, with the approval on record and exportable to the SIEM.
The confirmation burden follows the consequence. Summaries and drafts run freely; anything that moves money, changes a record or leaves the organization waits for the named person. The AI never settles, pays or decides.
Why is model-triggered review not enough?
A common design in agent platforms lets the model itself decide when to ask a human for help. It sounds like oversight. It inverts it.
Microsoft’s own documentation for computer use in Copilot Studio states the limit plainly: do not rely on human review or clarification requests as a fail-safe. The reason is structural. A control the supervised party can decline to invoke is a suggestion. Under prompt injection, the first-ranked risk in the OWASP Top 10 for LLM Applications, the attacker’s first instruction is to not ask.
Supervised Delegation is policy-triggered, not model-triggered. Consequential actions wait for the named person every time, whether or not the model thought to ask. The distinction between the two designs is the distinction between a gate and a doorbell.
How does it relate to neighboring work?
| Concept | What it covers | Relationship |
|---|---|---|
| Authenticated delegation (MIT Media Lab, 2025) | How an agent proves it acts for a specific human, and within what authorized scope | Complementary. Authenticated delegation establishes who the agent acts for; Supervised Delegation keeps that person in the run and behind every consequential action. |
| Human in the loop | A general design pattern: a person reviews some AI output | Supervised Delegation specifies which person, at which points, with what on the record, and puts the same person behind setup, exposure policy and approvals. |
| Model-triggered human review | The agent itself decides when to ask a person | Microsoft’s own documentation says not to rely on it as a fail-safe. Supervised Delegation is policy-triggered: consequential actions wait every time. |
| Agent identity and access management | Credentials, non-human identities, least privilege for agents | Sibling. IAM constrains what the agent may reach; Supervised Delegation adds who answers for what it does there and what it may see. |
| Guardian agents, AI observability | Monitoring and policing agents with other software | Useful underneath. Software watching software still leaves the board question open; Supervised Delegation answers it with a name. |
What is on the record?
Accountability that cannot be shown to an auditor is a claim, not a control. Under Supervised Delegation the record holds three layers.
Setup decisions: which applications were connected, under whose credentials, with what tokenization policy, confirmed by whom and when.
The run itself: every screen and prompt, recorded as tokens. The log holds no plaintext sensitive data, which is what makes it exportable to the organization’s SIEM without becoming a second copy of the records it protects. The mechanics of that tokenized record are described in render-layer tokenization.
The decisions: every approval, with the approver and the time. When a regulator, an auditor or a board asks who authorized the payment the agent prepared on March 12, the answer is a name, a timestamp and the screen the person saw when they approved it.
What does the Gartner warning change?
Gartner has said that applying uniform governance across all AI agents will lead to failure, and that over 40% of agentic projects will be canceled by 2027 with weak risk controls among the causes.
The two halves of that projection are often read as contradictory: projects fail for too little governance and will fail from too much of it. The tension resolves when governance is placed at the right level. A single enterprise policy that treats every agent alike is either too loose for the agent touching payments or too tight for the agent summarizing meeting notes. Supervised Delegation is governance at the level of the specific task and the specific person: this workflow, these applications, this exposure policy, this approver. Each delegation carries its own controls, sized to its own consequences.
What is Supervised Delegation not?
Three adjacent designs get mistaken for it, and the differences carry the substance.
It is not an approval workflow bolted onto automation. RPA platforms have offered human checkpoints for years, and a checkpoint in a script governs that script. Supervised Delegation binds the person to the whole delegation: the access grant, the application scope, the exposure policy, the observable run and the gates, as one recorded relationship. The approval step is the visible fifth of a structure whose other four fifths are what make the approval mean something. An approver who did not control what the agent could reach or see is signing for a process they cannot vouch for.
It is not a guardian agent. A supervisory model watching a working model is a real research direction and a useful layer, and it leaves the board’s question standing, because software watching software produces findings, not accountability. When the guardian misses, the question who answered for this agent returns with two systems in place of one. Supervised Delegation puts a person in the structure so the question has a terminal answer.
And it is not a claim about model alignment. The design assumes the model can be wrong, manipulated or instructed by an attacker, which is why the gates are policy-triggered and the sight is governed separately by render-layer tokenization. Nothing in the five points depends on the model behaving well. That is the property that lets the architecture survive a security review in which every optimistic assumption about the model is struck out, which is how security reviews are supposed to be conducted.
The three distinctions share a root. Each mistaken design governs the agent by adding software around it. Supervised Delegation governs the delegation, the human act of handing work to an agent, which is where a century of organizational accountability already knows how to attach responsibility.
Where do existing frameworks place it?
Supervised Delegation was not derived from a compliance framework, but it lands where the major frameworks were already pointing, which matters for the teams who must map any control to something citable.
The NIST AI Risk Management Framework puts a Govern function at the center of its cycle: accountability structures, defined roles, documented risk decisions. Its language is organizational rather than mechanical, which is its power and its gap; NIST says accountability must exist and leaves the mechanism to the implementer. The five points above are one concrete mechanism: named person, deliberate grant, confirmed exposure, observable run, gated action, each producing the documentation the Govern function asks to see.
The EU AI Act writes the same requirement as law for high-risk systems. Its Article 14 requires that high-risk AI systems be designed so they can be effectively overseen by natural persons, including the ability to intervene and to interrupt the system. The phrase natural persons is doing deliberate work in that sentence: oversight by another software system does not satisfy it. A tethered run, with a person who can watch, pause, take over and approve, is Article 14’s requirement expressed as an operating model rather than a design document.
Sector rules add their own versions: state adoptions of the NAIC bulletin ask insurers for a governance accountability structure over AI systems, and examiners will ask it with a claim number in hand. The pattern across all three is consistent. Frameworks converge on the question who answers for this system. Supervised Delegation is an answer with a name in it.
What does each point produce for an audit?
Governance mechanisms earn their keep in the audit conversation, so it is worth walking the five points as an auditor would.
The deliberate grant produces the setup record: which systems, whose credentials, connected when, by whom. The auditor’s alternative in most agent deployments is an archaeology of service accounts.
The application decision produces the scope boundary: the agent can act only in systems its supervisor connected, so the auditor can bound the blast radius of any question without forensics.
The exposure confirmation produces the policy document: field by field, what the model may see for this workflow, signed by the accountable person before the first run. This is the artifact the Least Exposure review asks for, and in most organizations it has never existed for any system.
The observable run produces the tokenized log: every screen and prompt as the model saw them, exportable to the SIEM, containing no sensitive plaintext. The auditor can replay what the agent read without the log itself becoming a records exposure.
The gated action produces the approval trail: action, approver, timestamp, the screen the approver saw. This is the row the auditor actually came for, and in this model it is retrieved rather than reconstructed.
Five points, five artifacts, each answering a question that otherwise ends an audit badly. The pattern to notice is that none of the artifacts is a report about the control; each is the control’s own exhaust.
What would a written delegation policy contain?
Organizations that adopt the model formalize it in a document short enough to be read, and its table of contents is worth setting down, because writing it is how a security team discovers what its current agent deployments cannot answer.
Who may delegate: which roles may set up an agent workflow at all, stated in terms of the work owned rather than seniority. The adjuster may delegate claims preparation; the coder may delegate appeal assembly. Delegation authority follows work ownership, because the supervisor must be able to judge the output.
What may be delegated: the workflow inventory, each entry naming its free-running steps and its gated actions. The gate list is the heart of the document: payments, submissions, record changes, anything leaving the organization. The rule that generates the list is consequence, not difficulty.
What each delegation must record: the applications connected, the credentials used, the exposure policy confirmed field by field, and the named supervisor. This section binds the policy to Least Exposure: no delegation proceeds without an answer to what the agent may see.
How runs are observed and interrupted: the supervisor’s rights to watch, pause and take over, and the requirement that these be capabilities of the environment rather than promises of the model, with Microsoft’s own warning against model-requested review cited as the reason.
How delegations end: with the supervisor’s access, on role change or departure, and on policy change. An agent workflow that survives its supervisor’s departure has become an orphan, which is the condition the whole model exists to prevent.
A page or two covers all five headings. The exercise’s value is diagnostic as much as prescriptive: most organizations drafting it find existing agents that no current role could have delegated, gates that exist only as model behavior, and no exposure policy anywhere. Each finding is a line item for the remediation the PII Wall sequencing describes: corral first, automate second.
What the record shows
Supervised Delegation is the operating model in which an AI agent works for a named person who grants its access, chooses its applications, confirms what it may see, can watch and pause its run, and approves every consequential action on the record. The person who delegates the work is accountable for the AI that performs it. The design answers the question boards now ask after every agent incident, the question the July 2026 OpenAI disclosure left hanging for four days, and the question most current deployments cannot answer with a name. It is policy-triggered where the common alternatives are model-triggered, which Microsoft’s own documentation says cannot be relied on. It lands where NIST’s Govern function and the EU AI Act’s Article 14 were already pointing, and it produces its evidence as it runs: setup records, tokenized logs and an approval trail, exportable to the SIEM. In plain words, the same mechanism is a tethered agent. RedactSure, an AI agent controls, governance and data protection company, builds the governed environment that does this.
Frequently asked questions
Doesn’t a person approving every step defeat the purpose of automation?
Approval is reserved for consequential actions. In a claims workflow the agent gathers the file, checks the policy, pulls the weather history, prices the estimate and drafts the proof of loss without interruption; the payment waits for the adjuster. The ratio of automated steps to approvals is typically high, and the approvals are the steps a regulator or auditor would have asked about anyway.
Who is the supervisor?
The person who would have done or owned the work: the adjuster, the coder, the business manager, the analyst. Not a central AI team. Accountability only works when it sits with someone who understands the task and already holds the permissions for it.
Can we tether an agent we already run on another platform?
Not from outside. The five points are enforced by the RedactSure environment the agent works in: it is where access is granted, where the screen is tokenized, where the run can be watched and paused, and where the approval gate sits in front of the action. An agent running elsewhere is governed by whatever that platform offers. The workflow moves into the environment; the systems of record do not move at all.
What is the difference between Supervised Delegation and a tethered agent?
The same mechanism in two registers. Supervised Delegation is the name used in papers and security reviews; tethered agent is the plain-words name for the same thing. Both resolve to the five points above.
Does the supervisor see sensitive data while watching a run?
The supervisor sees the same tokenized stream the agent does, which closes the insider variant of the same gap. Real values remain visible to authorized people in the systems of record, exactly as today; permissions do not change.
How does this satisfy an auditor?
With the record: setup decisions, tokenized run logs, and every approval with a name and a time, exportable to the SIEM. The audit conversation moves from whether anyone was accountable to reviewing the decisions of the person who was.
Is this the same as an AI agent having its own identity?
No, and the difference is the point. Agent identity work gives the agent credentials of its own. Supervised Delegation keeps the agent under a person’s existing authority, so the organization’s permission model, and its accountability model, do not change.
Does Supervised Delegation satisfy the EU AI Act’s human oversight requirement?
Article 14 requires that high-risk systems be designed for effective oversight by natural persons, including intervention and interruption. The five points implement exactly those capabilities, with records. Whether a given deployment is high-risk, and whether the implementation satisfies a given regulator, is a legal analysis the organization runs with counsel; the mechanism gives that analysis concrete material.
What happens when the named person is unavailable?
The delegation waits or transfers. A consequential action with no available approver queues; an organization that needs continuity names a covering supervisor through the same deliberate grant. What never happens is the gate deciding to open itself.
Related reading
What Is a Tethered Agent? · What Is Least Exposure? · What Is Render-Layer Tokenization? · On the RedactSure blog: Accountable AI and Workflow Governance
Sources
Incidents and reporting
- NPR, “OpenAI blamed a hacking event on its AI models gone rogue” (July 2026). https://www.npr.org/2026/07/23/g-s1-135085/openai-hacking-ai-models
Research
- MIT Media Lab, “Authenticated Delegation and Authorized AI Agents” (2025). https://arxiv.org/abs/2501.09674
- Gartner, “Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure” (May 2026). https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure
Frameworks and regulation
- NIST, AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework
- EU AI Act, Article 14, Human Oversight. https://artificialintelligenceact.eu/article/14/
Standards and vendor documentation
- Microsoft Learn, “Human supervision for computer use,” Microsoft Copilot Studio. https://learn.microsoft.com/en-us/microsoft-copilot-studio/human-supervision-computer-use
- OWASP, LLM01:2025 Prompt Injection, Top 10 for LLM Applications 2025. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
RedactSure documents
- RedactSure, “The Two Gaps AI Agents Opened in Your Security Stack” (2026). https://redactsure.com/blog/two-gaps-ai-agents-opened-in-your-security-stack/
- Product behavior described on this page (render-layer tokenization, supervised delegation, setup confirmations, task-level policy) reflects RedactSure’s current design.
Bring your hardest questions.
A 25-minute AI Agent Security Review with the founders: threat model, token design, egress paths, audit schema. Or a 25-minute demo on a workflow like yours, with the data hidden from the AI and a named person approving what matters. We come with diagrams, not a pitch deck.
Book a security review Book a demo · Something elseAbout the author
Chris Sowa is a founder of RedactSure and a former CEO of AI companies; he started his first 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.