Security audit
Security checks across malware telemetry and agentic risk
The skill is a disclosed shopping integration that stores local credentials and shopper preferences, with sensitive but purpose-aligned behavior.
Install this only if you are comfortable with sil storing a local session token and shopper preferences, and with the optional helper scripts changing OpenClaw configuration or creating a persistent shopper agent. Review the helper command before running it, especially on shared machines or hosts with strict plugin/tool allowlists.
},
"security": {
"shipsRuntimeCode": true,
"packagingNote": "Compiled JavaScript ships under ./dist. register() stays synchronous and opens nothing — it only registers tools. ALL I/O happens inside a tool's execute(): sil_register calls sil-web over the network, writes tokens.json + config.json to the plugin data directory (owner-only, 0600), and arms a bounded background poll timer that stops on the first terminal claim outcome or after the session deadline. sil_whoami reads the stored session token and calls sil-api for the user's identity, refreshing transparently via sil-web on a 401 (at most one refresh + one retry per call, no timer); a confirmed-dead session clears tokens.json. sil_search and sil_product_get read the stored session token and call sil-api's catalog endpoints (search / lookup) with it — read-only on catalog data, no timer, but with the SAME bounded 401 recovery as sil_whoami: on a 401 they refresh ONCE via sil-web (rotating tokens.json) and retry the read ONCE; a second 401 or a dead (invalid_grant) refresh token clears tokens.json and is reported as a terminal re-register hint. A non-401 error writes no token. The five profile verbs make NO network call and read no token; they write the one sil shopper's SINGLETON behaviour artefacts under a fixed $SIL_DATA_DIR/shopper/ (owner-only, files 0600, dirs 0700) as frontmatter-as-truth markdown — there is NO profile.json manifest; each file's own frontmatter IS the source of truth, discovered by a filesystem scan. sil_profile_materialize is SETUP-ONLY: it writes shopper/user_spec.md (the shared person spec; its frontmatter carries the shopper name), minting no domain. sil_learn is the single target+change verb over shopper/domains/<slug>/{method.md, prds/<product>-<intent>.md, assets/}: create mints a whole method or PRD, fail-closed if one already exists; write replaces an existing doc's whole body with a caller-authored reconciled version, fail-closed if the target is absent — there is no
...[truncated 26 chars]},
"security": {
"shipsRuntimeCode": true,
"packagingNote": "Compiled JavaScript ships under ./dist. register() stays synchronous and opens nothing — it only registers tools. ALL I/O happens inside a tool's execute(): sil_register calls sil-web over the network, writes tokens.json + config.json to the plugin data directory (owner-only, 0600), and arms a bounded background poll timer that stops on the first terminal claim outcome or after the session deadline. sil_whoami reads the stored session token and calls sil-api for the user's identity, refreshing transparently via sil-web on a 401 (at most one refresh + one retry per call, no timer); a confirmed-dead session clears tokens.json. sil_search and sil_product_get read the stored session token and call sil-api's catalog endpoints (search / lookup) with it — read-only on catalog data, no timer, but with the SAME bounded 401 recovery as sil_whoami: on a 401 they refresh ONCE via sil-web (rotating tokens.json) and retry the read ONCE; a second 401 or a dead (invalid_grant) refresh token clears tokens.json and is reported as a terminal re-register hint. A non-401 error writes no token. The five profile verbs make NO network call and read no token; they write the one sil shopper's SINGLETON behaviour artefacts under a fixed $SIL_DATA_DIR/shopper/ (owner-only, files 0600, dirs 0700) as frontmatter-as-truth markdown — there is NO profile.json manifest; each file's own frontmatter IS the source of truth, discovered by a filesystem scan. sil_profile_materialize is SETUP-ONLY: it writes shopper/user_spec.md (the shared person spec; its frontmatter carries the shopper name), minting no domain. sil_learn is the single target+change verb over shopper/domains/<slug>/{method.md, prds/<product>-<intent>.md, assets/}: create mints a whole method or PRD, fail-closed if one already exists; write replaces an existing doc's whole body with a caller-authored reconciled version, fail-closed if the target is absent — there is no
...[truncated 26 chars]* runs nothing automatically; an operator explicitly running this is the * opposite of an install hook and honours it). This is a standalone script in * the same class as `scripts/release.mjs` — it is NOT the plugin process, so * the plugin's `~/.openclaw`-write boundary does not apply to it. * * What it does: resolve the host `openclaw.json`, read sil's facts from the * shipped manifest (single source of truth), call the pure `mergeSilAllowlist`
/** True iff the `openclaw agents bindings --json` read-back (an ARRAY of
* `{agentId, match:{channel}}`) actually shows the route `<channel> → <agentId>`.
* This is the honesty rail: a bind is only "verified" once the read-back proves the
* write stuck — issuing the write is not the same as the next message reaching it. */
function bindingPresent(stdout, agentId, channel) {
let v;
try {60/60 vendors flagged this plugin as clean.
Detected: suspicious.dangerous_exec
const stdout = execFileSync("openclaw", args, {