When should organisations add runtime governance to IAM for machine identities?

Why Runtime Governance Becomes Necessary for AI Agents

runtime governance is the point where login-centric IAM stops matching how machine identities actually operate. That matters most for autonomous AI agents, because they do not follow fixed human session patterns: they request tools, chain actions, retry tasks, and sometimes escalate from one API call into several downstream systems. Static RBAC can describe who should have access, but it cannot reliably describe what an agent is trying to do at a given moment. Current guidance suggests that authorisation for agentic workloads must move closer to intent and context, not just preassigned roles, which is why runtime policy evaluation is increasingly part of the control stack. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it pushes organisations to align identity, access, and continuous monitoring rather than treating them as separate problems. NHIMG research also shows how often governance gaps are already visible: the Top 10 NHI Issues page highlights the operational patterns that make static controls fail. In practice, many security teams encounter this only after an agent has already issued, reused, or chained credentials in ways no access review ever anticipated.

How Runtime Governance Works in Practice

The practical answer is to add controls at the moment of use, not only at the moment of issuance. For machine identities, that means combining workload identity, short-lived secrets, policy-as-code, and request-time decisioning. An agent should prove what it is through cryptographic workload identity, then receive just-in-time credentials for a specific task, with scope and TTL tied to that task rather than to a long-lived account. This reduces the blast radius when a token is stolen or a workflow misbehaves. It also makes downstream calls auditable, because each privileged action can be correlated with an intent, a policy decision, and a bounded credential lifetime.

• Use workload identity as the base primitive, so the system trusts the workload’s cryptographic identity before issuing secrets.
• Issue ephemeral credentials per task, and revoke them automatically when the task completes or the context changes.
• Evaluate authorisation at runtime using policy-as-code, so the decision reflects current risk, target system, and action intent.
• Log token issuance, reuse, and downstream calls together, because those events are often where misuse becomes visible.

This is consistent with the direction of least privilege in NIST CSF, and with agent-specific thinking in the NIST Cybersecurity Framework 2.0. For an NHI-specific view of lifecycle controls, see NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, which is especially relevant when runtime governance must be tied to issuance, rotation, and revocation. The main failure point is environments where agents can invoke many third-party tools with mixed trust levels, because policy decisions then depend on context that IAM alone does not see.

Common Variations and Edge Cases

Tighter runtime governance often increases operational overhead, so organisations have to balance control depth against latency, engineering effort, and workflow friction. That tradeoff is real, especially when agents operate at high frequency or across many microservices. Best practice is evolving, but there is no universal standard for exactly where the boundary should sit between IAM and runtime policy enforcement. Some teams place all decisions in a central policy engine; others use a layered model where IAM handles initial trust and runtime governance handles tool access, data access, and high-risk actions. This is where static secrets become especially risky. Long-lived credentials may still exist for legacy workloads, but they should not be the default for autonomous systems. NHIMG has documented how exposed secrets can quickly turn into privilege escalation paths, including cases such as Azure Key Vault privilege escalation exposure and JetBrains GitHub plugin token exposure. Those examples reinforce a simple rule: if an agent can act continuously, secrets should be short-lived and governance should be continuous. For organisations formalising this shift, the Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps frame how to evidence control decisions, while the external guidance from NIST Cybersecurity Framework 2.0 supports continuous monitoring and accountability. Runtime governance breaks down most clearly when an agent has broad tool access, weak observability, and no clean boundary between authenticated identity and authorised intent.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• How can organisations reduce the blast radius of compromised agent identities?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Should organisations prioritise external exposure or internal credential governance first?