EVIDENCE TRAIL
Out-of-band verification for high-stakes data changes
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The OOB primitive is defined at federal-government grade in NIST SP 800-63B §5.1.3; the agentic-AI application is Helmwart's extension of that primitive to agent HITL approval gates for irreversible operations. MDX note: the frontmatter cites "OWASP NHI Top 10 NHI7 (Insufficient Authentication)" — the correct entry is NHI4:2025 (NHI7:2025 is Long-Lived Secrets); NHI4 does not name OOB as a recommended control and has been omitted from this trail.
Last cross-checked against upstream sources: · 7 sources
References
Each entry shows what the source supports and what it does not prove.
NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management
§5.1.3 Out-of-Band Authenticators — definition paragraph
"An out-of-band authenticator is a physical device that is uniquely addressable and can communicate securely with the verifier over a distinct communications channel, referred to as the secondary channel. The device is possessed and controlled by the claimant and supports private communication over this secondary channel, separate from the primary channel for e-authentication."
Supports: Canonical federal-government definition of the OOB primitive: "distinct communications channel … separate from the primary channel." The structural-independence rationale cited throughout the m-out-of-band-verify mitigation page derives directly from this definition.
Does not prove: SP 800-63B defines OOB as an authentication mechanism for identity verification, not specifically for AI agent action approval. The application to agentic HITL gates is Helmwart's extension, not SP 800-63B's own framing.
NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management
§5.1.3.1 Out-of-Band Authenticators — channel separation requirement
"The device does not leak information from one channel to the other without the authorization of the claimant."
Supports: Specifies the structural guarantee the OOB control relies on: the attacker who controls the primary channel (the agent's UI) cannot read or write the secondary channel. This is the exact security property that makes OOB valuable for AI-powered invoice-fraud scenarios.
Does not prove: The requirement is stated as a property the device must maintain; it does not prescribe how to verify the requirement holds in practice, nor does it address SIM-swap or SS7 attacks against the PSTN as a secondary channel.
OWASP Agentic AI — Threats & Mitigations v1.1
§T15 Human Manipulation — Scenario 1: AI-Powered Invoice Fraud
"Scenario 1: AI-Powered Invoice Fraud – An attacker exploits Indirect Prompt Injection (IPI) to manipulate a business copilot AI, replacing legitimate vendor bank details with the attacker's account. The user, trusting the AI's response, unknowingly processes a fraudulent wire transfer."
Supports: Verbatim statement of the named scenario that m-out-of-band-verify directly closes. Confirms that the threat model (IPI substitutes bank details; user trusts agent UI; fraudulent wire transfer executes) is an upstream-recognised scenario, not a Helmwart invention.
Does not prove: The T15 table-row mitigation (v1.0 text: "Monitor agent behavior … validate manipulated responses using guardrails") does not name OOB verification. The out-of-band control is not explicitly listed as a T15 mitigation in the v1.1 document; the connection is inferred from scenario closure, not direct citation.
OWASP Top 10 for Agentic Applications 2026
§ASI09 Human-Agent Trust Exploitation — Common Examples of the Vulnerability §2
"Missing Confirmation for Sensitive Actions: Lack of a final verification step converts user trust into immediate execution. Social engineering can turn a single prompt into irreversible financial transfers, data deletions, privilege escalations, or configuration changes that the user never intended."
Supports: Names the absence of a "final verification step" as a first-class vulnerability for irreversible financial transfers — the same action class m-out-of-band-verify targets. Validates that requiring an independent confirmation before irreversible actions is recognised upstream as a mitigation gap.
Does not prove: Does not name OOB specifically as the verification mechanism. The ASI09 mitigations name "multi-step approval or human in the loop" (§Mitigation 1) rather than a structurally independent channel. Helmwart's OOB specialisation is stricter than the ASI09 generic guidance.
OWASP Top 10 for Agentic Applications 2026
§ASI09 Human-Agent Trust Exploitation — Example Attack Scenarios §7
"Fraudulent payment advice: A finance copilot, poisoned by a manipulated invoice, confidently recommends an urgent payment to attacker-controlled bank details. The manager, trusting the agent's expertise and explanation, approves the transfer without independent checks."
Supports: Verbatim upstream scenario naming the absence of "independent checks" as the proximate cause of the fraud. Directly supports deploying an independent-channel (OOB) confirmation as the missing control.
Does not prove: The scenario uses the phrase "independent checks" generically; it does not prescribe OOB as the mechanism. Other independent-check patterns (dual-control, risk-engine review) would also address this scenario.
Stripe — 3D Secure (3DS) Authentication
Stripe Docs — 3D Secure overview
"3D Secure (3DS) is an authentication protocol that adds an additional security layer to card transactions … When 3DS is activated, the issuing bank might request cardholders authenticate — typically through a familiar security prompt like a password, one-time code sent to their mobile device, or biometric verification."
Supports: Production-grade OOB pattern for payment actions: "one-time code sent to their mobile device" is the SMS/push OOB primitive applied to exactly the payment-authorisation scenario the mitigation targets. Demonstrates that this is shipping infrastructure, not theoretical.
Does not prove: Covers card-issuer-driven OOB for cardholder authentication, not the agentic-AI variant where the agent proposes the payment. The integration point (agent HITL gate vs. payment network 3DS challenge) is architecturally distinct.
MITRE ATLAS AML.M0026 — Privileged AI Agent Permissions Configuration
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: The closest ATLAS mitigation to this control: defines that AI agents with elevated privileges must be hardened with step-up auth, scoped credentials, and explicit review before privileged actions execute. OOB verification is one concrete implementation of the "step-up auth" and "explicit review" requirements.
Does not prove: ATLAS AML.M0026 page returned 404 on live fetch at cross-check date (2026-05-29); description sourced from local Helmwart ATLAS catalogue (src/lib/handbook/atlas-mitigations.ts). Does not use the phrase "out-of-band" and does not prescribe a specific verification channel.