How should IAM teams govern agents that are instantiated by users on demand?

Why user-instantiated agents need their own governance model

When users can spin up agents on demand, the governance problem is not just who owns the underlying platform. The key issue is whether each instantiated agent receives a clearly bounded authority envelope, or whether it quietly inherits broad access from the user, project, or default template. That is why agent governance needs task scope, expiry, and reviewability as first-class controls.

For teams that are still treating these agents as ad hoc automations, the boundary problem gets worse quickly. An agent may start as a helper for one workflow, then accumulate broader permissions, longer-lived tokens, or informal exceptions. A useful baseline is to treat the agent as an owned operational object with its own governance model for entitlements and access review, rather than as a side effect of the user who created it.

That framing also fits the broader lifecycle view in NHI Lifecycle Management Guide, because on-demand agents still need creation, ownership, rotation of credentials where used, and retirement when the task ends. If the organisation cannot answer when an agent expires, who can re-authorize it, and what resource scope it had at runtime, governance is already behind the operational reality.

What runtime authorization and scoped tool access should look like

Runtime authorization is the control point that matters most for these agents. The decision should be made at execution time, not only at enrollment time, because the task, context, and risk can change from one invocation to the next. That means the agent should receive only the tools, data, and actions that are required for the specific job, not a broad standing grant “just in case”.

This is where task-bound access becomes more than a policy slogan. A well-governed agent should be able to prove, at the moment of use, why it can call a tool, read a dataset, or act on behalf of a user. If your organisation already understands the difference between human and machine access paths, human versus non-human identity governance is the right mental model for separating personal privileges from delegated execution authority.

For teams choosing implementation patterns, the most defensible model is least privilege with per-action control decisions, not one-time approval for everything the agent might do later. That keeps the blast radius aligned to the current task, especially when the agent can invoke external systems, write to shared repositories, or trigger business workflows. It also creates a clear basis for audit, since each action is tied to a specific authorization decision.

How to keep agent governance consistent across projects

Project-level freedom sounds efficient until the estate fills up with incompatible delegation rules, different expiry conventions, and local exceptions that nobody can reconcile. Once that happens, the organisation loses the ability to compare risk, review access consistently, or prove that similar agents are governed the same way. Central policy does not need to block team autonomy, but it does need to define the guardrails for registration, approval, scope, and retirement.

A practical governance pattern is to separate policy definition from project execution. Central identity and security teams should define the control plane, while product teams request agent creation within that model. The Identity Security Programme Guide is a good reference point for thinking about operating model, RACI, and governance ownership when multiple teams create identities or identity-like execution actors.

For organisations that want a broader control baseline, the regulatory and audit perspective in the Ultimate Guide to NHIs is useful because it reinforces the need for traceable ownership, access review, and evidence retention. On-demand agents are easiest to defend when every instance has a named owner, a purpose, an expiry condition, and an audit trail that can be reviewed without reconstructing the story from tickets.

Risk and Threat Considerations

On-demand agents concentrate risk when teams let them inherit user access too freely or keep them alive after the task is over. The common failure mode is that a short-lived request becomes a persistent delegated capability, which expands blast radius and makes later review difficult. This is especially dangerous when the agent can touch production tools, secrets, or administrative workflows.

Failure mechanism: Weak runtime authorization, broad default scopes, or missing expiry allows an agent to keep operating beyond the task that justified it, creating privilege creep and hidden persistence.

Impact: The organisation gets uneven blast radius, inconsistent audit evidence, and a larger opportunity window for misuse, accidental damage, or credential abuse if the agent is compromised or simply overused.

Practitioner Guidance

What to prioritise: Establish a single registration and authorization path for on-demand agents before allowing more teams to create them. If an agent can act, it should have an owner, a task scope, a runtime decision point, and an expiry condition that are visible to security operations and audit.

What to verify: Check whether the agent can still perform its actions after the original task window, whether tool access is narrowed per invocation, and whether you can produce evidence of each authorization decision. If you cannot show those three things, the control is not yet mature enough for production use.

Common mistake: Treating the user who launched the agent as the full governance answer. That shortcut works only for the smallest experiments; at scale it creates inconsistent delegation, unclear ownership, and a review problem that grows faster than the number of agents.

Practitioner takeaway: Govern on-demand agents as bounded delegated actors, not as informal project utilities. The strongest control is the one that makes every agent's authority narrow, temporary, and explainable at the moment it is exercised.

Related resources from NHI Mgmt Group

• How should teams govern AI agents that use MCP?
• 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 IAM teams govern tokens when access is delegated across users, services, and agents?