AI-Assisted Secure Coding (Appendix C) · AI Code-Review & Assistant Bot Hardening
Sandbox review bots
Verify that AI review and assistant bots run in network-isolated, least-privilege sandboxes: a dedicated namespace, default-deny egress with an allow-list to approved APIs only, no mounted repository secrets, and ephemeral credentials only.
OWASP AISVS v1.01, requirement AC.11.4
In plain English
Run review and assistant bots in an isolated, least-privilege sandbox. That means their own namespace, outbound traffic denied except to approved APIs, no repository secrets mounted and only short-lived credentials. Assume the bot will one day be successfully injected. The sandbox decides what the attacker gets.
What good looks like
- Each bot runs in a dedicated namespace or runtime, apart from other workloads.
- Egress is denied by default, with an allow-list of approved APIs only.
- No repository, organisation or cloud secrets are mounted in the bot's environment.
- The bot's credentials are ephemeral and narrowly scoped.
How teams usually do it
- Dedicated ephemeral runners or containers with network policies or an egress proxy.
- A read-only repository token for review, with write actions routed through a separate service (AC.11.5).
- Runner hardening tools that enforce egress allow-lists on CI jobs.
Suggested evidence
- Runtime and network configuration.
- The bot's token permissions.
- A test showing a blocked outbound request to an unapproved host.
Common mistakes
- Running the review bot on a shared CI runner that holds repository secrets.
- Open egress, so an injected bot can post what it reads to any website.
- A long-lived personal access token as the bot's credential.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.