AWS Builder Center
Your Employees Are Already Testing AI Tools on Their Laptops. Give Them a Disposable Sandbox Instead.

Your Employees Are Already Testing AI Tools on Their Laptops. Give Them a Disposable Sandbox Instead.

Open-source AI tooling is showing up on corporate laptops. Here is a reusable AWS pattern for moving exploration into disposable, budget-capped accounts with per-user Amazon Bedrock cost attribution. Co-authored with Ayu Shah, Senior Solutions Architect. DISCLAIMER: Opinions are my own and don't represent my employer.

Customer Solutions Manager
Most enterprise AI policies tell engineers to not use unapproved tools on corporate devices. Meanwhile, engineers are cloning open-source MCP servers and wiring coding assistants to frontier models on their laptops that have access to company IP and sensitive materials. They aren't being reckless. The tools change every week, and the only way to know whether one is useful is to try it. Blocking exploration doesn't stop it. It just moves it somewhere you can't see.
Earlier this year, Ayu Shah (Solutions Architect) and I worked with an enterprise customer facing this scenario. Their ask:
  1. Give people a safe place to try AI tools
  1. Isolate it from the corporate network
  1. Cap the spend
  1. Show a spend breakdown per user, per project, per tool
This post describes the pattern we proposed. You can reuse it for enterprise customers where AI curiosity is outpacing AI governance.

What the environment has to do

Requirement
In practice
Isolation
Nothing experimental runs locally on the laptop or reaches the corporate network
Cost control
Hard spend limits per environment, with alerts before the limit
Cost attribution
Usage broken down by person, team, project, and tool
Self-service
Users request an environment in minutes, with automatic approval rules built in
Ephemeral by default
Environments expire and are wiped automatically
Promotion path
Validated tools can move into formal security review

The pattern

Three existing AWS capabilities cover most of this. A fourth piece is custom.
Building block
Role
Innovation Sandbox on AWS
Temporary, isolated AWS accounts with budgets, time limits, and automatic cleanup
Amazon WorkSpaces Applications (formerly AppStream 2.0)
Non-persistent streaming desktop, so experimental tools never touch the enterprise laptop
Amazon Bedrock IAM principal cost allocation
Attributes Bedrock spend to the person or role behind each call
Exploration to approval workflow (custom)
Promote a validated tool set into an approved enterprise standard
Plain text
Employee laptop (browser or streaming client only)
│
▼
┌──────────────────────────────────────────────┐
│ Amazon WorkSpaces Applications fleet │
│ Non-persistent desktop, curated image │
│ Clipboard, file transfer, printing off │
└─────────────────────┬────────────────────────┘
│ IAM Identity Center
▼
┌──────────────────────────────────────────────┐
│ Innovation Sandbox on AWS (hub account) │
│ Lease templates, approvals, blueprints │
│ Budget and duration thresholds, cleanup │
└─────────────────────┬────────────────────────┘
┌──────────┼──────────┐
▼ ▼ ▼
Sandbox Sandbox Sandbox (SCP-bounded)
└──────► Amazon Bedrock ◄─────┘
│
▼
Caller identity + IAM principal tags
→ AWS Cost Explorer and CUR 2.0

The flow

  1. A user signs in with their corporate identity
  1. Picks a lease template (for example, “AI exploration, 8 hours, small budget”)
  1. Gets a pre-provisioned sandbox account
  1. They open a streaming desktop, do all their experimenting there, and call Bedrock from the leased account
  1. Every call is attributed to their identity
  1. When the lease hits its budget or time limit, the account is cleaned and returned to the pool.

Innovation Sandbox on AWS

 Innovation Sandbox on AWS  is an open-source AWS Solution that manages a pool of temporary accounts inside AWS Organizations. It was built for training and hackathons, but its controls map almost one to one onto AI exploration.
  1. Leases assign an account to a user (or a shared team) for a set budget, duration, or both.
  1. Lease templates encode policy: approval rules, thresholds, and what happens when a threshold is crossed. Auto-approve small, short leases; route bigger ones to a manager.
  1. Blueprints are CloudFormation StackSets deployed into each account at lease time, so users start with Bedrock access, a results bucket, and logging already in place.
  1. Service control policies bound which services and Regions sandbox users can touch.
  1. Cleanup runs AWS Nuke when a lease ends. If validation fails, the account is quarantined instead of recycled.
The solution is free. You pay for what it deploys and what users run. It requires AWS Organizations and IAM Identity Center.

Amazon WorkSpaces Applications

Isolated accounts don't help if the untrusted MCP server still runs on the laptop. WorkSpaces Applications streams a desktop from AWS instead. Sessions are non-persistent, so the instance disappears when the user is done. Stack settings turn off clipboard, file transfer, and printing to the local device. You maintain one custom image with the tools people ask for (an IDE, Jupyter, a coding assistant, vetted MCP servers). It supports elastic fleets that suit bursty exploration patterns. See the  pricing page  for current rates.

Bedrock cost attribution by IAM principal

Bedrock now records the IAM identity behind each inference call and passes it to Cost Explorer and CUR 2.0, with no change to your API calls. Tag the calling users and roles (team, project, cost center), activate those tags as cost allocation tags, and include caller identity data in a CUR 2.0 export. Bear in mind that tags only appear for activation after the principal makes a Bedrock call, and activation can take up to a day or two. The finest grain is per usage type per day, not per request. Details are in the  Bedrock user guide . The lease budget is the guardrail that stops a runaway sandbox. Principal attribution is the ledger that tells you who drove the spend.

The custom piece: exploration to approval

This is the part customers get most excited about. Users try an open-source MCP server in their sandbox, submit it for review if it works, and approved servers go into the internal registry everyone installs from. The organization finally gets a visible “exploration in progress” list. Innovation Sandbox publishes lease lifecycle events to Amazon EventBridge, which you can route into a review workflow (for example, AWS Step Functions plus a tracking table).

Decisions you'll have to make

  • Air gap or controlled egress. A VPC with no internet gateway is the strongest posture, but users can't pull a new tool from a public repository. Either pre-stage packages in the image or an internal artifact repository, or allow egress through a domain allow-list.
  • Understand and define who the users are. Streaming desktops with Jupyter suit engineers. Our customer's main audience were power users one step below that, so images and blueprints have to do more of the work for them.
  • Desktop or headless. R&D and data science teams running automated evaluation loops may not need a desktop at all. They need isolated accounts with stable, role-based Bedrock access. Same foundation, minus the streaming layer.
  • What survives cleanup. Everything is deleted when a lease ends. Decide upfront if there are assets you want to keep.

Where this applies

Scenario
Why it fits
Regulated industries
Isolation and per-user attribution satisfy security and audit
Firms with sensitive IP
Experimental tools never run on devices holding designs or customer data
“No AI tools on laptops” policies
A sanctioned place to explore instead of a reason to work around policy
Hackathons and AI enablement
Time-boxed accounts that clean themselves up
Tool and vendor evaluations
Side-by-side tests under identical conditions
R&D and data science labs
Headless experiments separated from production

Getting started

Roll it out in phases where each delivers value on its own:
  1. Deploy Innovation Sandbox in a non-production organization, with one lease template and one blueprint for AI exploration.
  1. Build a WorkSpaces Applications image with the three or four tools your users ask for most.
  1. Turn on Bedrock IAM principal attribution and tag your roles.
  1. Pilot with a small group.
  1. Add agent hosting and the approval workflow once the basics work.
  1. Set alert thresholds well below hard limits, since cost data lags usage, and assign someone to own the image.

Conclusion

You can't stop people from exploring AI tools, and you shouldn't want to. Give them a better place to do it: isolated from the corporate network, capped in cost, attributed to a person, and cleaned up automatically. None of these building blocks are new. The value is in assembling them so security, finance, and builders all get what they need from one environment.



DISCLAIMER: Opinions are my own and don't represent my employer.

AWS services and AI tooling change quickly. Check the linked documentation for current features, limits, and pricing before you build.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article