Human-in-the-loop setups for AI agents are usually specified in terms of who approves; the channel question is answered inconsistently, when it's answered at all. An agent (or a stolen token) that can open a session, run a command that trips a review, and approve that review—all on the same credential, all on the same channel—has effectively approved itself. The fix isn't a second person. It's a channel the requesting agent can't reach.
The threat isn't a rogue admin
Picture the setup a lot of teams already have: an AI agent has a superuser-scoped credential so it can operate infrastructure without pinging a human for every step. It opens a session, runs a command that a policy engine flags as needing review, and then—using the same credential, on the same channel—clicks approve on its own request. No human touched any part of it.
That's not a hypothetical edge case. It's the default behavior of any AI agent approval workflow that checks identity (is this account allowed to approve things?) without checking channel (is this approval arriving through a channel the agent's credential can't reach?). If the answer to "who can approve" is "any account that already holds approve permission," and the agent's credential holds that permission, the approval step is decorative. A leaked API token does the same thing with no agent involved at all—it requests, then rubber-stamps, end to end, on one stolen credential.
Notice what this threat model explicitly isn't: a human admin abusing their own judgment. A superuser approving their own team's routine work is normal and shouldn't require a second person standing over their shoulder. The problem is narrower: don't let the same execution path both ask the question and answer it.
Production monitoring coverage is still limited, which is why the approval gate's own integrity matters: Gravitee's 2026 State of AI Agent Security report, a survey of 750 senior technology leaders in the UK and US, found that mean monitoring coverage across production AI agents is just 52%, and 54% of organizations have experienced or suspected an AI agent security or data-privacy incident in the past 12 months.
Channel separation, not person separation
The primitive Alpacon uses against the agent-and-token version of this is simpler than a two-person rule: an execution channel—an agent's CLI, an API token, a service token—can never be an approval channel, so an agent or a leaked token cannot approve its own request. Only a registered approval channel—the web console or Slack—can move a held action into "approved."
The distinction that makes this work is that the check runs on the channel, not on a guess about whether a human or an agent is driving. The system derives which channel a given credential is using at the moment an approval is redeemed—the application context for an interactive session, the token type for a programmatic one. It checks that channel against a per-workspace, configurable list of registered approval channels, fail-closed: a new channel can't approve until it's explicitly registered.
The channel check never tries to infer "is this a human acting" from behavior, because that's exactly the kind of signal an agent (or an attacker driving one) can imitate. Deriving the channel from the credential itself, rather than asserting it, is what makes the check uniform whether the thing driving the requesting side is a person or a script—and it's also what makes the exclusion hold regardless of how many tokens of that credential class an agent mints. A rule that just hides the approve button on one interface still leaves every other surface that shares the credential able to call the approve endpoint directly; a rule keyed to the credential class itself doesn't have a surface it forgot to lock down.
Registry membership alone isn't the whole guarantee, either: each channel still has to attest a live human its own way—the web console through the deliberate approve action in the UI, paired with step-up presence; Slack through its signed request and the workspace's identity mapping. The channel check sits inside Alpacon's execution control layer: a command that runtime risk assessment scores as neither clearly safe nor clearly forbidden can be held for a human before it runs, and whether that hold is enforced or just logged is a per-workspace policy choice on the risk lane's own default posture, monitor-and-record. The channel check above is a separate guarantee: whatever the risk lane's posture, the execution credential that tripped the hold is never the one that can clear it.
The rule above is deliberately a channel rule, not a person rule. The same human can request an action from their CLI and approve it from Slack—that's fine, and it's what keeps a single-admin workspace functional; you don't need to hire a second admin just so approvals work. The baseline is channel separation, not person separation—person-level dual control (approver and requester must be two different people, true two-person control) is a committed design layered on top, not something you can turn on today.
What this rule doesn't cover
The channel rule governs runtime access decisions—opening a session, expanding scope mid-session, approving a privileged command in the moment. It doesn't cover policy changes, like editing who's allowed to approve in the first place. That's a related but separate surface.
What the standards actually say
Neither NIST publication cited here was written with agents in mind—they address human operators and service accounts. But the closest control IDs are worth naming precisely—mostly to show which parts of this they don't cover.
NIST SP 800-63B-4—part of the SP 800-63-4 suite that superseded SP 800-63-3 in July 2025—defines an out-of-band authenticator as "a physical device that is uniquely addressable" and communicates over "an independent communications channel." It works from the same instinct for authenticators: a secondary channel that can't leak into the primary one. The channel rule here is weaker—it separates credential classes, not hardware.
NIST SP 800-53 AC-5 (Separation of Duties) and AC-3(2) ("Enforce dual authorization for [Assignment: organization-defined privileged commands and/or other actions]") are person-separation controls—they map to what person-level dual control, a committed design layered on top, would satisfy, not to the channel baseline this piece is about. For re-authentication at the moment a privileged action executes, the fitting control is IA-11 (Re-authentication).
The OWASP Top 10 for Agentic Applications 2026 comes at the problem from the other side: "Least-Agency" is advice "to avoid unnecessary autonomy" because "deploying agentic behavior where it is not needed expands the attack surface without adding value"—a call to grant less autonomy, not a rule about who redeems an approval. The Cloud Security Alliance's agentic IAM paper frames a related instinct in credential terms: just-in-time, action-scoped credentials that expire automatically rather than standing grants an agent (or an attacker who compromises one) can quietly reuse.
What's still open
What's still open is scoping who is authorized to click approve—narrowing it to the specific resolved approver for a request. That's a committed design, not yet built.
One limit is worth naming: a human who hands an agent their live browser session has handed over an approval channel, and no channel rule catches that—it's credential handover, the same as any other.
The takeaway
A human-in-the-loop control that only checks identity is a rubber stamp with extra steps if the same credential can request and approve. The fix that actually holds is structural: bar execution channels from ever approving, derive the channel from the credential rather than guessing at the actor, and treat person-level dual control as a committed design layered on top—not the load-bearing part.
FAQ
Does out-of-band approval mean the requester and approver must be different people? No—that's a separate, stricter control. The baseline here is channel separation: the same human can request an action from their CLI and approve it from Slack, which is what keeps a single-admin workspace functional. Person-level dual control, where requester and approver must be two different people, is a committed design layered on top, not something available today.
What does this rule not cover? It governs runtime access decisions—opening a session, expanding scope mid-session, approving a privileged command in the moment. It doesn't cover policy changes, like editing who's allowed to approve in the first place, and it doesn't catch a human handing an agent their own live, already-authenticated browser session—that's credential handover, the same as any other.
