Composable computers for AI agents and the new identity model

At a glance

What this is: This is a conversation about AI agents needing dedicated computers, with the key finding that agent identity is becoming a systems-and-access problem, not just an API integration issue.

Why it matters: It matters because IAM, NHI, and human access programmes will increasingly need to govern machine identities that behave like users, but operate at runtime with their own tools, credentials, and environments.

👉 Read WorkOS's conversation with Daytona CEO Ivan Burazin on AI agent computers

Context

AI agent identity is becoming a governance problem because agents are moving beyond fixed API calls and into full computing environments where they can retrieve data, operate tools, and act under their own credentials. That changes the access model from narrow service integration to a broader machine-identity surface that looks more like a managed worker than a script.

For IAM teams, the relevant question is no longer whether an agent can authenticate, but what it is allowed to do once it has a computer, a sandbox, and separate accounts. In that environment, lifecycle, privilege scope, and accountability all become harder to anchor to human assumptions.

Key questions

Q: How should security teams govern AI agents that have their own sandboxes?

A: Security teams should govern AI agents with the same discipline used for other machine identities, but extend the model to include the sandbox, the agent account, and every delegated integration it can reach. The key is to bind access to task scope, record all actions, and revoke the full execution environment when the task or agent ends.

Q: Why do AI agents complicate traditional access reviews?

A: AI agents complicate access reviews because they can accumulate permissions across tools and environments faster than manual certification cycles can observe. A review process built for stable human accounts does not fit an executor that can act across systems, create new access paths, and complete work before the next review window begins.

Q: What breaks when an agent is treated like a normal service account?

A: What breaks is the assumption that the account only performs one bounded function. A modern agent may browse, retrieve data, interact with multiple applications, and carry state across steps, so a normal service-account model can miss the broader path of privilege and the need for tighter lifecycle control.

Q: How do machine-majority environments change identity governance priorities?

A: Machine-majority environments shift governance from human-centric seat management to action-centric machine control. Teams need clearer ownership, stronger logging, faster offboarding, and more precise privilege boundaries because the volume and velocity of non-human access will exceed what manual processes can safely manage.

Technical breakdown

Agent sandboxes as controlled execution environments

A sandbox gives an AI agent a constrained computer environment, not just an API token. That matters because the agent can open browser sessions, query internal systems, and complete tasks that require more than one tool interaction. From an identity perspective, the sandbox becomes part of the trust boundary: it contains the agent's runtime, credentials, and observable actions. The core governance issue is that the access surface now includes the environment itself, not only the service the agent ultimately touches.

Practical implication: treat the sandbox as a governed execution zone with explicit identity boundaries, logging, and scoped access controls.

Why AI agent identity behaves differently from service accounts

Traditional service accounts usually execute a bounded function with relatively stable permissions. Burazin's framing describes something broader: an agent that can decide when to look up missing data, which application to enter, and which action to take next. That is closer to delegated work than fixed automation. Identity governance has to account for session-level behaviour, task-specific authority, and the possibility that the agent will traverse multiple systems during one task.

Practical implication: map agent permissions to task scope and session boundaries instead of assuming one static role will fit all agent work.

Consumption-based access and the machine-majority shift

The move from seats to consumption reflects a deeper change in who or what is using enterprise systems. If agents become the dominant consumers of software, then identity programmes have to govern large populations of non-human actors whose access may outnumber human users. That creates pressure on provisioning, offboarding, auditing, and policy enforcement. The risk is not only more identities, but identities that scale faster than current review processes can handle.

Practical implication: build machine-identity governance for scale now, before agent populations outgrow manual review and recertification processes.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent identity is becoming a workload-governance problem before it becomes a user-experience problem. Once an agent has a sandbox, email, phone number, and access across internal tools, it stops looking like a simple integration and starts behaving like a managed workload with human-like reach. That shifts the centre of gravity from authentication alone to lifecycle control, privilege scope, and environment containment. Practitioners should treat agent identity as an expanding machine-identity class, not a feature request.

Delegated work identity: the useful concept here is not that the agent is autonomous in the strict editorial sense, but that it can operate under credentials that represent a task, not a person. That distinction matters because the control problem is no longer just who signed in, but what the agent is allowed to do across systems while it is active. In NHI terms, this is a delegation-chain problem with broader runtime reach than a normal service account. Practitioners should govern the agent as a distinct executor, not as an extension of a human seat.

Seat-based SaaS assumptions are already colliding with machine-majority usage. If agents become the primary consumers of applications, per-seat thinking will undercount exposure and overestimate human oversight. Access reviews, charging models, and entitlement design all assume a relatively stable human user population. That assumption weakens once machines become the dominant callers of enterprise systems. Practitioners should rework governance metrics around actions, tasks, and machine identities rather than only named users.

The strongest identity risk is not the sandbox itself but the identity sprawl that follows it. An agent with a dedicated computer often needs separate accounts, unique tokens, and cross-system permissions to function convincingly. Each of those artifacts extends the lifecycle burden. The practical consequence is that machine identity hygiene, offboarding discipline, and observable privilege boundaries become central to agent governance. Practitioners should plan for identity proliferation as a design outcome, not an exception.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a wider view of why machine identity lifecycle discipline matters, see 52 NHI Breaches Analysis.

What this signals

Delegated work identity will become a core governance concept as agents begin to operate under credentials that are not meant to represent a person. That means programme owners should start classifying agent access as a distinct executor pattern with its own ownership, lifecycle, and audit requirements.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, machine-scale identity growth will expose weak entitlement hygiene quickly. Teams that can still name every non-human executor and its account path will adapt faster than those relying on seat-based reporting.

Identity and access teams should expect agent populations to pressure offboarding, recertification, and logging first. The practical signal is not whether agents exist, but whether the organisation can prove which tasks they performed, which systems they touched, and which credentials were revoked when they were done.

For practitioners

• Define a separate agent identity model Create a policy class for AI agents that distinguishes them from humans and from classic service accounts. Specify who owns the agent, what systems it can reach, and what evidence is required before it receives access.
• Scope permissions to tasks, not roles Replace broad standing entitlements with task-scoped permissions that expire when the agent finishes a discrete job. Tie approval, logging, and revocation to the task lifecycle rather than to the account alone.
• Instrument the sandbox as part of the control plane Treat the agent's sandbox, browser session, and internal tool access as one governed execution surface. Require logging that shows when the agent entered the environment, what it touched, and which credentials it used.
• Build machine-offboarding into lifecycle processes When an agent is retired, revoke its accounts, tokens, and environment access together. Include its sandbox, its secondary accounts, and any delegated integrations in the offboarding checklist.

Key takeaways

• AI agents that receive their own sandboxes and accounts stop behaving like simple integrations and start creating a broader machine-identity governance problem.
• Machine-majority consumption will expose the limits of seat-based access models, especially where lifecycle controls and accountability still assume human users.
• Identity teams should define agent-specific ownership, task scope, and offboarding before non-human access becomes too large to manage manually.

Key terms

• Agent Identity: An agent identity is the set of accounts, credentials, and permissions assigned to an AI system so it can act in enterprise environments. In practice, it should be governed as a distinct executor with clear ownership, task scope, and revocation rules, not as an extension of a human user.
• Sandbox: A sandbox is a controlled execution environment that isolates an agent's runtime from the rest of the estate while still allowing defined actions and tool use. For identity teams, the sandbox is part of the trust boundary because it carries the agent's access, state, and audit trail.
• Delegation Chain: A delegation chain is the sequence of identities, accounts, and permissions that lets one actor operate through another. For AI agents, the chain may include human sponsors, service credentials, and tool access, which makes ownership and offboarding harder unless the full chain is mapped.

Deepen your knowledge

AI agent identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are preparing for machine-majority access patterns, it is worth exploring.

This post draws on content published by WorkOS: Composable computers for agents, a conversation with Daytona CEO Ivan Burazin. Read the original.