The security Skill — Hardening Recipes Built Into the Workflow
How Datarim's security skill embeds authentication rules, input validation, dependency auditing, and incident recipes directly into the agent workflow rather than leaving them for a post-merge review.
Security advice that arrives after implementation is expensive. Finding an exposed secret in a commit history or a vulnerable dependency in production costs far more than catching it in the plan phase. The security skill exists to keep security reasoning inside the workflow, not outside it.
The skill covers four areas: authentication and authorization, data protection, dependency safety, and a set of operational recipes for incidents that recur across projects. Each area carries concrete rules, not general principles. For example, the rule on cached secrets specifies that any hot-store cache holding raw bearer credentials — even one with a bounded TTL and a network-isolated bind — must be recorded in the project's accepted-risk register, because operator access to the cache bypasses the primary secret store's audit trail.
Authentication and input validation
The basic rules are straightforward: never hardcode secrets, validate all inputs on the server side, and apply least-privilege to API keys. Data protection adds three more: sanitize user input against XSS and SQL injection, encrypt sensitive data at rest and in transit, and never log personally identifiable information.
Dependency auditing is deliberately stack-neutral. The skill instructs the agent to run «the package-manager-native audit command at the declared severity threshold» — the concrete invocation belongs in the project's own CLAUDE.md, not in a shared framework file. This keeps the framework from encoding npm-specific or cargo-specific commands that break for other ecosystems.
Incident recipes
Three recipes cover situations that generate debugging sessions when encountered without prior preparation. The git history scrub recipe describes the mandatory two-flag invocation of git filter-repo — one flag for blob contents, one for commit messages — because omitting the second flag leaks any pattern that appears in the commit message describing the redaction. The recipe also specifies acceptable backup channels (a local mirror clone or external object storage) and explains why a tag in the same repo is not a valid backup after a force-push rewrite.
The Tailscale and VPN coexistence recipe is a five-step checklist for macOS. The most common trap is starting Tailscale after a commercial VPN: the VPN claims the first available tunnel interface, and Tailscale silently fails to establish a mesh connection. The recipe also covers the --accept-dns=false flag, which prevents two daemons from both overwriting the system resolver and producing intermittent NXDOMAIN failures.
The reconnaissance versus compromise heuristic addresses a different kind of confusion: a 200 response to a suspicious filename is not proof of compromise. The skill lists four indicators that distinguish scanner noise from actual exploitation — unusual base64 payloads, modification dates inconsistent with provisioning, outbound connections from PHP workers to unknown IPs, and unexpected cron entries or SSH keys.
Cross-stack path-flip threat model
One recipe is worth noting for its scope. When a task changes the root of an HTTP request — flipping a document root, a container volume mount, or a symlink target — the skill requires auditing every consumer that resolves paths relative to that root, not just the configuration performing the flip. Runtime caches keyed by path treat two byte-identical files at different inodes as different sources, and a long-running worker that loaded the same class from both inodes will crash with a redeclare error at request time. The mitigation is to make the two roots share the same inode tree for the duration of the flip, then plan a canonical relocation as a follow-up step.
Where it fits
The security skill is a companion to the security-baseline skill, which holds the canonical S1–S9 rule reference. Loading both together covers security planning; loading security alone covers live incident investigation. The skill also ships two reusable plan templates: one for dependency CVE and framework-version-bump tasks, and one for atomic cutover with auto-rollback for live-service configuration flips.
Read what Datarim is for the broader context, or explore the self-verification skill to see how security findings are structured in the verification layer.