DISC InfoSec blog

Where Does the Human Sit Relative to Execution?

Outside the loop, in it, on it, or alongside it? The position determines what evidence exists, which risk tiers are defensible, and whether Article 14 oversight is real or theatre.

Someone put a question to me recently that I thought was better than most of the governance frameworks I read: is the human positioned outside the execution process, or integrated into it at some point?

The phrasing they reached for was “perpendicular to execution,” and I want to keep that metaphor because it’s more precise than it looks. A perpendicular line crosses another at exactly one point. That is a genuinely different arrangement from running alongside, and different again from never intersecting at all. Where the human’s line meets the execution path — once, continuously, or never — determines almost everything that matters afterwards.

And it determines it in a way most organizations haven’t noticed: position determines what evidence exists. Which, as I argued in the post on ISO 42001 evidence, is the difference between having controls and being able to demonstrate control.

Underneath the question is the distinction that governance conversations routinely collapse: oversight is not control. Watching is not the same as being able to stop. Reviewing afterwards is not the same as authorizing beforehand. The frameworks care about the difference even when the org chart doesn’t.

---

Four positions, and one that pretends to be a position

Position	What the human actually does	Latency added	Evidence it produces	Defensible for
Outside execution (post-hoc)	Reviews, audits, samples after the fact	None	A review record. No authorization record	Tier 1 assistive work
Perpendicular (in the loop)	Approves this specific action before it executes	Human-scale, per action	Approval bound to actor, tool, resource, parameters, time	Tier 3–4 irreversible actions
Parallel (on the loop)	Monitors live, can interrupt, doesn’t approve each action	Near-zero	Monitoring records, intervention events, tested stop capability	Tier 2–3 at volume
Alongside (co-execution)	Works the task jointly, continuously	Continuous	Session records, joint attribution — often murky	Skilled analytical work
Nominally in the loop	Clicks approve on everything	Human-scale, wasted	An approval record that proves nothing	Nothing

That last row is the one to sit with, because in my experience it’s the most common arrangement in production. An approval step exists. The approval rate is effectively 100%. The human has neither the information nor the time to disagree. The organisation believes it has an in-the-loop control; what it actually has is an accountability sink — a place to assign blame, with no capacity to prevent harm.

“Oversight watches the action; control owns the gate.”

• Oversight = a human observes what the AI/agent is doing and can intervene if something goes wrong.
• Control = a defined decision point that determines whether an action is allowed to proceed.

For example:

AI agent wants to send $50,000 to a vendor.

Oversight: A human watches the agent execute the transaction and is supposed to stop it if necessary.

Control: The system says, “Transactions above $10,000 require human approval before execution.” The transaction cannot proceed until the gate is passed.

“Continuous collaboration during execution degrades into oversight theater at volume”

This is the most important—and controversial—part.

The argument is that if you require humans to continuously watch and collaborate with AI agents while they are executing thousands of actions, humans eventually become passive observers.

They are technically “in the loop,” but aren’t really making meaningful decisions.

That’s “oversight theater.”

The human is present, but the AI is effectively making the decisions.

“The human is present but not deciding.”

This means human presence ≠ meaningful human control.

A person clicking Approve on hundreds of AI-generated actions without understanding each decision isn’t meaningful oversight.

“Control sits perpendicular”

This is a conceptual way of saying that control should not necessarily be embedded in every moment of execution.

Instead, controls should intersect the execution process at defined decision gates:

AI/Agent → Action → CONTROL GATE → Execution

For example:

• Low-risk action → automatically proceed
• Medium-risk action → additional validation
• High-risk action → human approval required
• Prohibited action → blocked

Then:

“The gate before it ships, the audit after.”

Before execution, controls prevent unacceptable actions.

After execution, audit/evidence determines what happened, whether the control worked, and whether the system needs improvement.

Where I would challenge the statement

I wouldn’t interpret this as “humans shouldn’t collaborate continuously with AI.”

For high-risk or highly autonomous AI systems, continuous human involvement can absolutely be necessary.

The better principle is:

Don’t confuse human presence with human control.

Human presence: A person monitors a dashboard, reviews alerts, receives AI outputs, or is technically “in the loop.” Human oversight: A person can observe what the AI is doing and intervene if necessary. Human control: The person has real authority and capability to approve, reject, stop, modify, or reverse the AI’s action before or after it creates consequences.

A mature AI governance model should combine:

Preventive controls + risk-based human decision points + monitoring + post-action assurance.

That’s particularly relevant to agentic AI: the question isn’t simply “Is a human watching?” but “At which points does the human actually have authority to stop, modify, or authorize the action?”

That distinction is very close to the human-oversight issue which I’ve been exploring in my AI governance work.

---

Three tests for where you actually are

Your policy says where the human is supposed to sit. These tests establish where they sit.

1. The intervention test. Can the human stop the action mid-flight — not stop the next one, stop this one — and has that path been tested end to end? EU AI Act Article 14 sets the bar for high-risk systems as a demonstrated capability to intervene, interrupt, and disregard output. Note that all three verbs are active. A human who can only decline the next invocation is outside execution, whatever the diagram says. And an untested stop capability is an assumption: recent surveys put the share of organizations able to automatically terminate a misbehaving agent’s access at roughly a fifth, with a meaningful proportion of those in production never having tested the path.

2. The information test. Does the human have what they’d need in order to disagree? If the interface presents a recommendation and an approve button, the human is a signature, not a control. Real in-the-loop oversight requires the inputs, the alternatives considered, the confidence or uncertainty, and the consequence of proceeding. This is where explainability stops being an ethics topic and becomes an oversight prerequisite — a decision offered without an explanation can’t be meaningfully refused.

3. The consequence test. What happens when the human says no? If the process stops, they’re in the loop. If the request routes to someone else, gets retried until approved, or proceeds after a timeout, they’re decoration. The timeout case deserves special attention: a system that executes when approval times out has converted its human control into a delay. Fail closed, or don’t claim the control.

---

The problem with in-the-loop that nobody designs for

Assume you’ve built a real approval gate. There’s a decay problem, and it’s psychological rather than technical.

Humans are poor at maintaining vigilance while approving a high volume of mostly-correct outputs. The approval rate drifts toward 100% not through negligence but through calibration — if the last four hundred were fine, the four hundred and first gets less scrutiny. Add deadline pressure and the drift accelerates. This is the same pattern that gave us alert fatigue, arriving in a context where the consequence of a rubber stamp is an executed action rather than an ignored ticket.

Which produces a governance requirement most programmes miss entirely: instrument the oversight layer itself. Track approval rates over time, time-to-approval, approval bypass attempts, elevated privilege usage, and any change in approval behaviour by approver. Oversight degrades quietly — nobody files a ticket saying “I’ve started rubber-stamping” — and if you aren’t measuring the control’s effectiveness, you’ll discover its decay during an incident review.

The related design implication: don’t put humans in the loop for high-volume routine actions. It doesn’t work, it costs latency, and it manufactures false assurance. Reserve in-the-loop for the genuinely consequential, and use deterministic policy enforcement for everything else. A gate a human passes four hundred times a day is not a gate.

---

Matching position to risk tier

Using the tiering model from the agentic governance post — tier by maximum action impact, not typical impact:

• Tier 1, assistive. Outside execution is appropriate. Post-hoc review, sampling, periodic audit. Nobody should be approving draft summaries.
• Tier 2, controlled action. On the loop. Real-time monitoring, tested interrupt, automated rollback. Approval per action would be waste.
• Tier 3, privileged autonomous. On the loop as standard, in the loop for the consequential subset. This is where the split matters: same agent, different positions depending on the action class.
• Tier 4, high-impact or irreversible. In the loop, no exceptions, with the approval bound to the exact action and step-up authentication for the top of the range. Payment initiation, privilege changes, bulk deletion, regulated disclosure.

The important move is that position is a property of the action, not of the agent. An agent that files tickets and can also delete a production table needs both arrangements simultaneously — on the loop for the routine path, in the loop for the destructive one. Organizations that assign a single oversight posture per agent end up either strangling routine work or leaving the destructive path unguarded, and usually both.

---

The regulatory consequence people miss

Position isn’t only a governance choice. In two places it changes which rules apply to you.

California’s ADMT regulations. Advisory tools — systems producing recommendations, scores, or analysis for a human decision-maker — are excluded from the ADMT definition, provided there’s genuine human involvement in the final decision. CPPA staff testified during rulemaking that this narrowing reduced coverage to roughly 10% of CCPA-covered businesses. So the difference between a system that informs a human decision and one that makes it can look nearly identical in a product demo and land in entirely different regulatory buckets. But “genuine” carries the weight, and the three tests above are how a regulator will probe it. Build the advisory architecture deliberately if you’re relying on that boundary, and document the reasoning. (Not legal advice — run scoping decisions past counsel.)

EU AI Act Article 14. For high-risk systems, oversight must be a demonstrated capability, and Article 26 puts deployer obligations alongside it: competent staff, monitoring, incident notification, log retention of at least six months. Post-hoc review does not satisfy Article 14 for a high-risk system, regardless of how diligent the reviewer is. If your human sits outside execution on a high-risk system, that’s not a thin control — it’s a missing one.

---

The speed tension, and how it resolves

Here’s the objection to everything above, and it’s a serious one. My last two posts argued that autonomous offensive loops operate at machine speed and that human-in-the-loop defence cannot hold against them. Article 14 demands intervention capability. Machine speed demands the human step out of the execution path. Both can’t be satisfied by putting a person in front of every action.

The resolution is to change what the human does, not how fast they do it. The human moves from executing the decision to specifying and authorising the decision class in advance:

• Define action classes with hard bounds — what may be done autonomously, to what scope, up to what magnitude, within what window.
• Pre-authorise those classes explicitly, with a named approver and an expiry date.
• Enforce the bounds with a deterministic policy service the model doesn’t control.
• Route anything outside the pre-authorised envelope to a human, synchronously.
• Preserve a tested capability to interrupt and revoke, exercised at machine speed by the policy layer and available on demand to the human.

That’s human-on-the-loop with teeth, and it satisfies both constraints because the human’s authorising act happens once, in advance, deliberately — rather than four hundred times a day under time pressure. It’s also the shape of every mature control regime we already accept: a trader has limits rather than per-trade sign-off; a surgeon has protocols rather than a supervisor approving each incision.

Which is the same principle running through everything I’ve written in this series. When I audited a client’s MCP Governance Standard and produced a v1.1 redline with 27 changes, nearly all of them reduced to one idea: authority must be bound to a specific action rather than held ambiently by a component. Pre-authorized action classes are that idea applied to human oversight. The human’s authority attaches to a defined class of action, with a boundary and an expiry, rather than floating as a general sense of being in charge.

---

Five design rules

1. Assign position per action class, never per agent. One agent, several postures.
2. Fail closed. If classification, policy lookup, approval validation, or audit logging fails, nothing executes. A timeout is not an approval.
3. Bind the approval to the exact action — actor, tool, target resource, normalised parameters, timestamp, expiry. “Yes, send the email” is redirectable between approval and execution; “yes, send this email to this recipient” isn’t.
4. Give the human what they’d need to refuse. Inputs, alternatives, uncertainty, consequence. An approve button with no context manufactures liability rather than control.
5. Measure the oversight layer. Approval rates, latency, bypass attempts, behavioural drift by approver. Review it at management review, not after an incident.

---

What to do in the next 30 days

1. Map every agent action class against the four positions. Write down where the human actually sits, using the three tests — not where the policy claims.
2. Find the nominally-in-the-loop steps. Any approval running near 100% is either unnecessary or broken. Decide which, and either remove it or fix the information available to the approver.
3. Test one intervention path end to end and record how long it took. That single artifact tells you whether your Article 14 posture is real.
4. Check the timeout behaviour on every approval gate. If any of them proceed on timeout, that’s your most urgent fix.
5. Instrument approval rates so the drift is visible before it matters.

The question the whole thing turns on is worth keeping in the room whenever an agent design gets discussed: not is there a human involved, but at which point does the human’s line actually cross the execution path — and what happens there if they say no?

human oversight AI execution, human in the loop vs on the loop, EU AI Act Article 14, ADMT advisory tool, automation bias, agent approval gate, ISO 42001

---

Work with DISC InfoSec

DISC InfoSec helps B2B SaaS and financial services organisations design human oversight that holds up to an auditor and a regulator — agent inventories and risk tiering, oversight posture per action class, approval architecture, kill-switch and intervention testing, ADMT and Article 14 scoping support, and the evidence architecture that maps to ISO/IEC 42001, NIST AI RMF, and EU AI Act Articles 14 and 26.

I led ShareVault through ISO 42001 Stage 2 certification on the first audit attempt as the internal practitioner, served as internal auditor, and authored their MCP Governance Standard.

Readiness path: free 15–20 minute readiness call → ISO 42001 gap assessment or ISO 27001 gap assessment → 7–10 day Quick-Start → full implementation and certification support.

DiscInfoSec — Principal Consultant, DISC InfoSec (Deura Information Security Consulting LLC), Petaluma, AICP, CISSP, CISM | ISO/IEC 42001 & ISO/IEC 27001 Lead Implementer | PECB Authorized Training Partner

📅 calendly.com/hd-deurainfosec 📧 info@deurainfosec.com 📞 (707) 998-5164 🌐 deurainfosec.com

---

References

• Regulation (EU) 2024/1689 (EU AI Act) — Art. 14 (human oversight), Art. 26 (deployer obligations)
• CPPA ADMT regulations under CCPA/CPRA — advisory-tool scope exclusion
• ISO/IEC 42001:2023 — Clause 5.3 (roles), 9.1 (monitoring), 9.3 (management review); Annex A responsible-use and human-oversight controls
• NIST AI RMF 1.0 (NIST AI 100-1) — GOVERN, MANAGE functions
• OWASP Agentic Security Initiative; OWASP AI Agent Security Cheat Sheet
• Kiteworks 2026 Data Security and Compliance Risk Annual Survey; Gravitee State of AI Agent Security 2026

When AI Hacks At Machine Speed, Can Humans Still Defend The Network?

Tags: AI execution, alongside the execution, Human control, Human in the loop, Human oversight, Parallel on the loop, Perpendicular in the loop