# GRD-010: Support granular custom detections


- Area: Runtime Guardrails

- Verification: Walkthrough
- OWASP adoption tier: AT0–AT4
- Formerly: DAT-007
- URL: /r/GRD-010

**Acceptance criteria:** Let authorized teams maintain custom keywords, client and project identifiers and deal codenames, with an audit trail.

**Why it matters:** Built-in models cannot know your client names, project codes or deal codenames.

**How to verify:** An authorized user adds a project codename and it is detected in the next pilot prompt, with the change audited.

**OWASP adoption context:** Customer, project and deal vocabulary can appear across the listed employee AI settings, so custom detections should follow that vocabulary rather than one product.

**Mappings:**
- ISO 42001: A.6.2.8 — The audit trail of custom-detection changes supplies AI event-record evidence. It does not establish complete logging coverage, retention or record protection.
- SOC 2: CC6.7, CC8.1; ISO 27001: A.8.15, A.8.12 — Custom detections tailor leakage rules to company information, while their audit trail records administrative changes. Detection still needs a protective disposition, and the trail alone does not demonstrate change testing and approval.
ISO/IEC 27001: A.8.15: Keep attributable records with appropriate retention, protection and analysis; a live view alone is insufficient. A.8.12: Use an operated leakage-protection workflow with defined alert triage, warnings, blocking or another protective response. Enforce authorization; keywords cannot replace a complete information inventory or semantic detection.
- NIST CSF 2.0: PR.DS-02 — Custom client, project and codename detections configure a specific sensitive-data signal for protecting AI submissions. Use those detections in an operated leakage-protection workflow; a detector vocabulary is not an inventory of data holdings.