EVIDENCE TRAIL
MFA on high-privilege agent identities
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The title "MFA on high-privilege agent identities" is Helmwart's normalised label for a pattern composed from human-auth standards (NIST SP 800-63B) and agentic-specific playbook guidance. The strongest verbatim upstream match is OWASP Agentic AI Threats & Mitigations v1.1, Playbook 4: "Deploy multi-factor authentication (MFA) for high-privilege AI accounts."
Last cross-checked against upstream sources: · 8 sources
References
Each entry shows what the source supports and what it does not prove.
OWASP Agentic AI — Threats & Mitigations v1.1, Playbook 4
Playbook 4: Strengthening Authentication, Identity & Privilege Controls — Step 1: Implement Secure AI Authentication Mechanisms (Proactive)
"Deploy multi-factor authentication (MFA) for high-privilege AI accounts."
Supports: Verbatim use of "MFA for high-privilege AI accounts" in an agentic context — the closest upstream wording match for this control's title. Located in the proactive playbook for T3 Privilege Compromise and T9 Identity Spoofing.
Does not prove: The sentence names MFA as one bullet among several (cryptographic identity verification, RBAC/ABAC, continuous reauthentication). It does not define what constitutes the second factor for a non-human identity, nor does it specify workload attestation or hardware-backed key material.
OWASP Agentic AI — Threats & Mitigations v1.1
§T9 Identity Spoofing & Impersonation / Agent Identity Compromise — Description
"Attackers exploit authentication mechanisms to impersonate AI agents or users to perform unauthorized actions under false identities. This includes the theft or misuse of a formal, persistent agent identity (e.g., Microsoft Entra Agent ID), enabling privileged, long-term API access that bypasses the agent's conversational interface and its guardrails."
Supports: Names the threat vector this control directly addresses: theft of a formal, persistent agent identity enabling long-term privileged access. Validates why a second factor bound to the credential issuance path reduces blast radius.
Does not prove: The T9 mitigation guidance ("Develop comprehensive identity validation frameworks, enforce trust boundaries, least privilege access and deploy continuous monitoring") does not explicitly call for MFA on NHIs — it prioritises behavioural profiling. MFA is the Playbook 4 recommendation, not the T9 table row.
OWASP Top 10 for Agentic Applications 2026
§ASI03: Identity and Privilege Abuse — Description
"Identity & Privilege Abuse exploits dynamic trust and delegation in agents to escalate access and bypass controls by manipulating delegation chains, role inheritance, control flows, and agent context; context includes cached credentials or conversation history across interconnected systems. In this context, identity refers both to the agent's defined persona and to any authentication material that represents it."
Supports: Establishes the threat landscape this control operates in. ASI03 maps one-to-one to T3 Privilege Compromise; the description explicitly includes "any authentication material (API keys, OAuth tokens, delegated user sessions)" as the attack surface, grounding why strong credential issuance (MFA/attestation) matters.
Does not prove: The ASI03 mitigations section does not call out MFA by name; they focus on scoped permissions, re-authentication on context switch, and automated revocation. MFA appears in the companion playbook (Playbook 4), not in the ASI03 mitigation list itself.
NIST SP 800-63B — Digital Identity Guidelines: Authentication and Lifecycle Management
§4.2 Authenticator Assurance Level 2 (AAL2) — opening normative requirement
"Proof of possession and control of two distinct authentication factors is required through secure authentication protocol(s)."
Supports: Canonical definition of multi-factor authentication at AAL2: two distinct factors required. This is the standard the Helmwart control names as its definitional anchor for MFA primitives. AAL3 (§4.3) extends this to hardware-bound authenticators, which is the model applied to agent workload attestation.
Does not prove: SP 800-63B addresses human subscriber authentication throughout; it contains no discussion of non-human identities, service accounts, or machine-to-machine authentication. The application of AAL2/AAL3 primitives to agent NHIs is an architectural extension Helmwart makes, not a claim SP 800-63B itself makes.
RFC 9470 — OAuth 2.0 Step Up Authentication Challenge Protocol
Abstract
"resource servers can use to signal to a client that the authentication event associated with the access token of the current request does not meet its authentication requirements."
Supports: Defines the IETF primitive for action-time step-up re-attestation — pattern 3 in the "How to deploy" section. When an agent bearer token is about to be used for a high-impact action, RFC 9470's insufficient_user_authentication error code and acr_values challenge trigger re-attestation before the action executes.
Does not prove: RFC 9470 targets OAuth 2.0 resource server / authorization server interactions for human users. It does not address workload-identity attestation or non-human principals. The step-up for workload re-attestation is an architectural extension of the RFC's mechanism.
SPIFFE/SPIRE Concepts — Workload Attestation
SPIRE Concepts — Workload Attestation section
"Workload attestation asks the question: "Who is this process?" … These properties are then compared against the information provided to the server when you registered the workload's properties using selectors."
Supports: Documents the mechanism behind pattern 1 in the "How to deploy" section. SPIRE's workload attestation — comparing discovered process properties against registered selectors before issuing an SVID — is the operative second factor for cluster-internal agent identities.
Does not prove: SPIFFE/SPIRE documentation does not describe this attestation as "MFA"; that framing is Helmwart's. The docs also do not address agentic AI specifically.
MITRE ATLAS AML.M0026 — Privileged AI Agent Permissions Configuration
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: The direct ATLAS cross-reference for this control. AML.M0026 addresses configuration of permissions for privileged AI agents, aligning with the workload-attestation and step-up patterns Helmwart specifies. Techniques AML.T0012 and AML.T0055 cited in the MDX are the adversary techniques this mitigation counters.
Does not prove: ATLAS pages are JavaScript-rendered and could not be fetched for verbatim text at cross-check time. No verbatim excerpt available; check https://atlas.mitre.org/mitigations/AML.M0026 directly to verify description text.
NSA / CISA — Careful Adoption of AI: Agentic AI Services
No verbatim excerpt pulled yet — open the original to verify the cited section.
Supports: Cited in the source MDX as recommending step-up authentication for high-privilege agents, §Privilege. If accurate, this is the strongest government-authority endorsement of the specific step-up pattern.
Does not prove: The CISA URL returned HTTP 403 at cross-check time; no verbatim excerpt could be retrieved to verify the §Privilege section reference or the exact recommendation wording. The publication date of April 2026 is within the plausible window but should be independently verified before treating this as a confirmed citation.