Give AI Agents a Safe Workspace Before Giving Them Business Access
By Hexagon IT Solutions Content Team · October 16, 2026
An AI agent that runs code needs two separate controls: a contained place to work and explicit limits on what it can do to business systems. A sandbox addresses the execution environment. Your application still has to decide which records the agent may read, which changes require approval, and how a failed job is recovered.
That distinction matters following Perplexity’s October 15, 2026 announcement that it is open-sourcing SPACE, the sandbox platform behind Computer. The company’s official blog index dates the announcement to October 15; it does not establish an exact publication time in Mountain Time. SPACE is an infrastructure development, not evidence that any particular company’s AI workflow is safe to deploy. Perplexity announcement · Official dated index
What SPACE adds, and what your application still owns
SPACE runs code in isolated Firecracker microVMs. Applications use its HTTP API to create environments, execute commands, collect results, and manage the environments’ lifecycle. The project is available under Apache 2.0. Its value is a reusable execution layer, rather than a complete business application. SPACE repository
Perplexity describes the sandbox as untrusted, with network access and platform-held credentials managed outside it. That is a useful architectural boundary. It is not a promise that generated code is correct, that every deployment has the right network policy, or that an agent should be allowed to update your ERP. Perplexity announcement
For a business implementation, separate three questions: Where can the code run? What information can it obtain? What consequences can its output trigger? Answering the first does not settle the other two.
Start with an exception report, not an autonomous transaction
Consider a proposed pilot for an operations team that compares open purchase orders with shipment updates. This is an illustrative design, not a customer case study.
The agent’s assignment is to produce a reviewable exception report: which orders appear delayed, which references do not match, and which records need investigation. It should not change a promised delivery date, cancel a purchase order, or contact a supplier during the pilot.
The inputs are deliberately narrow: order identifier, item identifier, ordered quantity, expected date, shipment reference, shipped quantity, and source timestamp. Exclude supplier banking details and unrelated employee or customer information. Agree on timezone, units, partial-shipment rules, and the authoritative source for each field before writing the agent prompt.
Keep the first workflow small enough that an operations owner can check its output against the same source files. If the team cannot explain what counts as a discrepancy, the immediate work is process definition rather than more autonomy.
Design the handoffs before connecting live systems
A practical implementation can use five components:
- An intake service receives an approved request, checks the requester’s access, and assigns a job identifier.
- A data adapter prepares the permitted order and shipment fields, preserving source identifiers and extraction timestamps.
- An isolated execution workspace runs the analysis against that bounded input package.
- A result validator checks the output format, required references, totals, and missing-data flags.
- A review screen presents each exception with its evidence and lets an authorized person accept, reject, or request another analysis.
Keep the analysis artifact separate from the operational record. A line in a generated report should never become an ERP update merely because the model described it confidently. If write-back is added later, give it its own service, authorization check, change preview, and confirmation record.
This is where API and system integration work becomes as important as model selection: record identity, stale data, retries, and permissions determine whether the result reaches the right place.
Implement the job lifecycle explicitly
SPACE’s architecture documentation distinguishes a sandbox, an asynchronous lifecycle operation, and a command session. An accepted creation request is not proof that execution is ready. The documented sequence waits for successful operation completion, a running sandbox, and a reachable process endpoint. Attaching to a command session starts its process; finishing the command does not delete the sandbox. SPACE architecture
Translate those distinctions into visible application states: requested, preparing, running, validating, awaiting review, failed, and cleaned up. Store the job identifier alongside infrastructure identifiers so support staff can find a stalled run without asking the model what happened.
Treat a dropped output connection as an uncertain result until the application checks the existing job. Re-running the entire workflow blindly can duplicate reports or, after write-back is introduced, duplicate business actions. Define which operations are safe to repeat and how an existing result is recognized.
Export the accepted report to approved business storage before cleanup. Set a retention rule for input copies, intermediate files, logs, and snapshots. Pausing execution is not a substitute for a retention policy; SPACE specifically distinguishes resident paused state from a suspended snapshot. SPACE architecture
Keep authority outside the model
OWASP identifies excessive functionality, permissions, and autonomy as causes of excessive agency. Its guidance recommends narrow tools, least-privilege access, downstream authorization, and human approval for high-impact actions. These are application responsibilities, even when the execution runtime is isolated. OWASP: Excessive Agency
For the purchase-order pilot, the model should receive no supplier-payment capability and no general-purpose ERP administrator connection. The result viewer should enforce the reviewer’s access to the underlying orders. A report containing an unauthorized order must fail validation rather than becoming visible because it arrived in a generated file.
Also decide how external text is treated. A supplier note is evidence to analyze, not authority to change the workflow. Test documents containing instructions that conflict with the assigned task, and verify that controls outside the model still prevent unauthorized actions.
Check the operating requirements before committing
SPACE’s documented local installation requires an appropriate Linux x86_64 host with KVM, device access, btrfs support, and Docker capable of privileged containers. Those instructions do not run directly on macOS. The local setup also uses development credentials and explicitly warns against production credentials. A successful development install is therefore not a production security review. Installation guide
The versioning documentation identifies 0.8.0 as the public baseline and allows breaking changes before 1.0. Pin and record the version evaluated, assign upgrade ownership, and test recovery with the actual templates and stored state your application uses. Versioning guide
Before approving a pilot budget, include infrastructure operations, monitoring, incident response, model usage, review time, and maintenance. Open-source licensing does not eliminate those costs.
Measure whether the workflow earns more responsibility
Create a reference set that includes normal deliveries, partial shipments, missing references, duplicate inputs, and contradictory dates. Have the operations owner establish the expected result before assessing the agent.
Measure exception precision, missed exceptions, human correction time, end-to-end turnaround, cost per accepted report, and failed-job recovery. Track authorization violations and incomplete cleanup separately from answer quality. These are proposed evaluation measures, not claimed results.
Define acceptance thresholds before the pilot begins. Require every reported exception to link to its source record, every failed run to have an owner, and every proposed business change to remain reviewable. Expand to a second workflow only when the first demonstrates useful results and controllable failures.
For help mapping that boundary, discuss an AI workflow with Hexagon IT Solutions. Start with one operational problem, its data sources, and the actions your team is prepared to delegate. Our business automation approach begins with workflow ownership, rules, exceptions, and monitoring.
Frequently asked questions
Does an AI sandbox prevent every security problem?
No. It provides an execution boundary. Business permissions, data handling, network configuration, output validation, and operational monitoring still need separate design and testing.
Should a first pilot connect directly to production systems?
Prefer a bounded, approved input set and reviewable outputs first. If live reads are necessary, restrict the data and account permissions to that workflow. Introduce writes only after a separate authorization and failure-recovery review.
What should happen when an agent job times out?
Check the recorded job and infrastructure state before retrying. A timeout may mean the caller stopped waiting while work continues. Recover an existing result where possible and prevent duplicate downstream actions.
Is SPACE a replacement for a workflow engine?
No. SPACE manages execution environments and command lifecycles. Your application still needs business routing, approval rules, record-level access, result validation, and a clear owner for exceptions.
