Security And Safety Rules
Definition
Define security and operational safety as explicit design knowledge owned by modules, not scattered checks. Security rules reduce unknown unknowns by making trust boundaries and prohibited actions obvious.
Process
- Identify actors, authentication method, authorization model, and sensitive data.
- Place authorization checks at stable interfaces, close to the protected operation.
- Validate all external input at boundaries and preserve domain invariants internally.
- Keep secrets out of code, logs, tests, fixtures, and generated output.
- Define destructive, irreversible, or privacy-sensitive actions that require confirmation.
- Add tests for permission failures and unsafe input.
Rules
- Never trust client-side checks as authorization.
- Do not duplicate security policy across UI, route, and domain code; give it an owner.
- Log enough for diagnosis without leaking secrets or private data.
- Fail closed when permission or validation state is unknown.
- Treat dependencies, environment variables, and migrations as safety surfaces.
Examples
- Good:
documents.canEdit(user, document) owns edit permission.
- Bad: every route checks a different role string.
- Good: API validates request shape before calling the domain command.
- Bad: raw request bodies flow into database queries or shell commands.
Vocabulary
- Trust boundary: place where untrusted data enters the system.
- Authentication: proving who the actor is.
- Authorization: deciding what the actor may do.
- Sensitive data: secrets, personal data, credentials, tokens, and private business data.
- Fail closed: deny access when uncertain.
- Policy owner: the module responsible for a safety rule.
Expected Outcome
Produce security rules covering identity, permissions, validation, secrets, logging, sensitive data, destructive actions, and required abuse-case tests.
1---2name: security-and-safety-rules3description: Define or audit authentication, authorization, validation, secrets, sensitive data handling, and prohibited unsafe actions. Use when adding user access, handling private data, reviewing external inputs, or creating safety guardrails for agents and developers.4---56# Security And Safety Rules78## Definition910Define security and operational safety as explicit design knowledge owned by modules, not scattered checks. Security rules reduce unknown unknowns by making trust boundaries and prohibited actions obvious.1112## Process13141. Identify actors, authentication method, authorization model, and sensitive data.152. Place authorization checks at stable interfaces, close to the protected operation.163. Validate all external input at boundaries and preserve domain invariants internally.174. Keep secrets out of code, logs, tests, fixtures, and generated output.185. Define destructive, irreversible, or privacy-sensitive actions that require confirmation.196. Add tests for permission failures and unsafe input.2021## Rules2223- Never trust client-side checks as authorization.24- Do not duplicate security policy across UI, route, and domain code; give it an owner.25- Log enough for diagnosis without leaking secrets or private data.26- Fail closed when permission or validation state is unknown.27- Treat dependencies, environment variables, and migrations as safety surfaces.2829## Examples3031- Good: `documents.canEdit(user, document)` owns edit permission.32- Bad: every route checks a different role string.33- Good: API validates request shape before calling the domain command.34- Bad: raw request bodies flow into database queries or shell commands.3536## Vocabulary3738- Trust boundary: place where untrusted data enters the system.39- Authentication: proving who the actor is.40- Authorization: deciding what the actor may do.41- Sensitive data: secrets, personal data, credentials, tokens, and private business data.42- Fail closed: deny access when uncertain.43- Policy owner: the module responsible for a safety rule.4445## Expected Outcome4647Produce security rules covering identity, permissions, validation, secrets, logging, sensitive data, destructive actions, and required abuse-case tests.
harsh817