Skillv0.1.0

ClawScan security

Secure Autofill · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousFeb 22, 2026, 6:03 AM

Verdict: suspicious
Confidence: medium
Model: gpt-5-mini
Summary: The skill's behavior (onboarding script and SKILL.md) is broadly consistent with a 1Password-backed autofill tool, but the registry metadata omits the sensitive environment usage and the skill instructs editing your gateway env and restarting services — that mismatch and the token-handling deserve caution.
Guidance: Before installing or running this skill: - Treat OP_SERVICE_ACCOUNT_TOKEN as a sensitive secret. Do not paste it into chat. Prefer creating a least-privileged 1Password service account/token for this use. - The metadata claims no required env vars but the skill will prompt to write OP_SERVICE_ACCOUNT_TOKEN (and DISPLAY/WAYLAND_DISPLAY) into a skill-local config and optionally into your gateway env (~/.config/openclaw/env). This is a material mismatch — expect the gateway process to gain access to the token if you allow copying. - The onboarding script can restart your openclaw-gateway systemd user service; only proceed if you understand and trust that service. - Verify the presence and provenance of the external tools the skill depends on (vault_suggest, vault_fill) and confirm they are allowed in your tool allowlist before enabling them. - Review the included onboard.sh yourself (it's short and readable) and run it manually in a terminal rather than letting an automated agent perform the onboarding. - If you decide to proceed, restrict file permissions on any env file that contains the OP token, and consider not copying the token into the gateway env (use skill-local config) unless necessary. Given the metadata mismatch around required environment access and the sensitive token handling, proceed only after manual review and applying the least-privilege principles.

Review Dimensions

Purpose & Capability: concernName/description claim 1Password-backed autofill; included files (SKILL.md + onboard.sh) implement exactly that. However registry metadata declares no required env or primary credential while the runtime docs and script clearly expect/handle OP_SERVICE_ACCOUNT_TOKEN and gateway env updates. The missing declaration is an incoherence that affects trust decisions.
Instruction Scope: noteInstructions ask the operator/agent to write machine-local and gateway env files, optionally copy OP_SERVICE_ACCOUNT_TOKEN into the gateway env, modify tool allowlists, and restart the openclaw-gateway systemd user service. These actions are within the scope needed to enable a plugin that types secrets into the browser, but they involve modifying user config and restarting services and therefore touch sensitive local state.
Install Mechanism: okThere is no network install/download; the skill is instruction-first and ships a small onboarding script. No remote archives, URLs to execute, or package installs are performed by the skill itself (the SKILL.md suggests manually installing Chrome from Google's apt repo, which is a standard, explicit step).
Credentials: concernFunctionality legitimately needs a 1Password service token (OP_SERVICE_ACCOUNT_TOKEN) and display-related env vars, but the skill metadata lists no required env vars. The onboarding script will propose copying the OP token into a gateway env file and the gateway process would therefore gain access to it; this is sensitive and should be explicitly declared and justified in metadata. Ensure principle of least privilege for any token used.
Persistence & Privilege: noteThe skill does not request always:true and won't install persistent binaries. It does instruct optionally modifying the gateway env and restarting the openclaw-gateway user service so the gateway process can read the token — this grants the gateway process access to the secret and increases blast radius if the gateway is compromised. That behavior is plausible for the stated purpose but worth deliberate consent.