code-safety

name	code-safety
version	1.0.0
description	Scan LLM-generated code for security vulnerabilities using language-aware pattern rules
author	Frame.dev
namespace	wunderland
category	security
tags	["guardrails","code-safety","security","injection","xss","owasp","static-analysis"]
requires_tools	["scan_code"]
metadata	{"agentos":{"emoji":"🛡"}}

Code Safety Scanner

A guardrail automatically scans code in your responses for security vulnerabilities. You also have a tool for on-demand code scanning.

When to Use scan_code

• Before writing code to files via write_file or create_file
• Before executing code via shell_execute
• When reviewing user-submitted code for security issues
• Before presenting code examples that handle user input

What It Detects

• Injection: eval(), exec(), os.system(), command injection
• SQL Injection: string concatenation in SQL queries
• XSS: innerHTML, document.write, dangerouslySetInnerHTML
• Path Traversal: unsanitized ../ in file paths
• Hardcoded Secrets: API keys, passwords, tokens in code
• Weak Crypto: MD5/SHA1 for passwords, Math.random for security
• Insecure Deserialization: pickle.loads, yaml.load without SafeLoader
• SSRF: unvalidated URL construction from user input

Post-Approval Guardrail Override

When HITL (human-in-the-loop) is enabled with guardrailOverride: true (the default), the code-safety scanner runs after HITL approval as a post-approval guardrail. This means even actions approved by a human operator or LLM judge are scanned for destructive patterns before execution. This catches accidental approvals of dangerous commands like rm -rf / or DROP TABLE. See the hitl-safety skill for full HITL configuration.

Constraints

• Regex-based detection — may have false positives on safe code patterns
• Language detection from code fence tags or heuristics
• Does not perform deep AST analysis