Secure

Secure

Security skill for LLM coding agents. Load this when a change touches authentication, authorization, user input, secrets, data access, file handling, or a network boundary — which is more changes than it sounds like.

Where deliberate keeps code honest, this skill keeps code safe. Counters the documented failure mode of AI-generated code: taking the path of least resistance, which is rarely the secure path — bypassed access controls, client-side-only auth, injectable queries, leaked secrets, and over-broad permissions.

---

1. Security Is Part of "Working"

Code that works but is exploitable does not work.

• The happy path proving out is not the bar. The bar includes: what can a hostile caller do with this?
• Security is not a later pass, a cleanup task, or someone else's audit. It ships with the change or the change isn't done.
• When you demo a feature, you demo the door. Ask who else can walk through it.

Test: Did I consider this change from the attacker's side, or only the user's?

---

2. Never Route Around a Security Control

When a security mechanism blocks you, that is the mechanism working.

The most dangerous shortcut an agent takes: the permission check fails, so reach for the key that bypasses it — the service-role token, the admin credential, the sudo, the disabled TLS check, the widened CORS policy.

• If row-level security blocks the query, fix the policy — don't switch to the role that ignores it.
• If auth middleware rejects the request, fix the auth flow — don't add the route to the exempt list.
• If a certificate fails validation, fix the certificate — don't set verify=false.

Each bypass "fixes" the task by deleting the protection. If a control genuinely seems wrong, say so and let the user decide.

Test: Does my fix satisfy the security control, or evade it?

---

3. Trust Nothing That Crosses a Boundary

Input is hostile until validated — at the server, at the API, at the parser.

• Validation and authorization live server-side. Client-side checks are UX, not security; anything enforced only in the browser is enforced nowhere.
• Queries are parameterized. String-built SQL, shell commands, and file paths from user input are injection, full stop.
• Output is encoded for its destination — HTML, attribute, URL, shell. XSS is the single most common flaw in generated code.
• File paths from users get canonicalized and checked against a root. Uploads get type- and size-checked.
• Deserialization of untrusted data uses safe loaders, never eval-equivalent ones.

Test: For each place data crosses into this code, what happens when the data is malicious?

---

4. Secrets Never Enter the Repo

A credential in code, config, logs, or output is a leak — even in a private repo, even "temporarily."

• Keys, tokens, passwords, and connection strings come from env vars or a secret store. Never literals.
• Don't print secrets in logs, error messages, debug output, or your own progress commentary.
• Don't copy a real credential into a test fixture or an example file. Placeholders only.
• Before committing, scan the diff for anything that looks like a credential. "I'll rotate it later" means it's already leaked.

Test: If this diff went public right now, would anything need rotating?

---

5. Least Privilege by Default

The convenient permission is the insecure one. Scope everything down.

• Tokens, roles, and service accounts get the narrowest scope that makes the feature work — not the broad one that makes the error go away.
• New endpoints default to authenticated. Public is an explicit, stated decision.
• Database users for an app don't own the schema. Cloud roles don't get * on resources or actions.
• If you can't name why a permission is needed, it isn't.

Test: Can I justify every permission this change grants, individually?

---

6. Vet Dependencies Before Adding Them

A package name you're confident about may not exist — and an attacker may have registered it.

Hallucinated package names are now a supply-chain attack vector (slopsquatting): attackers publish malware under the names models invent.

• Before adding a dependency, confirm it's the real one: registry page, repo, download count, maintenance activity, exact spelling.
• Prefer the platform's standard library and already-present dependencies over new ones (see deliberate §4).
• Never hand-roll crypto, session management, or password hashing. Use the platform's standard, maintained mechanism.
• Pin versions. Review what a new dependency pulls in transitively.

Test: Did I verify this package exists and is the one I think it is, or did I trust my memory of its name?

---

7. Escalate Security Decisions — Don't Default Them

When the spec is silent on security, the gap is a product decision, not yours to fill quietly.

• Data retention, PII handling, encryption at rest, audit logging, session length, rate limits: if unspecified, ask — don't pick the permissive default because it's less code.
• Flag security-relevant omissions the way review hunts for what isn't there: the missing rate limit, the missing audit log, the unsanitized input the spec never mentioned.
• If you spot an existing vulnerability while working, report it — don't silently fix it (scope), and never ignore it.

Test: Did any security posture get decided in this change without anyone deciding it?

---

These Guidelines Are Working If

• Security controls stop getting bypassed to make features work.
• Injection-shaped code (string-built queries, commands, paths) stops appearing in diffs.
• Secrets stop showing up in commits, logs, and fixtures.
• New permissions arrive with one-line justifications.
• Security gaps in specs get surfaced as questions, not filled with permissive defaults.

---

Part of Deliberate. Load alongside deliberate; pairs with review (safety is a review layer), verify (exploitable isn't done), and pentest (which hunts the holes this skill then fixes).