Windmill discovery must follow workspace tokens into execution authority
Windmill runs scripts and flows and exposes a web console and API for managing them. A workspace may contain credentials, schedules, jobs, and code that can act on external systems. Discovering a Windmill page is only useful when the owner can map the URL to a workspace and the tokens that authorize its operations.
A count-only ZoomEye measurement on 2026-10-29 returned 2,507 matches for title="Windmill" and 3 for app="Windmill". Both used sub_type=all, page 1, and page size 1. The title result is larger and selected for discovery. It can include unrelated pages, documentation, or pages that mention the product. The application match is much smaller and does not prove that the title set is Windmill.
Treat workspace tokens as privileges
Windmill documentation describes user tokens that use bearer authentication and can be limited to specific scopes. A token created with full access may be able to exercise more workspace operations than a script or integration needs. Store tokens for CI, scheduled jobs, and service integrations separately, and set a review date.
The workspace is the main boundary for jobs and scripts. For each workspace, list who can create, edit, run, and schedule work. Check whether a run executes with the runner's identity or an explicitly configured user and scope. Windmill's role and permission documentation describes built-in roles, folder-level ACLs, and run-on-behalf settings. Those details matter because a user who cannot edit a script may still be able to start a privileged run.
Review secrets and variables exposed to scripts. A flow step that calls a cloud API should use the smallest credential that can perform its task. Do not give a shared workspace token to every bot or automation. Use separate tokens for read-only monitoring, deployment, and emergency administration.
Separate title evidence from product evidence
The title query is broad. A candidate needs an owned domain or an additional product clue before an analyst treats it as a Windmill instance. The application query returned three matches, which is useful for validating the fingerprint but does not set the population used in the title measurement. Keep both observations and their exact scope.
For an owned instance, confirm which network can reach the web console and which can reach the worker or agent. A reverse proxy may publish the UI while keeping the execution backend internal. Test login, token revocation, scheduled jobs, and API calls separately. A browser session expiring does not necessarily invalidate a long-lived workspace token.
Review script and flow trust. A user who can submit arbitrary code can use any credential available to the runner. Restrict script creation to approved roles, pin imports and dependencies, and review code changes with the same care as production deployment. A flow that runs on a schedule should have an owner and an alert if it starts failing repeatedly.
Build a compact control inventory
For every workspace, record:
- Public and internal URLs.
- Authentication provider and administrator group.
- Role assignments for create, edit, run, and admin actions.
- Token scopes, owners, and expiry.
- Secrets available to scripts and the environments they can reach.
- Audit and job-history retention.
Then test the actual boundaries. Use a low-privilege token to edit another user's script, start a privileged flow, and read secret metadata. Use a token from the wrong workspace against the API. Rotate a key and confirm the old token fails within the documented window. These tests produce more useful evidence than the external match count.
Windmill's search result is a discovery lead. The operational review decides whether workspace membership, token scope, and run identity keep each automation inside its intended authority.
Top comments (0)