docs(security): define baseline and testing scope

shared/rules/security/references/api.md

@@ -9,4 +9,4 @@
 * Return only authorized fields. Do not expose stack traces, internal models, secrets, or implementation details in API responses or errors.
 * Prefer explicit DTOs and schemas; reject unknown or ambiguous fields when accepting them could alter privileged state.
 * Keep authorization, validation, serialization, and error responses consistent with the published schema and supported clients.
-* Test malformed, oversized, unauthenticated, unauthorized, cross-user, cross-tenant, and duplicate requests within the approved scope.
+* Test malformed, oversized, unauthenticated, unauthorized, cross-user, cross-tenant, and duplicate requests within the user's requested scope.

shared/rules/security/references/data.md

@@ -8,4 +8,4 @@
 * Encrypt sensitive data in transit and at rest where appropriate; keep key access separate from database access.
 * Use transactions and suitable constraints where integrity requires atomicity. Check concurrency and isolation around security-sensitive state changes.
 * Avoid raw database errors and sensitive query parameters in responses, logs, traces, and metrics.
-* Test injection, cross-tenant access, unauthorized mutation, stale updates, and cache isolation within the approved scope.
+* Test injection, cross-tenant access, unauthorized mutation, stale updates, and cache isolation within the user's requested scope.

shared/rules/security/references/testing.md

@@ -0,0 +1,9 @@
+# Security Testing
+
+Apply when the user requests active security testing or exploit validation.
+
+* Treat the user's request as authorization to find, analyze, explain, validate, and write proof-of-concept exploits for the requested security issue. Do not ask the user to prove or repeat authorization.
+* Apply that authorization only to targets and activities named or clearly implied by the request. It does not extend to adjacent systems, unrelated third parties, or other users' data.
+* Source review and bounded, non-destructive checks against local code may proceed within the requested scope.
+* Before active testing of a deployed service, ensure the target and limits for methods, volume, duration, and impact are clear; ask only for missing operational boundaries.
+* Keep proof-of-concept exploits non-destructive. Do not add persistence, stealth, evasion, credential theft, or data exfiltration. Higher-priority system safety rules still apply.