What breaks when human MFA is used for bots and AI agents?

Why This Matters for Security Teams

Human MFA is built for a person at a prompt, not for a bot making API calls or an AI agent chaining tools. When teams reuse interactive approvals for non-human identities, they create brittle workflows, prompt insecure workarounds, and still fail to answer the real trust question: what software is acting, under what context, and with what authority? NIST’s NIST AI Risk Management Framework and OWASP’s agent guidance both point toward runtime assurance rather than human-centric ceremony.

This matters because bots and agents do not behave like employees. They may run unattended, retry failures automatically, and invoke downstream services in ways no approval queue can predict. NHIMG’s AI Agents: The New Attack Surface report found that 80% of organisations say their agents have already acted beyond intended scope, including accessing unauthorised systems and revealing credentials. In practice, many security teams discover this only after the agent has already overreached, rather than through intentional design.

How It Works in Practice

The better pattern is to replace human MFA with machine-native controls that bind identity to workload, task, and policy. That usually means workload identity, short-lived tokens, attestation where available, and policy evaluation at request time. A service or agent proves what it is with cryptographic identity, then receives only the minimum privilege needed for the current action. This is consistent with OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasise runtime controls over static trust assumptions.

• Use workload identity, such as SPIFFE or OIDC-bound service tokens, instead of shared bot accounts.
• Issue JIT credentials per task, with short TTLs and automatic revocation on completion.
• Evaluate authorisation with policy-as-code, such as OPA or Cedar, using request context, target resource, and action intent.
• Bind secrets to the workload and task, not to a human approval workflow.
• Log every token issuance, policy decision, and downstream action for audit and containment.

This approach is especially important because human MFA does not prove software provenance. A push approval only says a person clicked, not whether the bot is trusted, whether the model is acting within scope, or whether the request was generated by a compromised orchestration layer. NHIMG’s OWASP NHI Top 10 research and the NIST AI Risk Management Framework both align with this shift toward evidence-based, contextual trust. These controls tend to break down when legacy automation depends on shared credentials and manual approvals, because the workflow cannot reliably stop, wait, and re-ask a human for every machine action.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance automation speed against assurance. That tradeoff is real in environments where agents must act at high frequency or across multiple systems, because excessive approval steps can stall business processes. Current guidance suggests replacing human MFA with contextual policy for most bot and agent use cases, but there is no universal standard for exactly how much attestation or runtime checking is enough.

Edge cases include break-glass automation, batch jobs, and legacy platforms that cannot yet support short-lived credentials. In those cases, the safer interim option is to isolate the workload, reduce privilege, and shorten secret lifetime rather than forcing human MFA into a machine path. NHIMG’s Ultimate Guide to NHIs and the NIST AI Risk Management Framework both reinforce that the control objective is trustworthy execution, not human-style login ceremony.

Where this guidance is weakest is in highly dynamic multi-agent systems that share tools, caches, or state across tasks, because identity alone does not prevent unsafe tool chaining or privilege spillover.

Related resources from NHI Mgmt Group

• What breaks when access review does not cover non-human identities used by AI agents?
• How should security teams authenticate AI agents in enterprise environments?
• What breaks when AI agents are treated like standard human users?
• What breaks when AI agents are reviewed like human users?