agentleFS
CsHengCsHeng/agent-skills/skills/security-guardrails/SKILL.md

security-guardrails

Skill3 starsChanged 9 days agoMITView on GitHub

Use for security implementation guardrails: secrets, TLS, CORS, input validation, SQL injection, XSS, uploads, and container hardening calibrated to actual exposure and loss.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When the change handles secrets:

    line 18
  2. Distinctive:

    Keep credentials out of source, logs, prompts, and client-visible payloads.

    line 20
  3. Very specific:

    When the service exposes TLS, CORS, or response headers, or the change builds or hardens images, read references/infra-security.md.

    line 27
  4. Distinctive:

    Use parameterized queries or the driver's bound-parameter API so values cannot become SQL syntax.

    line 35
  5. Distinctive:

    Use the platform's HTML sanitizer when the product must accept HTML.

    line 41
  6. Very specific:

    When the product accepts files, read references/file-uploads.md.

    line 45
  7. Distinctive:

    Keep thresholds, recovery, bypass, and support ownership configurable and testable rather than embedding universal values.

    line 50

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Security Guardrails

Purpose

Select controls that protect the current goal from actual exposure, exploitability, expected loss, and blast radius at a control cost the threat justifies. Add a control only when it closes a named exposure at the current boundary.

Risk Calibration

Apply the environment classification in development-standards and the recovery calibration in runtime-diagnosis. Clearly exploitable harm is not waived by a "dev" label; protect real secrets, shared-host boundaries, and production in every environment.

Credential Management

When the change handles secrets:

  • Keep credentials out of source, logs, prompts, and client-visible payloads.
  • Load secrets from the environment or the repository-owned secret boundary already in use.
  • Restrict access to credential files when files are the owned store.
  • Rotate or revoke credentials on compromise, ownership change, or existing policy.

Network, Headers, And Containers

When the service exposes TLS, CORS, or response headers, or the change builds or hardens images, read references/infra-security.md. Derive TLS versions, header set, and CORS allowlist from the clients and browser origin policy the service actually has.

Input Validation

Validate untrusted input at the owned boundary for the types, lengths, and semantic rules the operation needs. Reject invalid required input rather than guessing.

Injection

  • Use parameterized queries or the driver's bound-parameter API so values cannot become SQL syntax.
  • Apply the same bound-parameter or typed-binding rule to other query languages the code constructs.

XSS

  • Encode or pass values in the encoding required by the output context (HTML text, attribute, URL, JS).
  • Use the platform's HTML sanitizer when the product must accept HTML.

File Uploads

When the product accepts files, read references/file-uploads.md.

Authentication And Abuse Controls

  • Require multi-factor authentication, account lockout, rate limiting, or step-up verification when the threat model or policy justifies the control.
  • Keep thresholds, recovery, bypass, and support ownership configurable and testable rather than embedding universal values.
  • Store authentication factors and recovery material through the owned secret boundary; keep them out of logging side effects.

Security Evidence Handoff

Define which control outcome must be observable without recording secrets or unnecessary personal data, and route security and audit event selection, redaction, correlation, retention, access, alert evidence, and tamper evidence to logging-standards. Prevention, validation, authorization enforcement, and response behavior stay here; logs are evidence of the control.

References

  • Python Security Examples
  • Infrastructure Security
  • File Uploads

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.