A coding agent with a shell can do a lot of damage if it is mistaken or manipulated. Sandboxing limits what it can reach.
Why it needs boundaries
The agent may read untrusted content, such as an issue description or a dependency's documentation, that contains instructions meant to hijack it. It may also simply make a destructive mistake.
Filesystem controls
Restrict the agent to the project directory. Keep credentials, signing keys, and personal files outside its reach. Use version control so every change can be reviewed and reverted.
Command controls
Allow a defined set of commands, such as Gradle tasks and test runners. Require approval for anything else, especially deletion, network downloads, or package installation. Avoid giving the agent a broad shell with the developer's full permissions.
Network and dependencies
Limit outbound connections. Pin dependency versions and review additions, since an agent might add a malicious or mistyped package.
Secrets and audit
Never place secrets in the agent's context or in files it can read. Log commands and file changes so you can audit what happened.
Layered approach
Combine technical limits, such as containers or restricted user accounts, with process limits like code review. Do not rely on telling the model to "be careful".
Takeaway
Assume the agent will occasionally be wrong or deceived, and design so the consequences stay small.
Continue with the book
Explore the full treatment, worked examples, and exercises in Agentic Android App Development.
Adapted from Agentic Android App Development, published by Choral Software. Article text and original examples © 2026 Choral Software. All rights reserved.