bolt.diy scans need a workspace and provider-key review
bolt.diy is an AI-assisted development environment that can connect to many model providers and use browser-based project execution. Access credentials extend beyond the application's login. Provider API keys, source-control tokens and generated code all sit inside the development boundary.
A small and ambiguous scan result
On 2026-11-07 UTC, page-one count-only ZoomEye probes with sub_type=all returned zero for app="bolt.diy" and five for title="bolt.diy". The sample is small. Each title match should be reviewed for ownership, deployment purpose and whether the page is an actual interactive workspace rather than a documentation page.
The lack of an application fingerprint is expected for a development tool that can be served under many hostnames and reverse-proxy configurations. A zero application count does not support a conclusion that the software is unused.
Map the two credential planes
The first plane is access to the bolt.diy instance. The reviewed documentation centers on local setup, provider configuration and server endpoint authentication. An organization that exposes the tool beyond one trusted machine needs an explicit access layer, such as an identity-aware proxy, network allowlist or an application session control it has verified.
The second plane is outbound authority. The environment can hold provider keys and a GitHub API token. Those credentials let the tool call external services and, depending on scopes, read or modify repositories. Keep development and production API keys separate, use the smallest token scopes available and rotate any key placed in a shared environment file.
Review WebContainer and server-side execution separately from the model prompt. Generated code is untrusted content that may execute in a browser sandbox or a server process. Confirm which commands can run, where files persist and whether a user can reach an internal network from the execution environment.
Make the inventory useful
Record owner, hostname, access method, provider keys by label rather than value, repository permissions and whether project data persists. Test an unauthenticated request, a request with a read-only user if supported, and a request after key rotation.
For each candidate host, compare the scan result with the organization's DNS and cloud inventory. Do not send active probes to hosts that are not owned by the organization.
The count identifies a very small candidate set. The security decision comes from the workspace, outbound credentials and the code-execution path.
Top comments (0)