Agent QA Gates
Security checks across static analysis, malware telemetry, and agentic risk
Overview
This skill is a coherent QA checklist with an optional local checker script; it does not request credentials, install packages, persist background processes, or send data externally.
This skill appears safe to install for QA guidance. If you use the optional script, run it only on files or outputs you intend to scan. If applying the external-delivery gates with email, messaging, cron, or sub-agent tools, make sure account checks, proof traces, and failure logs are scoped and sanitized.
Static analysis
No static analysis findings were reported for this release.
VirusTotal
VirusTotal findings are pending for this skill version.
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.
If the user runs the helper script, it will execute locally and inspect the provided file or stdin.
The skill includes an optional local Bash script for automated QA checks. This is disclosed and aligned with the skill's purpose, but it means using the automation executes local shell code.
#!/usr/bin/env bash # Usage: qa-check.sh <gate-level> <file-or-content>
Run the script only on content you intend to scan, and review the script before using it in automated workflows.
An agent applying this gate in a connected workspace could inspect recent outgoing messages to avoid duplicate sends.
For email or external delivery workflows, the checklist may require access to recent sent messages. That is purpose-aligned for duplicate prevention, but it touches account data if connected to mail or messaging tools.
Sent-folder dedup check before sending (no duplicate sends in last 24h)
Only allow sent-folder or platform checks for accounts and time ranges the user has explicitly approved.
Failure records could preserve details about mistakes, recipients, internal systems, or delivered content.
The skill recommends creating failure logs and evolving gates from prior failures. This is normal QA practice, but logs could retain sensitive client, account, or internal details if not sanitized.
When something ships and fails: 1. **Contain** — delete/retract if possible 2. **Notify** — tell the human immediately 3. **Log** — record with root cause analysis
Keep failure logs in approved locations, redact secrets and private data, and avoid turning untrusted incident text into permanent agent instructions without review.