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

Why This Matters for Security Teams

Forcing MFA on machines sounds like a simple way to raise assurance, but it breaks the distinction between a person and an autonomous workload. AI systems do not sit at a keyboard, complete a one-time challenge, and stop. They call tools, chain actions, and operate continuously, which means the real control objective is not “make the machine prove it is human” but “prove what the workload is allowed to do, for how long, and under whose approval.” That is why NHIs must be governed as their own identity class, as described in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.

Security teams often inherit the wrong pattern from human IAM: a login, a prompt, and a token that stays valid far too long. That model does not fit agentic workflows, where the task changes midstream and the access footprint is determined at runtime. A better pattern starts with human-approved delegation, then issues a machine identity with explicit scope, short TTL, and evidence requirements tied to the action being requested. This is also where broader lifecycle discipline matters, as NHIMG’s Lifecycle Processes for Managing NHIs shows why issuance, rotation, and revocation must be treated as first-class controls, not afterthoughts. In practice, many security teams discover overreach only after an agent has already reached a sensitive system, rather than through intentional access design.

How It Works in Practice

The practical answer is to separate approval, authentication, and authorisation into different layers. A human owner approves delegation for a specific task, but the AI does not inherit the human’s MFA session. Instead, the platform mints a workload identity for the agent, preferably backed by cryptographic workload identity primitives such as SPIFFE or OIDC-style assertions, and binds that identity to a narrowly defined policy. Current guidance suggests that runtime policy should evaluate the request context, not just a static role, because autonomous systems can alter their path mid-execution.

That usually means four controls working together:

• Ephemeral credentials issued per task, not long-lived secrets stored in a vault and reused indefinitely.
• Scoped permissions that constrain which tools, APIs, datasets, or actions the agent can invoke.
• Real-time policy evaluation using policy-as-code so the decision can change when context changes.
• Evidence capture, so every delegated action can be traced back to the approving human and the specific task.

In NIST terms, this maps cleanly to zero trust principles from the NIST Cybersecurity Framework 2.0, while the agent-specific implications are better captured in evolving guidance from the Top 10 NHI Issues and the OWASP NHI research track. The key design choice is that the machine proves its own workload identity, while the human proves delegation authority once, at the right layer. These controls tend to break down when legacy apps only support interactive user sessions because they cannot separate human approval from machine execution.

Common Variations and Edge Cases

Tighter delegation controls often increase operational overhead, so organisations have to balance assurance against developer friction and incident-response speed. That tradeoff is real, especially when teams are trying to retrofit AI access governance onto older IAM stacks. Best practice is evolving, but there is no universal standard for whether every agent action should require fresh approval, a cached delegation window, or continuous step-up evidence.

One common edge case is shared agent infrastructure. If multiple agents use the same runtime, the identity must stay bound to the workload instance and task context, not the host alone. Another is tool chaining: an agent may start with low-risk access, then escalate into a higher-risk action by composing benign tools. That is why static RBAC alone is too blunt for autonomous systems. For deeper background on abuse patterns, NHIMG’s LLMjacking research and Microsoft Midnight Blizzard breach analysis show how quickly exposed identities can be weaponised. If the environment cannot mint short-lived workload credentials or evaluate policy at request time, the model breaks down fast, especially in multi-agent systems that fan out across many services.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that use OAuth access?
• How should security teams govern AI agents that can access enterprise systems?
• How should security teams govern autonomous agents without relying on quarterly access reviews?
• How should security teams govern machine identity credentials in agentic AI environments?