Where Secure Agent Workspace Fits

Table 2: Where Secure Agent Workspace Fits

Need	Right home	Why
Day-to-day non-autonomous development	Local endpoint	Lowest latency, full editor control, fully offline-capable.
OSS / public-data work needing wide public-internet reach	Secure Agent Workspace - public profile	Intentionally outside the enterprise allowlist; i.e. no access to corpnet.
Higher-autonomy agentic dev with internal-service dependencies and long sessions	Secure Agent Workspace - corporate profile	Approved autonomy substrate; allowlisted internal reach; persistent personal workspace.
Hosting a service for other users to consume	Service-hosting platform	Multi-user serving and productionization concerns.

The corporate vs public split maps onto the Capability Risk Model (the “Rule of Three” / lethal trifecta): agent risk compounds when three capabilities combine — (a) access to internal data or secrets, (b) nondeterministic autonomy, and (c) external data access. Leg (c) is presumptively read/write: an outbound “read” is also an exfiltration channel, so ingress of untrusted content and the exfiltration path are the same leg. Because agentic autonomy (b) is the whole point, the practical rule reduces to: do not mix internal and external data access in the same agentic context. The two profiles apply that rule differently:

• Corporate profile — intentionally accepts the mix. Internal-service work needs internal data (a) and some external reach (c) under autonomy (b), so the corporate profile cannot defang the trifecta by removing a leg. It instead bounds leg (c) to the narrowest defensible surface — an egress allowlist, brokered network path, credential proxy, and human review on writes — and relies on these hard, deterministic controls, exactly as the Capability Risk Model prescribes when the legs cannot be separated.

• Public profile — honors the rule by separation. It removes leg (a): no access to private data (intentionally outside the enterprise allowlist). With nothing internal in context, untrusted external data and outbound reach carry no enterprise exfiltration or integrity risk.

Bounding a leg reduces but does not eliminate risk: it constrains the exfiltration channel without by itself stopping other harmful actions — destructive writes, DoS on internal systems, hallucinations. Those are addressed by the write-review gate, runtime sandbox, and signed policy elsewhere in this design.

Profile selection starts from data classification. Which data classes an agent may handle determines whether it belongs in the corporate profile (allowlisted internal reach) or the public profile (no access to private data). A published data-classification policy is therefore a precondition to turning autonomous agents on — it is the input every downstream control resolves against: where data may travel (the egress allowlist and routed inference) and which reads and writes require human review.

Regulated profile. Shorthand for a workload under data-residency or sovereignty constraints — data that cannot leave the host, and a host operator that sits outside the workload’s trust boundary. It is a constraint on where data and credentials may reside, not a claim of conformance to any specific regime; mapping it to a given legal or contractual obligation is the enterprise’s call.

Three Timescales of Sandbox Lifecycle

Different workloads need different sandbox lifetimes. The Secure Agent Workspace pattern accommodates all three with a single architecture:

Table 3: Three Timescales of Sandbox Lifecycle

Timescale	Home in Secure Agent Workspace	Example workloads
Long-running (days / weeks) — persistent filesystem, persistent agent state	The Secure Agent Workspace VM itself	Always-on personal assistant, long alpha-research loop, multi-day refactor
Per-session (minutes / hours) — ephemeral filesystem reset between sessions	OpenShell sandbox inside the VM	Coding agent run, document-drafting task, triage burst
Per-command (ms / s) — clean state on each tool call	OpenShell Drivers per-call ephemeral pod	High-trust tool execution (untrusted code review, exfil-risky operations), red-team / eval harness

The user/sponsor, workspace and logical-agent identities — plus the signed-policy and audit pipelines — span all three timescales. Only the short-lived runtime credential is minted fresh per-call, bound back to the same user/sponsor, workspace and local agent registration.