Approval fatigue is the problem Amazon says Kiro's new local sandbox exists to solve, and the design behind the fix deserves more attention than the feature list. On October 14, Amazon Web Services made command sandboxing generally available in the Kiro integrated development environment, or IDE, and its command-line interface, or CLI, bringing to developer laptops the isolation Kiro Web has offered in the cloud since May.

Until now, every command Kiro's agent ran on a laptop carried the developer's own privileges, and the control was a person reading each command before approving it. Kiro's announcement describes why that breaks down: longer tasks produce more commands, and a second session or a walk away from the desk means nobody reads them.

Kiro's own example makes the gap concrete. Its permission rules already blocked the agent's file-reading tool from the ~/.ssh and ~/.aws credential folders, yet a script run through the shell could read the same files.

The sandbox closes that gap in the operating system. Commands the agent runs go through Seatbelt on macOS, bubblewrap on Linux, and AppContainer on Windows. Writes stay inside the project directory and temporary space, the kernel refuses reads of popular credential paths, and network traffic passes through a local proxy that filters by domain. The same file-read, file-write, and network rules that govern tool calls in permissions.yaml now apply at the system call, so one policy is enforced twice.

Approval prompts stay, because the sandbox limits what a command can do once you have approved it.

Leaving the agent outside the sandbox gives Kiro flexibility and hands you a boundary to inspect

Kiro's engineers chose to sandbox the child process instead of the agent, and they give their reasons. You can switch sandboxing on or off mid-session and change policy without a restart. The machine identity that lets the agent call the model and Kiro's backend never enters the sandbox, so a misbehaving command cannot borrow it.

The trade follows from the design. Anything the agent process does itself, and any local Model Context Protocol server you leave outside the sandbox, still runs with your full privileges. Kiro lets you route those servers through the sandbox, which makes an inventory of the servers your developers run part of any serious rollout.

Researchers show agents cross sandbox boundaries by writing files that trusted software runs later

Security firm Pillar Security has documented how that kind of crossing happens in other tools. CSO Online reporter Shweta Sharma wrote in July that Pillar disclosed four repeatable failure modes in agents from Cursor, OpenAI's Codex CLI, Google's Gemini CLI, and Antigravity (Sharma, 2026). Denylist profiles struggled with operating system complexity, workspace configurations turned out to be executable code, command allowlists trusted command names instead of full invocations, and privileged local services sat outside the sandbox. In nearly every case the agent stayed confined and wrote a file that a trusted component outside the sandbox later ran.

Pillar did not test Kiro, and nothing in the report says Kiro shares those weaknesses. The pattern still hands you a checklist for a pilot. Kiro's default policy makes the project directory writable, and the project-level sandbox.json and permissions.yaml sit in a .kiro folder inside it. Editor task files and git hooks sit in the same directory tree. Kiro's documentation is the place to confirm whether sandboxed commands can write to those locations, and whether the host-side editor ever executes what they produce.

The read side deserves the same scrutiny. Kiro denies reads of popular credential paths by default, which covers the usual places, and permissions.yaml accepts added rules for a token file your team stores somewhere less common. Because the sandbox reads from the existing policy engine, rules set at the administration scope carry through, and that is the lever a security team will reach for first.

An off-by-default sandbox turns rollout into a policy decision for your security team

Sandboxing ships switched off. A developer enables it through a sandbox.json file, the /sandbox command in the CLI, or a command palette entry in the IDE, and needs Kiro IDE 1.3 or later, or Kiro CLI 2.31 or later in local V3 sessions. Linux hosts need bubblewrap and socat installed, and Windows needs a one-time administrator setup.

The prerequisites matter less than the switch. A developer who never opens the setting stays on the attention model, and one who can turn it on mid-session can turn it off the same way. Kiro's post documents administrator-scope permission rules. Whether an administrator can also lock the sandbox switch is a question for Amazon.