Steel Browser
Security checks across malware telemetry and agentic risk
Overview
Steel Browser mostly matches its stated cloud-browser purpose, but its shell wrappers unsafely insert selectors, URLs, and text into Python code, so crafted inputs could run local code.
Install only if you need Steel.dev cloud browser automation and are comfortable with the provider handling your browsing session. Before allowing autonomous use, patch or avoid the unsafe wrappers, manually review selectors/URLs/text passed to scripts, provide STEEL_API_KEY carefully, use proxy/CAPTCHA features only with authorization, and release sessions when finished.
VirusTotal
64/64 vendors flagged this skill as clean.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A malicious webpage or unreviewed agent decision could turn a crafted argument into code running on the user's machine, potentially accessing local files or environment variables such as STEEL_API_KEY.
The unquoted here-doc expands $SELECTOR directly into Python source. A selector containing triple quotes and Python statements could break out of the intended string and execute local Python; similar interpolation patterns appear across other wrappers for URLs, text, JavaScript, and file paths.
python3 - <<PYEOF ... page.click("""$SELECTOR""")Do not let the agent pass untrusted or page-derived arguments until this is fixed. Rewrite wrappers to pass arguments via argparse, stdin, or JSON/environment variables to static Python code, and avoid expanding user values inside executable source.
The agent can browse, click, type, submit forms, and use proxy/CAPTCHA features; misuse could violate site rules or perform unintended actions on websites.
The skill explicitly supports broad browser automation with optional proxy and CAPTCHA-solving features. This is disclosed and aligned with the browser-automation purpose, but it can affect third-party sites and accounts if used without clear user limits.
# 1. Start session (add --proxy --captcha for tough sites)
Use the skill only for authorized automation, and require explicit user confirmation before logins, purchases, account changes, form submissions, CAPTCHA solving, or proxy use.
Installing users must provide a Steel API key, and any local code-execution issue in the wrappers could expose that environment variable.
The code requires a Steel API key even though registry metadata declares no required environment variables or primary credential. The credential use is expected for Steel.dev, but users should be aware of the undeclared requirement.
api_key = os.environ.get("STEEL_API_KEY") ... client = Steel(steel_api_key=api_key)Declare STEEL_API_KEY in metadata and keep the key scoped, rotated, and separate from unrelated credentials.
Future dependency changes could affect behavior or security, and reproducibility is weaker without pinned versions.
The setup step installs unpinned Python packages. This is a normal, user-directed dependency install for the stated purpose, but versions and provenance are not locked by an install spec.
pip install steel-sdk playwright
Pin dependency versions or provide a reviewed install spec/lockfile.
Sensitive pages, screenshots, typed data, or authenticated browsing activity may be visible to or processed by the cloud browser provider.
Browser control is routed through Steel.dev's remote CDP endpoint. This provider flow is expected for a cloud-browser skill, but it means browsing activity and session data are handled outside the local machine.
connect_over_cdp(f"wss://connect.steel.dev?apiKey={api_key}&sessionId={session_id}")Avoid using the skill on sensitive accounts unless the Steel.dev trust model is acceptable, and review provider privacy/security terms.
A browser session may remain active after a task, potentially retaining logged-in state or incurring provider usage until released or timed out.
The skill intentionally stores session state and keeps cloud browser sessions alive. This persistence is disclosed and purpose-aligned, but users need to manage cleanup.
`start_session.sh` saves session ID to `~/.steel_state` ... Sessions persist until `release_session.sh` or timeout
Run release_session.sh after each task, avoid leaving sensitive sites logged in, and remove ~/.steel_state if the session should no longer be reused.