AI identity models need attestation, not human MFA rituals

At a glance

What this is: This is an analysis of why human MFA patterns do not fit AI identity, and why delegation plus multi-attestation is presented as the better trust model for non-human actors.

Why it matters: IAM teams need to separate human authentication from AI access governance so they do not create borrowed-credential exposure, brittle approvals, and misleading identity boundaries for autonomous or workload-based access.

Context

AI identity governance fails when teams treat non-human actors as if they were people. Human MFA is designed to prove a person’s presence at login, but AI systems need access patterns that can be verified continuously at runtime rather than anchored to a single interactive authentication event.

The governance gap is not just operational convenience. It is the mismatch between a human authentication model and a machine access model, where delegation, runtime evidence, and short-lived credentials matter more than repeated login prompts.

For IAM, PAM, and NHI programmes, the question is whether access decisions are being made around the identity type actually in use. When AI agents or workloads are forced into human-style authentication, the result is usually borrowed credentials, persistent access, and ambiguous accountability.

Key questions

Q: How should security teams govern AI access without forcing MFA on machines?

A: Treat AI as a separate identity class. Use human approval for delegation, then issue a machine identity with scoped access, short lifetime, and runtime evidence requirements. That preserves accountability without requiring the AI to impersonate a person or inherit a human authentication workflow.

Q: Why do human authentication controls create risk when applied to AI systems?

A: They create risk because they assume a person is present to complete login, own the credential lifecycle, and remain accountable for the session. When AI borrows that path, the result is often persistent access, weak attribution, and unclear governance over who or what is acting.

Q: What breaks when an AI system uses borrowed user credentials for CMMC-scoped work?

A: Borrowed credentials break attribution, least-privilege review, and identity-bound audit evidence. The AI activity appears to come from the human user, which makes it difficult to prove what the system accessed, why it had access, or whether the permissions were appropriately limited for the task.

Q: What is the difference between delegated agent access and impersonation in AI systems?

A: Delegated access keeps both the user and the acting agent visible in the token chain, while impersonation makes the agent indistinguishable from the user. Delegation is usually the safer pattern because it preserves attribution, supports per-hop authorization, and keeps an audit trail intact. Impersonation can hide the actor, which weakens forensics and accountability after an incident.

Technical breakdown

Why human MFA breaks for AI access

MFA assumes a human subject who can interact with a challenge, recover from friction, and manage a credential lifecycle around periodic login. AI and workload identities do not behave that way. They need access that can be established, scoped, and revoked at runtime without pretending the actor is a person. When teams force AI through human authentication, they often create shared or borrowed credentials, which weakens attribution and makes lifecycle control harder. The issue is not whether MFA is strong for humans. The issue is that it is the wrong trust primitive for a non-human identity.

Practical implication: Separate human authentication flows from AI access paths so non-human actors are governed as identities in their own right.

What multi-attestation proves in an AI identity model

Multi-attestation is a trust model that verifies what the AI system is, not who a person says it is. That means evidence such as code integrity, origin, supply chain provenance, hardware roots of trust, and orchestration context can be combined to support delegated access. This is materially different from MFA because the trust signal is runtime evidence about the system’s state and lineage, not a one-time human login event. In identity terms, attestation becomes the basis for asserting that an AI is the expected workload or agent before access is issued.

Practical implication: Design AI access decisions around verifiable runtime claims rather than reusing human authentication controls.

How delegation changes the access boundary

Delegation lets a human authorize a task while the AI operates under its own identity and permission scope. That matters because it avoids long-lived human tokens and reduces the temptation to let AI impersonate the user. In practice, delegation shifts the security boundary from human login to task-scoped authorization, where short-lived credentials can be minted only after fresh proof. The control challenge is then governance of the delegation relationship itself, including scope, duration, and revocation. Without that, delegation can become another form of persistent access in different clothing.

Practical implication: Define delegation scope, lifetime, and revocation conditions before allowing AI systems to act on behalf of people.

Threat narrative

Attacker objective: Obtain durable, poorly governed access by exploiting identity boundaries that were designed for humans rather than non-human actors.

1. Entry occurs when an AI is granted access by borrowing a human authentication path instead of using its own identity model.
2. Escalation follows when persistent or long-lived tokens extend the AI’s access beyond the task that originally justified it.
3. Impact is the loss of clear accountability and the creation of broader-than-intended access that is hard to review or revoke cleanly.

Breaches seen in the wild

• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Human MFA is a borrowed control when the actor is an AI system. MFA was designed around human interaction, stable users, and credential lifecycles that assume a person can complete the login ceremony. When applied to AI, it often forces borrowed human credentials into non-human workflows, which blurs ownership and widens the access boundary. The implication is that identity governance must stop treating AI access as a human authentication variant and start treating it as a distinct identity class.

Multi-attestation creates a more accurate trust boundary for AI than login rituals do. Code integrity, runtime context, and provenance are the signals that matter when the actor is a machine behaving at runtime. That is why attestation is not a cosmetic replacement for MFA but a different proof model altogether. It aligns access issuance with what the system is actually doing and prevents identity decisions from being anchored to person-centric assumptions.

Short-lived delegated access is the governance pattern that follows from this model. Once AI is granted its own identity path, persistent human tokens become harder to justify and easier to abuse. The field should expect stronger emphasis on task-scoped authorization, runtime proof, and explicit revocation boundaries. Practitioners should read this as a shift from human login controls to machine trust governance.

AI identity governance needs a named concept: borrowed-credential risk. When an AI authenticates through a human account, the credential may be valid while the identity claim is false. That gap creates attribution problems, persistence risk, and lifecycle blindness. The practitioner conclusion is straightforward: if the account is human-owned but the actor is not human, the governance model is already out of alignment.

This model also exposes the limits of static access grants. AAI systems do not need a permanent permission bundle to prove they are legitimate at every moment. Static grants make sense when identity is stable and intent is predictable, but runtime systems need proof that travels with execution. IAM and PAM teams should therefore evaluate where standing access still sneaks into AI workflows through delegation shortcuts.

From our research library:

• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: Threat Modelling AI Agents

What this signals

Borrowed-credential risk: AI access becomes harder to govern when the control plane is built around a human login event. If the AI inherits a person’s authentication path, IAM teams lose the ability to reason cleanly about ownership, task scope, and revocation.

This is where attestation becomes operationally relevant. Access decisions for AI should be tied to runtime evidence that the system is trusted at that moment, not to a one-time authentication ritual designed for people.

Delegation will increasingly become the governance primitive for AI access because it preserves separation between the human approver and the non-human executor. Teams that keep human MFA at the center of AI access design are likely to accumulate identity debt rather than reduce risk.

For practitioners

• Separate human and AI authentication paths Stop routing AI access through human MFA flows. Create a distinct identity path for non-human actors so access is issued from machine proof rather than a person’s login event.
• Require runtime attestation before access is issued Use code integrity, origin, and orchestration context as gating evidence for AI access. Treat those signals as the basis for delegated authorization, not as optional telemetry.
• Replace long-lived human tokens with short-lived delegated credentials Issue credentials only after fresh proof and keep their lifetime tied to the task. Remove any pattern where an AI can continue operating under a person’s durable token.
• Define revocation rules for delegated AI access Document what ends the delegation, who can revoke it, and what runtime conditions invalidate it. Revocation should be explicit because AI access can otherwise persist after the original approval context disappears.

Key takeaways

• For AI systems, forcing human MFA onto the access path creates borrowed-credential exposure and weakens identity boundaries.
• Multi-attestation is the proposed alternative because it grounds trust in machine evidence such as code integrity and runtime context.
• IAM and PAM teams should shift AI access governance toward delegation, short-lived credentials, and explicit revocation rules.

Key terms

• Multi-attestation: Multi-attestation is a trust model for non-human actors that combines several runtime evidence signals before access is granted or renewed. Instead of proving a person is present, it proves the workload or AI is the expected actor, running the expected code, in the expected context.
• Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.
• Borrowed-Credential Risk: The security exposure created when a non-human actor uses a human account or token to gain access. It weakens attribution, confuses lifecycle ownership, and can leave persistent access in place long after the original human approval context has changed.
• Runtime Context: Runtime context is the set of signals used to judge whether an AI agent's behaviour is appropriate while it is acting. It includes identity, data access, model behaviour, posture, and environment. In practice, it is the difference between checking permission and evaluating purpose.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.