Composable computers for AI agents and the new identity model

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: AI agents are moving toward dedicated computers, with agent identity and access models shifting away from human seat logic.

Why it matters: IAM teams need to understand this shift because agent-specific sandboxes, credentials, and account boundaries will force new lifecycle, governance, and authorisation decisions across NHI and autonomous identity programmes.

Context

AI agents are starting to outgrow API-only workflows and move into full computing environments. That changes the identity problem: once an agent needs its own machine, access is no longer just about whether a token can call a service, but about what that agent is allowed to do inside a computer-like runtime.

The governance gap is that most IAM models still assume a stable user, a stable workload, or a stable service account. Burazin's argument, as reported by WorkOS, is that the unit of access is shifting toward an agent with its own identity, tools, and environment, which has direct implications for NHI governance, privilege design, and lifecycle control.

Key questions

Q: What breaks when AI coding agents run in allow-default sandboxes?

A: Allow-default sandboxes fail because they preserve most host capabilities and rely on deny rules to catch every dangerous path. For AI coding agents, that is too weak, since file handling, launch behaviour and environment interactions can be chained into host execution. A permissive sandbox can look functional while still leaving the machine reachable through an escape path.

Q: Why do machine-majority workflows change IAM and governance decisions?

A: Because the unit of consumption shifts from a person to a machine task, traditional provisioning, recertification, and licensing models stop reflecting actual usage. That affects access governance, chargeback, and accountability at the same time. Teams need to treat agent activity as an operational identity signal, not as an edge case attached to human users.

Q: How do security teams prevent identity drift in AI agent deployments?

A: They should keep the human sponsor, the agent runtime, and any delegated service account separate in both policy and telemetry. If the agent starts using the creator's identity as a shortcut for authorization or context, accountability becomes unclear. Monitoring should flag cross-boundary authority bleed, not just failed logins or token expiry.

Q: Should organisations treat AI agent governance as a one-time rollout or an ongoing programme?

A: It should be treated as an ongoing programme, because agent workflows change as integrations, permissions, and tasks evolve. A baseline that worked in one quarter may not hold after a workflow update or new system connection. Continuous review is what keeps monitor mode useful after the first policy cycle.

Technical breakdown

Why agent sandboxes change the identity boundary

A sandbox is a controlled execution environment that lets software interact with files, networks, web apps, and internal tools without sharing a broader host identity. In this model, the agent is not just calling an API through a single service credential. It is acting inside a computing boundary that can carry its own permissions, data access, and operational scope. That moves the security question from endpoint permission to runtime identity. The practical issue is that access now needs to be defined around the environment the agent inhabits, not only the service it reaches.

Practical implication: define agent-specific runtime boundaries instead of treating every agent as a thin API client.

How agent-owned identity breaks seat-based access

Seat-based licensing and entitlement models assume a human user as the unit of consumption. AI agents invert that assumption because the consumer is often a machine that executes tasks continuously and can interact with many systems at once. Once that happens, account provisioning, access review, and cost allocation all detach from the old one-person, one-seat logic. Burazin's example of an AI with its own email, phone number, and tool accounts shows how quickly identity can become synthetic but still operationally real. The result is an access model that must govern machine-held identity, not just human-held accounts.

Practical implication: rework entitlement, billing, and review processes around machine consumption rather than human seats.

Identity drift appears when an agent starts acting like its creator

When an agent operates under its own credentials, the control problem is not only what it can access, but whether it remains distinguishable from the person or workflow that created it. If the agent begins defaulting to its creator's identity or authority, accountability becomes blurred and approvals become harder to trust. This is a governance issue, not just a UX quirk. The failure mode is identity drift, where the system's operational identity and its human sponsor's identity start to converge in ways that weaken traceability and scope control.

Practical implication: separate sponsor identity from agent identity and monitor for authority bleed between them.

NHI Mgmt Group analysis

Agent computers turn identity from a session problem into a runtime problem: once an AI agent needs a dedicated computing environment, IAM can no longer stop at authenticating a caller. The control question becomes how that runtime is bounded, observed, and retired across tasks. That is a structural shift for NHI governance because the protected object is no longer just a secret or token, but the whole execution surface the agent inhabits.

Seat-based access is the wrong abstraction for machine-majority systems: Burazin's model points to a world where consumption, not named-user entitlement, becomes the dominant commercial and operational unit. That means recertification, capacity planning, and access governance all need to follow machine activity patterns instead of employee headcount. The practitioner implication is that IAM and finance teams will have to align around machine consumption as a first-class identity signal.

Human-authored identity assumptions collapse when the agent can operate as its own actor: least privilege was designed for access that can be reasoned about at provisioning time. That assumption fails when an agent can initiate actions, retrieve missing data, and choose its own execution path inside a sandbox. The implication is not merely more controls, but a rethinking of how authority is assigned when the subject of access is itself making runtime decisions.

Identity drift is the named risk emerging from agent-with-an-identity patterns: the moment an agent has its own email, phone number, and tool accounts, it can be mistaken for, or operationally entangled with, the human who created it. That creates accountability ambiguity across NHI, human IAM, and autonomous behaviour. Practitioners should treat identity separation as a governance boundary, not an implementation detail.

Composable computers will push NHI governance toward lifecycle discipline, not one-time provisioning: the more agents resemble durable actors with persistent runtime environments, the more offboarding, attestation, and entitlement review matter. OWASP-NHI and NIST CSF thinking both point to the same conclusion: if the agent outlives the task, the governance model must outlive initial access approval. The practitioner conclusion is that agent identity should be managed as a lifecycle, not as a launch event.

What this signals

Identity drift is the governance smell to watch: when an agent begins to blur into the person who created it, the programme has lost the boundary that makes attribution possible. That matters for access reviews, incident investigation, and delegated authority because the system no longer has a stable answer to who acted.

The strategic shift is not just more automation, but a different access ontology. Programmes that can express runtime boundaries, machine consumption, and lifecycle controls for agents will cope better than those still treating every identity as either a human seat or a simple service account.

For practitioners

• Define agent runtime boundaries Map which agent tasks require a dedicated sandbox, which require only API access, and which should be denied a full computing environment altogether.
• Separate sponsor and agent identity Assign distinct identities, credentials, and approval paths for the human sponsor, the agent runtime, and any delegated service accounts to prevent authority bleed.
• Review entitlement models for machine consumption Replace seat-centric access assumptions with machine-centric consumption, task scope, and runtime access duration when evaluating agent permissions.
• Instrument agent identity drift Watch for agents that begin behaving as if they are their creators, especially when they inherit human context or cross-system authority.

Key takeaways

• AI agents are moving toward dedicated computing environments, which makes runtime boundary control more important than simple API authorisation.
• The identity model is shifting from human seats to machine consumption, forcing IAM, entitlement, and lifecycle processes to change together.
• Agent identity must remain distinct from human sponsor identity if organisations want accountability, traceability, and governable privilege.

Key terms

• Agent Sandbox: A short-lived execution environment where an AI agent can run tools, access files, and perform task-scoped work. The sandbox must isolate each run, control what the agent can reach, and cleanly tear down state when the task is complete.
• Identity Drift: Identity drift is the gap between the access path originally approved and the behavior that exists later. For browser extensions, drift can appear through updates, remote configuration, publisher changes, or permission expansion, turning a trusted integration into a materially different risk.
• Machine Consumption Model: A usage model where software value is measured by tasks, compute, and actions taken by machines rather than by named human seats. For IAM and governance, this shifts entitlement, review, and billing logic toward runtime activity and away from employee-based licensing assumptions.
• Agent Runtime: The agent runtime is the execution environment where an AI agent reads data, calls tools, and carries out actions. It matters because the runtime is where identity, policy, and filesystem boundaries either hold or fail. If those boundaries are weak, the agent becomes a high-privilege path into the environment.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.