Helmwart
← Atlas · Mitigations Tier 2 · Real-composable

MITIGATION · m-mfa-high-priv

MFA for high-privilege agent identities — step-up attestation at credential issuance and action time

An agent identity that holds broad write authority is a high-value target: compromising its credential gives an attacker persistent, authenticated access to every system that identity can reach. Multi-factor authentication addresses this by requiring a second factor at credential issuance time, so a stolen token is bounded to its issued lifetime and cannot be silently renewed. For non-human identities the second factor is workload attestation, hardware-bound key material, or certificate-backed proof rather than a phone or one-time code.

Last reviewed 2026-05-12 · Status: published · Evidence →

At a glance

MATURITY
Tier 2
Available off-the-shelf or as a documented pattern, but newer or less broadly proven. Expect integration work and some operational nuance.
PLACES ON
node
Restricted to node kinds: agent
COVERAGE
2 threats
T3 · T9
TRADE-OFFS
LAT
low
COST
low
UX
low
DEV
medium
Latency · cost · UX friction · dev effort.
TL;DR
  • Every agent identity that holds broad write authority must present a second factor before credentials are issued or renewed. A stolen token is valid only for its issued lifetime and cannot be silently refreshed without passing attestation again.
  • For non-human identities the second factor is workload attestation, hardware-bound key material (TPM, HSM, or Secure Enclave), or X.509 certificate-backed proof issued by a trusted CA, not a shared one-time code or phone.
  • Action-time step-up authentication (RFC 9470) layers on top of the base credential: a resource server issues a challenge requiring fresh re-attestation before a specific high-privilege action proceeds, keeping the common case fast.
  • Enrol every production agent identity before deploying it to a high-privilege role. An unenrolled identity in production is a gap, not a deferral.

How it behaves

Agent requests credential issuance, renewal, or a high-privilege action
Identity provider or resource server verifies the second factor: workload attestation, hardware-bound cert, or step-up challenge result
Issue short-lived credential, or allow high-privilege action to proceed
Deny credential issuance or block action; emit an alert for the failed attestation attempt
Attestation fires at credential issuance; step-up fires again at action time for operations whose blast radius justifies additional assurance. The credential lifetime must remain short so that a successful attestation does not grant indefinite access.

What it is

Multi-factor authentication is a credential-issuance control: before a credential is issued, the identity provider requires the requesting party to satisfy a second, independent factor in addition to the primary credential material. If the primary credential is compromised but the second factor is not, the attacker cannot obtain a valid credential and cannot act as the agent.

For non-human identities, the second factor is not a phone or a one-time code. It is workload attestation (the identity is only issued to a workload that proves it is the correct binary, running on the correct node, with a verified secure-boot chain), hardware-bound key material (a private key in a TPM, HSM, or Secure Enclave that cannot be extracted), or X.509 certificate-backed proof issued by a trusted CA. The application selects which combination forms the second factor and where in the credential issuance path it is verified.

A separate pattern, step-up authentication, applies the same logic at action time rather than at issuance time. When an agent presents a valid credential but then requests a high-privilege action whose blast radius justifies additional assurance, the resource server issues a challenge requiring fresh re-attestation before the action proceeds. RFC 9470 defines the OAuth 2.0 protocol for this challenge-response flow. Step-up can be layered on top of any base credential mechanism without replacing it.

Detection signals

  • Credentials issued without successful second-factor verification. Any issuance event that bypasses the attestation gate indicates a misconfiguration or a bypass attempt and warrants immediate investigation.
  • Step-up challenge failure rate per agent identity. A rising failure rate for a specific identity points to a misconfigured attestation path, a credential rotation event that was not propagated, or an active attempt to obtain credentials without the required second factor.

Threats it covers

  • T3 Privilege Compromise −2 severity steps

    WHY IT HELPS Privilege Compromise relies on an attacker obtaining and holding a valid agent credential long enough to act on it. Step-up attestation at credential issuance binds the credential to a second factor the attacker does not hold, so a stolen secret is valid only for the lifetime of the issuance window it was bound to and cannot be silently renewed without passing attestation again.

  • T9 Identity Spoofing and Impersonation −1 severity step

    WHY IT HELPS Agent identity spoofing requires an attacker to impersonate a specific agent identity convincingly enough to be issued credentials by the identity provider. Multi-factor attestation raises the bar: the attacker must compromise both the primary credential and the independent second factor simultaneously, which are typically bound to separate hardware or infrastructure trust roots.

Principle coverage

Defence-in-Depth stage: Prevent — and it advances:

  • Zero Trust Zero Trust holds that no identity is inherently trusted beyond what it explicitly proves. Multi-factor attestation enforces that for agent identities at the credential issuance layer: a valid primary credential grants nothing on its own without concurrent second-factor verification, so trust is re-established at each issuance event rather than assumed from a standing identity.
  • Agent-as-principal Identity Agent identity requires that every non-human workload be cryptographically distinguishable and that its credentials cannot be obtained without proof of correct provenance. Multi-factor attestation binds credential issuance to independent proof of workload identity, hardware trust, or certificate authority, so the issued credential carries evidence of who holds it, not merely that someone presented a secret.

Design & governance principles (open design, economy of mechanism, accountability, …) are architectural, not advanced by a single placed control.

Implementation options

Choose the attestation layer that fits your deployment model. Cloud-managed options are fastest to adopt for single-cloud workloads. SPIFFE/SPIRE is the vendor-neutral option for multi-cloud or bare-metal environments. RFC 9470 step-up adds action-time re-attestation on top of any base credential.

SPIFFE/SPIRE SPIRE issues a short-lived X.509 SVID to a workload only after two-phase attestation: node attestation (EC2 Instance Identity Document, GCP Instance Identity Token, Azure MSI, or a join token) followed by workload attestation (Unix uid/gid, Kubernetes service account, Docker container properties).

Why choose it: Best when agent workloads span multiple clouds or bare-metal nodes and a vendor-neutral identity fabric is required. The SVID TTL (typically minutes) makes the issued credential short-lived by construction. Set ttl in the SPIRE registration entry and pair with automatic SVID rotation via the Workload API.

More details:

AWS IAM Roles Anywhere Workloads outside AWS authenticate with X.509 certificates issued by a trust-anchor CA; IAM Roles Anywhere validates the certificate chain and signature, then issues short-lived STS credentials scoped to an IAM role, with no long-term AWS credentials required.

Why choose it: Best when agents run outside AWS but need to call AWS APIs under a high-privilege role. The certificate is the second factor: the workload must prove possession of the private key and that the certificate was issued by the trusted CA before STS credentials are issued. Use Condition keys on the trust policy to lock issuance to a specific certificate Subject, Issuer, or SAN field.

More details:

GCP Workload Identity Federation External workloads exchange a trusted token from their own identity provider (OIDC, SAML 2.0, X.509 certificate, or AWS/Azure credential) with Google Security Token Service for a short-lived GCP access token, without requiring a service account key.

Why choose it: Best when agents already hold a native identity from another platform (AWS IAM role, Azure managed identity, Kubernetes service account, SPIFFE SVID) and need to call GCP APIs. The external token is the second factor; GCP STS verifies it against the registered IdP before issuing credentials. Restrict issuance to specific SPIFFE IDs, Kubernetes namespaces, or AWS account conditions using attribute conditions in Common Expression Language.

More details:

Microsoft Entra Agent ID Microsoft Entra Agent ID provides purpose-built identity constructs for AI agents, including enforced human sponsorship, lifecycle governance, and Conditional Access policies, backed by workload identity federation for agents running outside Azure.

Why choose it: Best when agents operate in the Microsoft 365 or Azure ecosystem, or when Conditional Access enforcement against agent identities specifically is required. Agent ID extends Entra's adaptive access policies and audit logging to agent identities rather than adapting general service principal controls. Workload identity federation lets agents on non-Microsoft platforms still receive a governed Entra identity without managing secrets.

More details:

RFC 9470 Step-Up Challenge When a resource server determines that the existing access token does not meet the required authentication strength for a specific high-impact operation, it returns an HTTP 401 with the insufficient_user_authentication error and an acr_values challenge; the client re-authenticates at the required assurance level before retrying.

Why choose it: Best as the action-time gate that sits on top of any base credential. Use RFC 9470 when an agent's token is valid for most operations but a specific tool call (write to a financial ledger, execute infrastructure destroy) requires fresh re-attestation. The common case proceeds at normal speed; the challenge fires only where the blast radius justifies it. Requires an authorization server that supports acr_values and an agent runtime capable of catching 401 challenges and re-authenticating.

More details:

Trade-offs

  • Hardware-bound and attestation-based second factors add roughly 10 to 50 ms at credential issuance time. That cost is paid once per issuance window (minutes to hours), not on every request, so the per-request latency impact is negligible.
  • Selecting the right attestation mechanism per agent class is design work. SPIFFE SVIDs are cross-cloud but require deploying and operating SPIRE. Cloud-native options (Roles Anywhere, GCP WIF, Entra Agent ID) are faster to adopt but couple the credential format to a single provider.
  • Dev effort is medium and front-loaded: every agent identity must be re-provisioned to present a second factor, and the credential issuance path must be instrumented to reject unverified attempts.

When NOT to use

  • Do not apply to agents with narrow, read-only scopes where the damage from credential theft is bounded to non-destructive reads. The attestation overhead is not justified at that risk level.
  • Do not replicate human MFA patterns directly: a shared TOTP secret stored in a secrets manager that the whole team can read is not a second factor for a non-human identity. It is a shared secret with extra steps.
  • Do not treat passing attestation as evidence that the agent will behave correctly. Workload attestation verifies what the process is, not what it will do. Pair this control with behavioural bounds and output moderation for the other failure modes.

Limitations

  • MFA for a non-human identity does not prevent the agent's own software from misbehaving. It prevents silent credential theft from giving an attacker indefinite, authenticated access.
  • RFC 9470 step-up was designed for OAuth 2.0 human-user flows. Applying it to workload re-attestation is an architectural extension without an industry-standard profile; each deployment composes the mechanism differently.
  • Cloud-native workload identity federation (GCP WIF, Entra WIF, Roles Anywhere) operates at project or account granularity for some limits. A misconfigured trust anchor can allow any workload in the account to obtain credentials for a high-privilege role.
  • Certificate revocation for Roles Anywhere trust anchors relies on imported CRLs; OCSP and CDP callbacks are not supported, so revocation latency depends on how frequently CRLs are re-imported.

Maturity tier reasoning

  • Tier 2 fits because every component (SPIFFE/SPIRE, AWS Roles Anywhere, GCP Workload Identity Federation, Microsoft Entra Agent ID, RFC 9470) is production-available and documented. The integration is real composition across established primitives, not research.
  • What keeps this out of Tier 1 is the absence of an industry-standard agent MFA profile. Every deployment selects and combines primitives differently, and no single specification defines what multi-factor authentication for a non-human identity must look like end to end.
  • Microsoft Entra Agent ID (April 2026) is the first managed service to provide purpose-built identity constructs specifically for AI agents rather than adapting general NHI controls. The maturity of that specific layer is newer than the underlying federation primitives.

Last verified against upstream docs: 2026-05-30.