Notifications
Clear all
Topic starter
06/06/2026 2:27 am
TL;DR: AI agents are moving from API-only workflows to full computing environments, with Daytona CEO Ivan Burazin arguing that every agent will need its own sandbox, identity, and access surface as task complexity rises, according to WorkOS. The identity model shifts from seat-based software to machine-majority consumption, and that breaks assumptions about how access, accountability, and privilege are provisioned.
NHIMG editorial — based on content published by WorkOS: Composable computers for agents, a conversation with Daytona CEO Ivan Burazin
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Define a separate agent identity model Create a policy class for AI agents that distinguishes them from humans and from classic service accounts.
- Scope permissions to tasks, not roles Replace broad standing entitlements with task-scoped permissions that expire when the agent finishes a discrete job.
- 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.
What's in the full article
WorkOS's full article covers the conversational details this post intentionally leaves for the source:
- Burazin's full explanation of why he thinks agents need computers rather than API-only access
- The details of the 'human emulator' setup, including the agent's separate email, phone number, and internal accounts
- The discussion of how Daytona is positioning its product as agent infrastructure rather than a seat-based application
- The interview context from HumanX 2026 and the go-to-market story behind the pivot to sandboxes
👉 Read WorkOS's conversation with Daytona CEO Ivan Burazin on AI agent computers →
AI agents need their own computers, but what does that mean for IAM?
Explore further
06/06/2026 4:07 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Composable computers for AI agents and the new identity model
