Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add rules/brighton-labs/railguard-cursor-coding/java-database-secure-no-railguard-availablegit clone --depth 1 https://github.com/brighton-labs/railguard-cursor-codingWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.01070 | $0.01070 |
| Opus 5 | $0.00535 | $0.00535 |
| Sonnet 5 | $0.00214 | $0.00214 |
| Haiku 4.5 | $0.00107 | $0.00107 |
Grade A, and why
java-database-secure-no-railguard-available scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 92 lines — stays where its author put it; the contents beside it link to each section on GitHub.
R: Risk First
The goal of this rule is to ensure safe, auditable, and robust database access in Java applications.
The following risks are mitigated:
- SQL injection due to unsafe query construction
- Leaking credentials in source code or logs
- Poor ORM configuration leading to unintended DB writes or untracked queries
- Unsafe exception handling that can crash critical database access logic
- Lack of input validation before constructing dynamic queries
This rule teaches the LLM to reason about these concerns even when prompts are vague (for example, “connect to DB” or “get user by name”).
A: Attached Constraints
- Never use string concatenation to build SQL queries.
- Avoid direct use of
Statement. Always usePreparedStatementor ORM-based parameterization. - Never log raw SQL queries or parameters with user input.
- Never hardcode sensitive credentials (for example, DB password) into the codebase.
- Avoid unguarded auto-commits or DB writes without transactional control.
I: Interpretative Framing
- If the prompt asks for DB interaction, assume secure query logic and credential separation are expected.
- If prompted to use JDBC, enforce
PreparedStatementand parameter binding. - If using Spring Boot or Spring Data JPA, assume proper use of annotations and entity mapping.
- Credentials must always be externalized via environment variables or secret vaults.
// Ambiguity Handling:
- For prompts like “get user by name,” enforce input validation and parameter binding.
- If the developer uses raw SQL with hardcoded values, suggest a secure, param-based version and note config guidelines.
L: Local Defaults
- Assume the use of Spring Boot + Spring Data JPA as the ORM layer.
- If JDBC is used, assume modern usage with
PreparedStatement. - Assume the following environment variables are configured:
SPRING_DATASOURCE_URLSPRING_DATASOURCE_USERNAMESPRING_DATASOURCE_PASSWORD
- Default log level is set to suppress SQL query printing or sanitize it via masking.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 92 lines · 1,070 tokens per session scan A e03fa14045b1
java-database-secure-no-railguard-available is a cursor rule published in the GitHub repository brighton-labs/railguard-cursor-coding (13 stars, last pushed 1y ago), licensed MIT. It adds 1,070 tokens to every session, about $0.0053 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other cursor rules, from other repositories
database-design
Database design guidelines — relational normalisation, indexing, constraints, NoSQL patterns, query optimisation, migrations, security, and backup strategies. Applied when working with database schemas and queries.
backend-dev
Backend development workflow with Java/Python/Node.js - 后端开发完整工作流.
supabase-migrations
You are a Postgres Expert who loves creating secure database schemas.
database-patterns
Cursor rule "database-patterns" from floriscornel/todo-mcp, covering database development patterns, schema changes, database operations, schema patterns and migration best practices.
database
Cursor rule "database" from ItamarZand88/awesome-agent-conventions, covering database best practices, prisma setup, prisma models, prisma queries and supabase setup.
sqlite
本规范为 SQLite 开发提供全面指导，涵盖架构设计、性能优化、安全性、测试等最佳实践。旨在确保高效、安全和可维护的 SQLite 数据库应用程序。.