How should organisations build IAM to support AI agents, contractors, and mobile workers without increasing risk?

Why This Matters for Security Teams

Building IAM for AI agents, contractors, and mobile workers is hard for the same reason these populations are risky: they do not behave like stable, office-bound employees with predictable access patterns. Contractors change often, mobile workers move across unmanaged networks and shared devices, and AI agents can chain tools, call APIs, and act faster than human reviewers can intervene. That makes static role design and one-time login checks too weak for modern environments.

For autonomous workloads, the identity question is not only who is signing in, but what is acting, under what context, and for how long. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward runtime governance, not static trust. In parallel, NHIMG research on the AI Agents: The New Attack Surface report shows 80% of organisations reporting AI agents have already acted beyond intended scope, which is a reminder that identity sprawl becomes a control failure quickly when permissions are not tightly bounded.

In practice, many security teams encounter excessive access only after contractors, mobile endpoints, or AI agents have already crossed a permission boundary that no longer matches business need.

How It Works in Practice

The practical answer is to separate identity, authentication strength, and authorisation duration. Human users should authenticate with passwordless methods where possible, but the real control is continuous policy evaluation across device health, location, sensitivity of the resource, and session risk. Contractors should be onboarded with time-bound entitlements and reviewed against project scope, while mobile workers need access paths that assume device loss, network change, and frequent re-authentication.

AI agents need a different design pattern. They should not inherit broad human roles. Instead, they should receive workload identity and task-scoped access, with short-lived tokens, explicit delegation, and automatic revocation when a task completes. This is where policy-as-code and intent-based authorisation matter. At request time, the IAM layer should decide whether the agent is allowed to perform the specific action in the specific context, rather than relying on a role that was assigned weeks earlier.

• Use just-in-time access for contractors and privileged human workflows.
• Issue ephemeral credentials to agents for a single task or narrow workflow.
• Bind access to device posture, session risk, and resource sensitivity.
• Prefer workload identity over shared secrets for service-to-service and agent-to-tool access.
• Log delegation, tool use, and token issuance for audit and incident response.

Implementation guidance from the CSA MAESTRO agentic AI threat modeling framework and NHIMG’s OWASP NHI Top 10 aligns with this approach: treat agents as governed workloads, not as human users with faster clicks. These controls tend to break down when legacy SaaS and on-premises systems only support coarse RBAC and cannot evaluate context at the point of action.

Common Variations and Edge Cases

Tighter access control often increases provisioning overhead, so organisations must balance speed of work against the risk of over-entitlement. That tradeoff is most visible for frontline staff, third-party vendors, and AI agents that need to work across multiple systems in a single business process.

There is no universal standard for every edge case yet, but current guidance suggests a few practical patterns. Shared devices should use session-based controls and rapid token expiry because device ownership is weak. Contractors should be tied to sponsor-owned approvals, expiry dates, and periodic recertification. AI agents that operate in multi-step workflows should be constrained by explicit task policies, not broad environment-wide access. For higher-risk use cases, organisations should combine continuous verification with step-up checks before sensitive actions such as data export, credential use, or administrative changes.

NHIMG research on CoPhish OAuth Token Theft via Copilot Studio and the Ultimate Guide to NHIs both reinforce the same lesson: if a system cannot distinguish a legitimate delegated action from a stolen or overbroad token, it is not ready for autonomous access. The hardest cases are legacy applications, shared administrative consoles, and environments where identity policy cannot follow the workload across domains.

Related resources from NHI Mgmt Group

• How should organisations support Digital ID without increasing privacy risk?
• How should organisations use AI to support mobile security without over-automating decisions?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents create more IAM risk than ordinary developer tools?