AI identity models need attestation, not human MFA rituals

At a glance

What this is: This article argues that AI should not be forced through human MFA flows and instead needs delegation plus multi-attestation to establish non-human identity.

Why it matters: That matters because IAM, PAM, and lifecycle controls have to distinguish between human authentication, NHI access, and AI runtime proof or they will overfit to the wrong actor.

By the numbers:

• 74% say machine identity management complexity has increased significantly in the past two years.
• 66% say their current tooling is not adequate to manage the scale of machine identities they now have.
• 61% rely on spreadsheets or manual tracking for machine identity management.

👉 Read Defakto Security's analysis of AI MFA, delegation, and multi-attestation

Context

AI identity is not the same problem as human authentication. Human MFA assumes a person is proving intent at login time, while AI and workloads often need delegated access that is validated through runtime evidence rather than repeated user prompts. When teams blur those boundaries, they create long-lived credentials and audit trails that describe the wrong actor. That is why AI identity needs to be treated as a non-human identity problem, not a human login problem.

The operational gap is already familiar to machine identity teams: visibility, ownership, and lifecycle control break down as scale grows. NHI programmes need a stable way to represent what the actor is, what it is allowed to do, and how that proof is refreshed without impersonating a person. For broader context on this governance model, see the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.

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 borrowed human credentials create risk in AI workflows?

A: Borrowed credentials blur the subject of the access decision. Revocation, logging, and access review all point back to a human account even though a non-human actor executed the action. That weakens accountability, increases standing privilege risk, and makes incident response harder.

Q: What should organisations require before granting AI access to systems or data?

A: Require delegated authorization plus proof that the AI is the expected workload in the expected runtime context. Multi-attestation can combine code integrity, provenance, and environment signals so access is tied to evidence rather than to a borrowed human login.

Q: How do machine identity controls change when AI becomes more autonomous?

A: The more runtime decision-making the AI performs, the less useful human login rituals become. Governance has to shift toward task scope, execution context, and revalidation logic so access is controlled by what the actor is doing, not by a person’s original approval alone.

Technical breakdown

Why human MFA does not map cleanly to AI access

MFA verifies a human at the point of authentication, usually by combining knowledge, possession, or inherence factors. AI agents and workloads do not fit that model well because they act non-interactively, may execute repeatedly, and often need access that outlives a single user session. If the only way to grant that access is to borrow a human token, the system stops describing the real actor and starts extending human identity assumptions into machine behaviour. That creates weak accountability, brittle revocation, and hidden standing privilege.

Practical implication: separate human authentication from machine authorisation so AI access is governed as an NHI lifecycle problem, not a user login workaround.

How delegation and multi-attestation create a machine identity boundary

Delegation moves the trust decision from impersonation to authorization. A human can approve a specific AI task, while the AI presents its own identity using layered attestation signals such as code integrity, provenance, runtime context, or hardware-backed claims. Multi-attestation matters because no single signal is enough to establish trust in a dynamic system. The point is not to prove a person is present again and again, but to prove the non-human actor is the expected workload, running the expected code, in the expected environment.

Practical implication: define delegated task scopes and require attestation evidence before issuing or refreshing machine access.

Short-lived credentials and runtime claims are a governance control, not a convenience feature

Short-lived credentials reduce the time window in which borrowed access can be abused, but they only work when paired with a clear identity model. Without runtime claims, short-lived tokens can still become standing privilege in practice because the organisation cannot distinguish legitimate task execution from overreach. This is why attestation, delegation, and TTL all belong in the same control design. The identity model has to encode what the actor is, why it was trusted, and when that trust expires.

Practical implication: bind every AI credential to a named purpose, a short TTL, and a revalidation path tied to runtime evidence.

NHI Mgmt Group analysis

Human MFA was designed for a person at a login prompt, and that assumption breaks when the actor is an AI system. MFA is built around deliberate human interaction and a stable person behind the credential. AI access often needs programmatic execution, delegated scope, and repeated runtime activity without a human present for each step. The implication is that identity programmes must stop treating AI access as a special case of human authentication and start treating it as a separate actor model.

Delegation is the more accurate control primitive for AI access because it preserves accountability without borrowing personhood. A human can authorize a task while the AI proves its own trustworthiness through multi-attestation. That structure aligns the access decision with the actual actor rather than with a proxy account. Practitioners should read this as a shift from credential sharing to evidence-based machine identity governance.

Multi-attestation is a named control concept worth adopting because it captures the real trust problem for AI systems. The model is not just about verifying code, but about combining code integrity, origin, runtime context, and execution conditions into one authorisation decision. That matters because AI trust is situational and can change during execution. The implication is that static login rituals are the wrong trust boundary for dynamic non-human actors.

Persistent human credentials hidden inside AI workflows create identity blur, and identity blur is itself a governance failure. When an AI inherits a person’s token, revocation, audit, and access review all point to the wrong subject. That breaks ownership, weakens least privilege, and obscures who or what actually exercised the access. Practitioners should treat any long-lived borrowed credential as evidence that the identity model has failed.

This debate connects human IAM, NHI governance, and workload identity into one operating model. AI systems will increasingly sit alongside service accounts, certificates, tokens, and human approvers in the same delegation chain. If the governance model cannot distinguish those actor types, it cannot assign durable responsibility. The practitioner conclusion is simple: access policy must follow actor type, not interface style.

From our research:

• 74% say machine identity management complexity has increased significantly in the past two years, according to The Critical Gaps in Machine Identity Management report.
• 66% say their current tooling is not adequate to manage the scale of machine identities they now have, which shows the governance gap is already operational rather than theoretical.
• Use Ultimate Guide to NHIs to anchor your broader identity model, then pair it with OWASP Non-Human Identity Top 10 to map the controls this article implies.

What this signals

Multi-attestation: the practical lesson is that AI access should be governed by evidence of runtime state, not by repeated human authentication rituals. As organisations add more machine-like actors to identity stacks, they will need policy that can distinguish delegated purpose from borrowed personhood.

The operational signal is that credential lifecycle work for AI is converging with broader machine identity governance. With 61% of organisations still relying on spreadsheets or manual tracking for machine identity management, per our machine identity research, any AI programme that depends on borrowed credentials will scale faster than its control plane.

The reader takeaway is to rework identity architecture now, before AI access becomes embedded in production workflows. Align task approval, runtime attestation, and revocation logic so the programme can support non-human actors without inheriting human login assumptions.

For practitioners

• Separate human authentication from AI authorization Require a human to approve the task, then issue access to the AI through a machine identity path with its own lifecycle, revocation rules, and audit records.
• Adopt delegated task scopes Limit each AI grant to one purpose, one system boundary, and one expiry condition so the access can be reviewed and revoked as a discrete entitlement.
• Use multi-attestation before issuing credentials Combine runtime signals such as code integrity, provenance, and execution context before minting or refreshing an AI credential.
• Eliminate borrowed human tokens from AI workflows Find any AI process that authenticates through a person’s long-lived credential and replace it with a non-human identity that can be owned, observed, and retired independently.

Key takeaways

• AI access breaks human MFA assumptions because the actor is not a person at a login prompt.
• Machine identity governance is already under strain, with most organisations reporting rising complexity and inadequate tooling.
• Delegation plus multi-attestation gives IAM teams a clearer identity boundary than borrowed human credentials ever can.

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: Delegated authorization is a control pattern where a human approves a task and a non-human actor executes within that approved scope. It separates intent from execution, which helps preserve accountability without forcing the machine to impersonate a human account.
• Borrowed credential: A borrowed credential is a human token or account used by an AI or workload to access systems it should not inherit directly. It obscures ownership, complicates revocation, and turns machine activity into a false human identity record.
• Machine identity boundary: A machine identity boundary is the point where an organisation distinguishes non-human access from human authentication and assigns its own lifecycle rules. It defines what the actor is, what evidence is trusted, and how access is retired or renewed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Defakto Security: AI MFA vs Multi-Attestation, Why AI Needs a New Identity Model. Read the original.