Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add ShieldNet-360/secure-vibe --skill electron-securitygit clone --depth 1 https://github.com/ShieldNet-360/secure-vibeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/shieldnet-360/secure-vibe/electron-security)<a href="https://agentmods.dev/skills/shieldnet-360/secure-vibe/electron-security"><img src="https://agentmods.dev/badge/skills/shieldnet-360/secure-vibe/electron-security/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/shieldnet-360/secure-vibe/electron-security"><img src="https://agentmods.dev/badge/skills/shieldnet-360/secure-vibe/electron-security.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00073 | $0.02515 |
| Opus 5.5 | $0.00029 | $0.01006 |
| Sonnet 5.5 | $0.00015 | $0.00503 |
| Haiku 4.5 | $0.00007 | $0.00251 |
Grade A, and why
electron-security scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 173 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Electron Desktop Security
Rules (for AI agents)
ALWAYS
- Treat the renderer as untrusted. Any renderer-side code execution — XSS in rendered content, a redirect, a deep link — must not be able to reach Node, the shell, the filesystem, or session tokens. Every other rule here follows from this one, and every IPC sink you expose is reachable from a compromised renderer.
- Keep the renderer's process isolation at its defaults rather than restoring them:
nodeIntegration: false,contextIsolation: trueandsandbox: truehave been Electron's defaults for several major versions, so the finding is the line that turns one off. Note the coupling: undersandbox: truea preload gets a polyfilled module subset, so a preload needingfsfails — move that work behind IPC into the main process, never drop the sandbox. - Set the packaging fuses on release builds: disable
RunAsNode,EnableNodeCliInspectArgumentsandEnableNodeOptionsEnvironmentVariable. WithRunAsNodeon, an attacker runs your signed binary as a plain Node process and every renderer-side control above becomes irrelevant — a build-time setting no runtime hardening substitutes for. - Expose a minimal, typed API from the preload via
contextBridge.exposeInMainWorld. Expose named functions only — never hand the rendereripcRenderer,require,process, or whole modules. Do not add@electron/remote: it restores the main-process object access that was removed from core precisely because it defeats the boundary. - Validate every IPC argument in the main-process handler: type-check, bound, and allowlist. The renderer is an attacker-controlled input source.
- Spawn child processes with
execFile/spawnand an argument array, neverexecwith a shell string built from renderer input — that is command injection. Allowlist each argument (e.g.^[A-Za-z0-9_-]+$). - Confine filesystem paths:
path.resolve(base, input), then verify the resultstartsWith(base + path.sep). Reject absolute paths and..segments. Concatenating a renderer-supplied path (${BASE}${filePath}) is path traversal and arbitrary file write. - Allowlist
shell.openExternaltohttps:(andmailto:if needed) after parsing the URL. Rejectfile:, custom schemes, and anything else — an arbitrary or renderer-controlled URL here is a local-launch and RCE vector. - Add navigation guards:
app.on('web-contents-created', …)withcontents.on('will-navigate', …)andcontents.setWindowOpenHandler(…)that deny by default against a strict origin allowlist. KeepwebviewTag: false; where a<webview>is genuinely required, strip itspreloadand reset its options inwill-attach-webview. - Remember the contextBridge surface is exposed to whatever origin the webContents
currently holds — the preload re-runs on navigation and
exposeInMainWorlddoes not re-check origin. One missingwill-navigateguard lets an attacker origin inherit your entire IPC surface: that is how a stored hyperlink becomes 1-click RCE. Gating the preload onlocationis defense in depth, not the control. - Before attaching session tokens or cookies to an outbound request, verify the target host is on your own-API allowlist. Never attach credentials to a renderer-supplied URL — an XSS then exfiltrates the token.
- Bind custom-protocol / deep-link auth to a one-time
state/ PKCE value the app generated and is waiting for; validate before storing any token. Acceptingmyapp://auth?refresh-token=…unvalidated is login CSRF and session fixation. - Store tokens with Electron
safeStorage, not app-level crypto — and checksafeStorage.isEncryptionAvailable()first: on Linux with no keyring the backend falls back to a fixed key, so the ciphertext is not confidential. Ship release builds code-signed, with ASAR integrity where the platform supports it (macOS and Windows). - Treat every server the app connects to — your own API, an auto-update channel,
a telemetry endpoint, a shared multi-tenant backend — as potentially
attacker-controlled. Never load a server-supplied URL into a window carrying your
preload, and never feed a server response into an IPC sink (file path, shell
argument,
openExternalURL) without the validation you apply to renderer input. - Harden parsers consuming untrusted server or stream data: bound every length field before allocating, cap recursion and include-style expansion (circular references become an infinite loop), and wrap the parse in try/catch. A malicious server otherwise hangs the renderer even where memory safety rules out RCE.
- Consult
frontend-securityfor the renderer's own browser surface — Content Security Policy, DOM sinks, sanitizer choice. The renderer is a browser; that skill owns what runs inside it, this one owns what it can reach beyond it.
What ships with it
4 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 173 lines · 73 tokens per session scan A f11a89b3bced
electron-security is a skill published in the GitHub repository ShieldNet-360/secure-vibe (22 stars, last pushed 2mo ago), licensed MIT. It adds 73 tokens to every session and 2,515 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
ai-engineering-toolkit
6 production-ready AI engineering workflows: prompt evaluation (8-dimension scoring), context budget planning, RAG pipeline design, agent security audit (65-point checklist), eval harness building, and product sense coaching.
ai-agent-evaluation-benchmarking
Autonomous AI agent benchmark evaluation register: task completion rates, planning accuracy, tool invocation precision, and cost benchmarks.
ai-agent-tool-routing
Autonomous AI agent tool router register: schema registration, runtime parameter coercion, idempotency keys, and error recovery policies.
ai-prompt-regression-testing
Prompt engineering regression test matrix register: baseline outputs, semantic drift thresholds, judge evaluations, and golden dataset.
documenter-vitepress
Use when setting up or developing a Julia based documentation site with DocumenterVitepress.jl. Also use when the user mentions DocumenterVitepress, VitePress for Julia docs, or wants to preview docs locally with hot reload.
agent-teacher
A teaching aid that explains technical ideas with a small runnable code example and a guided walkthrough. It is meant for learning how something works, not fixing existing code.