A copy is safer than a writable mount, with a cost

The default backend uses Microsandbox and its libkrun-based microVMs. A normal acq run mounts the selected project into the guest. Version 3.1.0's --clone option instead creates a physical git clone --no-hardlinks under acq's host-side state directory and mounts that scratch copy read-write at the repository's original absolute path inside the guest.

The agent can edit this clone without changing the developer's working tree. To recover committed work, acq adds a host remote named sandbox-<name> and lets the developer fetch objects from the scratch repository. Git performs the transfer. A broad file copy could also bring hooks or unrelated configuration with it.

The boundary is honest about its losses. Uncommitted tracked changes, untracked files, and ignored files do not enter the clone. acq warns when the source tree is dirty. A documented race also remains if two processes create a sandbox with the same name: cleanup by the losing process can remove the winner's scratch directory.

This is not a replacement for Git worktrees. A worktree is useful when several trusted tasks need isolated branches with shared Git objects. The acq clone is for a different risk decision: give the guest a disposable copy and make committed state the return path.

Secrets stay outside the guest

The secret model avoids placing real credential values in the microVM. A user binds a host environment variable with --secret; the runtime substitutes the value into matching outbound requests. The guest sees the placeholder, not the credential itself.

Version 3.1.0 also changes how saved secrets reach macOS Keychain. Passing a password as a command argument can expose it through process inspection. The new implementation sends a security -i command stream through standard input. It rejects service and sandbox names outside [A-Za-z0-9_-]+, which prevents control characters from splitting that stream, and fails closed if a Keychain write fails on a capable host. The read path still supports older 0600 plaintext files until the user resaves or removes them.

The change closes one exposure path, but an authorized outbound request can still spend money, mutate a remote resource, or disclose data. Secret injection reduces guest exposure. Least privilege, rotation, audit logs, and agent tool permission checks still have to govern the remote service.

Network policy is a choice, not a property of the sandbox

acq offers strict, balanced, and open network tiers. balanced is the default. Both strict and balanced deny traffic unless policy permits it. Invalid tier values fail back to balanced. The open tier removes the restriction, requires ACQ_NETWORK_TIER_CONFIRM_OPEN=1, and is documented for testing rather than government-furnished equipment.

The open switch creates a more useful operational question: who may set it? If the automation that launches the agent can also select open, the network control is advisory. A deployment should enforce the allowed tier outside the session and record the effective policy with the run.

The same principle applies to the tool's bundled kits. The project's risk-assessment template says four kits are fetched from GSA-TTS/agentic-coding-patterns at pinned commit SHAs. A changed reference is reviewable, and SHA substitution is detectable. Creation still needs GitHub access, plus a token for the private playbook. In an offline or air-gapped environment, a sandbox can be created without the kits. Operators therefore need to verify the installed policy material, not infer its presence from a successful launch.

The documentation refuses to promote a demo into an approval

The repository classifies the quickstart for internal, non-sensitive local development on Low or Moderate-impact code and projects. It says the quickstart is not an authorized production or hosted environment and should not receive PII or CUI.

That caution matches GSA's broader AI strategy and compliance plan. USAi provides secure research and development workspaces, while production use cases go through governance, monitoring, periodic human review, and annual re-registration. The sandbox is one technical control within that process.

The project also ships a 62-item pre-deployment checklist. It requires a reviewer other than the person who directed the agent, and every failed item must be resolved. The checks cover code review, secrets, input and output handling, authorization, dependencies, logging, cryptography, APIs, testing, infrastructure, and accessibility.

The independent-review clause prevents containment from being mistaken for authority. Agents Shipgate draws the same boundary: an agent may prepare a change, while approval remains a separate action owned by someone accountable for the system.

Four checks before adopting acq

Asking whether acq is "secure" collapses several different decisions. Test each one instead.

1. For the workspace, decide whether a writable mount is acceptable or whether --clone is required. Test the dirty-tree warning and fetch-back workflow with a disposable repository.
2. Confirm that secrets remain outside the guest. Scope each remote credential to the smallest useful action, verify Keychain behavior on macOS, and remove legacy files after resaving.
3. Enforce the permitted egress tier outside the agent session. The run record should include the effective tier, destinations, and denied requests.
4. Treat authority as a separate control. Complete the risk assessment and pre-deployment checklist, name the independent reviewer, and keep deployment credentials outside the coding session.

This review examined the published release, repository code, and GSA documentation. It did not run an independent penetration test or security benchmark. At publication time, the README's pinned manual installer example still named v3.0.0, while the latest release was v3.1.0. An automated installer should verify the tag and checksum for the release it will deploy.

The microVM, cloned workspace, secret proxy, and deny-by-default network tiers can narrow an agent's blast radius. GSA's materials still require classification, review, and authorization around them. Treating the sandbox as the approval would remove the control that the documentation was careful to keep.