# Guardrails Selection > Analyze the developer request, infer the security categories and likely threats involved, shortlist the most relevant project guardrails, then hydrate the exact guardrails with get_guardrail_by_id before implementation. Use for every security-relevant code task before code is written and preserve the shortlist for the final VibeReview sync. - Skill: `securityreviewai/guardrails-selection` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add securityreviewai/guardrails-selection` - Raw SKILL.md: https://api.skillmd.com/api/skills/securityreviewai/guardrails-selection/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: securityreviewai (https://skillmd.com/u/securityreviewai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/securityreviewai/guardrails-selection --- # Guardrails Selection Configured SRAI project name: `` Use this skill whenever code will be created or modified and the task has any security surface. This skill exists to stop the IDE from treating the full `get_guardrails` result as an unstructured blob. The workflow is: 1. Understand the request deeply. 2. Infer which security categories are in play. 3. Predict the threats that might occur for this exact task. 4. Shortlist only the guardrails that mitigate those threats. 5. Fetch the exact shortlisted guardrails with `get_guardrail_by_id`. 6. Carry that same shortlist forward into implementation and the final VibeReview markdown sync. Do not skip the analysis step. Do not rely on title-matching alone. Do not dump every guardrail into the final answer. ## Inputs You Must Analyze First Before calling `get_guardrails`, extract the actual development intent from the prompt and surrounding code: - What is being built, changed, fixed, or refactored? - Which components are affected: API, UI, background jobs, auth flow, webhook, file upload, admin tooling, AI agent flow, infra code, data pipeline? - Which trust boundaries are crossed? - Which sensitive assets are touched: tokens, credentials, sessions, PII, tenancy boundaries, audit logs, secrets, internal APIs, signed URLs, payment state, workflow approvals? - Which technologies and patterns are involved in the existing code? - What abuse cases are plausible if this change is implemented poorly? You are not only selecting guardrails for the obvious functionality. You are selecting guardrails for the threats that might materialize around that functionality. ## Category Inference Workflow Derive a category set for the task before shortlisting guardrails. Common categories include: - `authentication` - `authorization` - `session_management` - `input_validation` - `output_encoding` - `secrets` - `cryptography` - `logging` - `monitoring` - `file_uploads` - `deserialization` - `data_access` - `rate_limiting` - `network` - `client_side` - `business_logic` - `tenant_isolation` - `admin_workflows` Use both the user request and the codebase patterns to infer the category set. A task can involve multiple categories even if the prompt mentions only one feature. Examples: - “Add magic-link login” likely involves `authentication`, `session_management`, `cryptography`, `logging`, `rate_limiting`, and `client_side`. - “Add org admin API to update member roles” likely involves `authorization`, `tenant_isolation`, `logging`, `business_logic`, and `data_access`. - “Add CSV import” likely involves `input_validation`, `file_uploads`, `data_access`, `deserialization`, `logging`, and denial-of-service protections. - “Add client-side token refresh” likely involves `authentication`, `session_management`, `client_side`, `logging`, and `cryptography`. ## Threat Mapping Requirement After identifying categories, infer the threat families that might occur. Use the reference file at `{{GUARDRAILS_SELECTION_SKILL_DIR}}/references/category-threat-map.md` every time you need to reason about category-to-threat mapping. Your goal is not to enumerate every possible weakness. Your goal is to pick the threats that should influence guardrail selection for this task. At minimum, consider whether the task can create: - authentication bypass - authorization bypass - privilege escalation - information disclosure - repudiation gaps - denial of service - unsafe client-side trust - insecure logging or audit gaps - injection-triggered security failures - serialization-triggered security failures - business-logic-triggered bypasses The shortlist should be threat-led, not catalog-led. ## Guardrail Selection Procedure ### Step 1: Resolve the project and load the catalog 1. Call `find_project_by_name` with `name=""` to obtain `project_id`. 2. Call `get_guardrails` with `project_id`. Treat `get_guardrails` as the broad catalog. Do not treat it as the final set of instructions. Assume each returned guardrail includes the fields needed for selection, including a stable identifier for follow-up retrieval, plus: - `title` - `rule_type` - `category` - `instruction` If an identifier is absent, fall back to the best available stable reference exposed by the tool, but prefer the real guardrail id whenever available. ### Step 2: Build a shortlist Shortlist guardrails using all of the following: - direct category match with the task - mitigation value against the likely threats you inferred - relevance to the technologies and code paths being touched - support for adjacent controls that prevent bypass chains - duplication removal Do not select a guardrail only because it sounds generally useful. Select it because it materially constrains the risky part of the current task. Examples: - If the task touches login, token issuance, password reset, session refresh, or identity proofing, prioritize authentication, session, crypto, logging, and brute-force defense guardrails. - If the task changes role checks, tenant scoping, admin APIs, resource ownership, or query filters, prioritize authorization, tenant isolation, data access, business-logic, and audit guardrails. - If the task introduces parsing, uploads, template expansion, or object hydration, prioritize input validation, file handling, deserialization, and denial-of-service guardrails. - If the task moves security decisions into the browser or mobile client, prioritize client-side trust, token storage, server-side revalidation, and privilege-boundary guardrails. ### Step 3: Hydrate exact shortlisted guardrails For every shortlisted existing guardrail, call `get_guardrail_by_id` to retrieve the exact guardrail that will govern implementation. - Use `get_guardrail_by_id` for the shortlisted ids only. - If the tool supports batching, batch the shortlisted ids. - If the tool only supports one id at a time, call it once per shortlisted id. Implementation must be driven by the hydrated shortlist from `get_guardrail_by_id`, not by vague memory from the broad catalog listing. ### Step 4: Track the active shortlist in context Maintain an explicit in-context list of the shortlisted existing guardrails that will govern the task. For each shortlisted existing guardrail, keep: - `id` - `title` - `rule_type` - `category` - `instruction` - `why_selected` Also track any new guardrails created during the task as `ide_generated`. This shortlist is the source of truth for the rest of the session. ## Implementation Rules Once the shortlist is hydrated: - Every applicable `must` guardrail is mandatory. - Every applicable `must_not` guardrail is a hard prohibition. - If two shortlisted guardrails appear to conflict, explain the conflict and resolve it before coding. - If the task reveals a real gap not covered by the shortlisted existing guardrails, create an `ide_generated` guardrail and apply it immediately. When deciding whether a guardrail applies, prefer security-preserving inclusion over risky omission. If it plausibly mitigates a realistic path to abuse for the current task, keep it in scope. ## VibeReview Sync Contract The final sync step must reuse the shortlist from this skill. It must not call `get_guardrails` or `get_guardrail_by_id` again. Before `sync_ai_ide_markdown` is called, ensure the main agent context clearly contains: - the exact existing guardrails shortlisted earlier - which of them were applied - whether each one was satisfied - any notes about partial compliance, conflicts, or rationale - every `ide_generated` guardrail created during the task If a guardrail was shortlisted but not fully satisfied, still include it in the handoff with `satisfied: false` and a note. Do not silently drop it. ## Selection Quality Bar A good selection does all of the following: - covers the feature’s real threat surface, not just its visible functionality - captures adjacent controls that stop bypass chains - avoids irrelevant noise - produces a small, defensible set of guardrails that can actually guide implementation - leaves the final VibeReview markdown with an exact list of what the IDE selected and enforced If your shortlist feels generic, it is probably incomplete or over-broad. Re-check the prompt, the code patterns, and the threat map.