# Runtime Guardrails (GRD) Requirements — 25 Workforce AI Security Controls > Inspect prompts, files and responses in real time; coach, redact or block before data leaves. 25 vendor evaluation requirements with acceptance criteria, verification tests and framework mappings. Source: Harmonic Security, updated October 2026. 25 requirements. Disclaimer: Mappings indicate relevant contributions, not complete compliance, certification, assurance, a conformity assessment or legal advice. Read each explanation and its scope conditions. Legal applicability depends on jurisdiction, role, use and effective dates. Reference summaries are selective; consult current official sources and full licensed standards before relying on them. ## GRD-001: Inspect prompt content in real time before submission - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DAT-001 - URL: /r/GRD-001 **Acceptance criteria:** Classify typed or pasted content at submit time and reach a policy decision before content leaves for the provider. **Why it matters:** A decision made after submission only tells you what was lost. Inspection before submission is what prevents the loss. **How to verify:** Sensitive pilot prompts receive a policy decision before they reach the provider; record the decision time. **OWASP adoption context:** Prompt inspection applies across the listed employee interaction contexts, including personal accounts and agent-assisted work, wherever the submission path is observable. **Mappings:** - NIST CSF 2.0: PR.DS-02, PR.DS-10 — Classifying prompts at submission supplies timely inputs for protecting data in use and in transit. A pre-egress policy decision does not by itself demonstrate that the protective action is executed. - SOC 2: CC6.7; ISO 27001: A.8.12, A.5.14 — Classification and a policy decision before provider egress supply inputs to leakage restrictions and governed transfers. The acceptance test requires a decision, not execution of a block; enforcement must be supplied separately. ISO/IEC 27001: A.8.12: Operate inspection in a leakage-protection workflow with defined alert triage, warnings, blocking or another protective response matched to the buyer’s policy. - NIST AI RMF: MANAGE 1.3 — The pre-submit policy decision can implement part of a planned AI risk response when linked to the buyer’s documented priorities. Inspection alone does not show that the selected response is carried out. - ISO 42001: A.9.2 — A pre-submit policy check helps operationalize responsible-use rules for prompts. It must be connected to the buyer’s rule and response process to govern use effectively. ## GRD-002: Inspect file uploads before submission - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT3 - Formerly: DAT-005 - URL: /r/GRD-002 **Acceptance criteria:** Apply eligible detection models to uploaded files, summarize the alert, and document coverage differences between files and typed text. **Why it matters:** Files carry far more data than typed prompts, and many tools treat uploads as a separate, weaker path. **How to verify:** Sensitive DOCX, PDF, XLSX and CSV uploads are inspected before submission; coverage differences are documented. **OWASP adoption context:** The listed shadow, assistant, platform and citizen-workflow contexts cover common upload paths; file-inspection support must be demonstrated for each eligible surface. **Mappings:** - NIST CSF 2.0: PR.DS-02; SOC 2: CC6.7; ISO 27001: A.8.12 — File inspection extends disclosure-detection inputs to uploads before submission. Alert summaries and file-versus-text coverage limits support transfer decisions, but inspection alone does not stop a prohibited upload. ISO/IEC 27001: A.8.12: Use an operated leakage-protection workflow with defined alert triage, warnings, blocking or another protective response. Make unsupported formats, encryption and parser limits visible. - NIST AI RMF: MANAGE 1.3 — Documented file-versus-text coverage differences inform the scope and limits of planned AI risk responses. They do not establish that an effective response is applied to every upload. - ISO 42001: A.9.2 — Inspecting uploaded files provides a detection stage in an AI-input-use procedure. This link requires documented rules for prohibited input and an operated disposition for findings; inspection and alert summaries alone do not establish the whole procedure. ## GRD-003: Classify sensitive information semantically in ordinary business language - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DAT-002 - URL: /r/GRD-003 **Acceptance criteria:** Detect context and intent without depending on formatted identifiers, regex, file labels or exact keywords, and keep detecting when the user asks to translate, rewrite, summarize or reformat the same content. **Why it matters:** Most valuable business information has no fixed format. Pattern matching misses it, and rewording defeats it. **How to verify:** Unstructured sensitive text, including translated and reworded versions, is detected on default configuration. **OWASP adoption context:** Semantic classification follows the business content across the listed employee AI contexts rather than relying on a particular application or account type. **Mappings:** - NIST CSF 2.0: PR.DS-02, PR.DS-10 — Recognizing sensitive meaning in prompts, including translated or rewritten content, supplies detection inputs for protecting data in use and in transit. Recognition does not itself stop transmission. - NIST AI RMF: MEASURE 2.10 — Where the recognized content includes personal data, semantic findings provide evidence for examining privacy risks. Security sensitivity alone is not a privacy assessment, and findings need documented evaluation. - SOC 2: CC6.7, C1.1; ISO 27001: A.8.12, A.5.12 — Semantic classification helps identify designated confidential information and feed leakage rules and sensitivity categories. It does not define the buyer’s classification scheme or enforce egress restrictions; rewrite-resistant quality needs testing. SOC 2: C1.1: The Confidentiality category and relevant information must be in scope. ISO/IEC 27001: A.8.12: Use an operated leakage-protection workflow with defined alert triage, warnings, blocking or another protective response. ## GRD-004: Detect and coach in the languages your workforce uses - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT1–AT4 - Formerly: DAT-019 - URL: /r/GRD-004 **Acceptance criteria:** Detect sensitive content in every language the workforce uses, including mixed-language prompts and translated text, and show coaching messages in the employee's language. **Why it matters:** A control that only reads English leaves much of the workforce unprotected. **How to verify:** Sensitive information is detected in all the languages required for your workforce. **OWASP adoption context:** Employees write prompts in their working language across every listed context, so detection quality should be measured for each language in use. **Mappings:** - NIST CSF 2.0: PR.DS-10; ISO 27001: A.8.12 — Detection that works in each working language extends data-in-use protection and leakage prevention to employees who do not prompt in English. Coverage must be demonstrated per language; a result for one language does not carry over to another. - NIST AI RMF: MEASURE 2.3, MEASURE 2.5; ISO 42001: A.6.2.4; SOC 2: CC4.1 — Per-language detection and false-positive results, with the test-set size and composition, provide performance and validation evidence. The buyer chooses the languages and thresholds; results from a vendor corpus still need testing on the buyer's own content. ## GRD-005: Detect general, customer, employee and bulk PII - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DAT-009 - URL: /r/GRD-005 **Acceptance criteria:** Correctly classify realistic personal, customer, employee and multi-person records inside contextual prompts. **Why it matters:** Personal data is the most regulated thing employees paste into AI, often as whole records rather than single fields. **How to verify:** Realistic customer, employee and multi-person records in pilot prompts are detected on default configuration. **OWASP adoption context:** Personal data can be submitted through any listed employee AI context; the tier does not determine whether the content is sensitive. **Mappings:** - NIST CSF 2.0: PR.DS-02 — Contextual recognition of individual and bulk personal records supplies a detection input for protecting data in transit. Classification alone does not prevent release. - NIST AI RMF: MEASURE 2.10 — Personal-data findings make relevant privacy exposure visible for examination and documentation. Recognizing PII does not complete the AI system’s privacy-risk assessment. - SOC 2: CC6.7, C1.1 — PII recognition informs transfer controls and, for records designated confidential, confidential-information identification. It does not establish notice, consent or a complete privacy program. C1.1 applies only when the Confidentiality category and relevant information are in scope. - ISO 27001: A.8.12, A.5.34 — Contextual PII recognition feeds leakage controls and privacy safeguards. A.8.12 needs an operated leakage-protection workflow with approved handling rules and defined alert triage, warnings, blocking or another protective response. Detection does not determine a lawful basis, fulfill privacy rights or establish regulatory compliance. ## GRD-006: Detect sensitive health and workforce information - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DAT-010 - URL: /r/GRD-006 **Acceptance criteria:** Recognize sensitive patient, clinical-research and employee information in context, including when users summarize or rewrite it. Document supported prompts and file types. **Why it matters:** Sensitive records can appear in everyday prose, not just structured forms or obvious identifiers. **How to verify:** Test synthetic health and workforce examples in prompts and supported files, including summarization requests. Compare results with nonsensitive reference text. **OWASP adoption context:** Employee records can flow through shadow use, assistants, integrated platforms and citizen workflows, making those the primary workforce-data test contexts. **Mappings:** - NIST CSF 2.0: PR.DS-02 — Recognizing named employee medical, accommodation, compensation and performance details supplies a detection input for in-transit protection. Detection alone does not restrict disclosure. - NIST AI RMF: MEASURE 2.10 — Findings about named employees make privacy exposure and potential impacts on individuals or groups visible for assessment. Recognizing sensitive workforce prose does not itself examine or document the full consequences. - SOC 2: CC6.7, C1.1 — Workforce-record recognition informs release restrictions and identification of records designated confidential. Permitted use, access and retention remain organizational decisions; this does not establish a privacy program. C1.1 applies only when the Confidentiality category and relevant information are in scope. - ISO 27001: A.8.12, A.5.34 — Detection of named employee records feeds leakage-control decisions and privacy safeguards. A.8.12 needs an operated leakage-protection workflow with defined alert triage, warnings, blocking or another protective response. Monitoring these records itself needs approved privacy handling; detection does not determine employment-law or privacy compliance. ## GRD-007: Detect confidential commercial information - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT3 - Formerly: DAT-011 - URL: /r/GRD-007 **Acceptance criteria:** Cover pipeline, pricing, contracts, supplier terms, financial projections, M&A and investment data. **Why it matters:** Pricing, contracts and deal information are often a company's most valuable data and rarely follow a pattern. **How to verify:** Commercial information in unstructured pilot prompts is detected on default configuration. **OWASP adoption context:** Commercially confidential information can appear across the listed employee AI settings; its sensitivity depends on the content and business context, not the tier. **Mappings:** - SOC 2: C1.1, CC6.7; ISO 27001: A.8.12, A.5.12 — Recognition of designated confidential commercial information supports its identification, sensitivity classification and leakage rules. The buyer’s classification policy and enforcement action are still required. SOC 2: C1.1: The Confidentiality category and relevant information must be in scope. ISO/IEC 27001: A.8.12: Use an operated leakage-protection workflow with defined alert triage, warnings, blocking or another protective response. Recognizing M&A or financial content does not classify every record. - NIST CSF 2.0: PR.DS-02 — Recognizing confidential commercial content supplies a specific input to data-in-transit protection. Use findings in an operated leakage-protection workflow; classification alone neither prevents release nor maintains an inventory. ## GRD-008: Detect secrets, technical configuration and security-operations detail - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DAT-012 - URL: /r/GRD-008 **Acceptance criteria:** Detect standard and homegrown keys, API tokens, credentials, connection strings, internal hostnames, network ranges and infrastructure config, plus narrative incident reports and customer authentication or session detail. **Why it matters:** One leaked credential or network detail can turn an AI prompt into a breach. **How to verify:** Standard and homegrown secrets, hostnames and incident details are detected in pilot prompts. **OWASP adoption context:** Secrets and configuration details can enter prompts across the listed employee AI settings, including technical and code-agent work. **Mappings:** - NIST CSF 2.0: PR.DS-02, DE.CM-09 — Detection of credentials, configuration and security narratives provides runtime/data-monitoring evidence and inputs to in-transit protection. A finding alone does not stop disclosure. - SOC 2: CC6.7, CC6.1; ISO 27001: A.8.12, A.5.17 — Credential and infrastructure findings can feed leakage controls and protect authentication information. Detection does not manage credential allocation, storage, rotation or revocation; incident narratives are not automatically credentials. ISO/IEC 27001: A.8.12: Use an operated leakage-protection workflow with defined alert triage, warnings, blocking or another protective response. - ISO 42001: A.9.2 — Detecting secrets and security-operations detail supplies a specific input to responsible AI-use procedures. This link requires documented prohibited-input rules and an operated disposition; the detector does not define or operate the whole process. ## GRD-009: Detect proprietary source code and engineering content - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DAT-013 - URL: /r/GRD-009 **Acceptance criteria:** Identify source code exposure across browser, IDE, desktop, CLI and agent workflows. **Why it matters:** Source code is pasted into AI tools daily, across more surfaces than any other data type. **How to verify:** Proprietary code is detected in browser, IDE, CLI and agent use by pilot users. **OWASP adoption context:** Source code and engineering material can move through assistants, platforms and agent workflows as well as shadow tools; protection should follow the content. **Mappings:** - NIST CSF 2.0: PR.DS-02, DE.CM-09 — Code-exposure findings across browser, IDE, desktop, CLI and agent paths supply runtime-monitoring and in-transit protection inputs. Demonstrated detection coverage does not imply every transfer is stopped. - NIST AI RMF: MANAGE 1.3 — Source-code detection informs planned disclosure-risk responses and responsible-use rules across AI channels. The buyer still needs to select and operate the response. - SOC 2: C1.1, CC6.7; ISO 27001: A.8.12 — Identifying exposure of code designated confidential supplies inputs to confidentiality and leakage controls. It does not establish ownership, licensing compliance, repository access management or enforced prevention. SOC 2: C1.1: The Confidentiality category and relevant information must be in scope. ISO/IEC 27001: A.8.12: Use an operated leakage-protection workflow with defined alert triage, warnings, blocking or another protective response. - ISO 42001: A.9.2 — Detecting source-code exposure supplies a specific input to responsible AI-use procedures across the supported channels. This link requires documented prohibited-input rules and an operated disposition; detection alone does not select or implement the response. ## 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. ## GRD-011: Maintain acceptable detection quality - Area: Runtime Guardrails - Verification: Live test + Documentation - OWASP adoption tier: AT0–AT4 - Formerly: DAT-008 - URL: /r/GRD-011 **Acceptance criteria:** Report the false-alert proportion: reviewed flagged events judged benign divided by all reviewed flagged events, over a defined window. Document the sample size and composition; under 5% where that target is adopted. Separately report the missed-detection rate using a labeled test corpus: cases expected to be flagged but not flagged divided by all cases expected to be flagged. Include results by data class. **Why it matters:** False positives decide whether employees and the SOC tolerate a control. A noisy one gets switched off. **How to verify:** Review a representative sample of flagged pilot events and calculate the false-alert proportion. Separately run a labeled test corpus and calculate the missed-detection rate by data class. Record the numerator, denominator and test scope for each metric. If a denominator is zero, report the rate as not measurable. **OWASP adoption context:** Detection quality should be tested across the listed employee AI contexts because supported surfaces, payloads and user behavior can change error rates. **Mappings:** - NIST CSF 2.0: ID.IM-01, ID.IM-02 — Documented false-positive and false-negative results help identify improvements from evaluations and tests. These outcomes concern identifying improvements, not implementing every finding. - NIST AI RMF: MEASURE 2.3, MEASURE 2.5; ISO 42001: A.6.2.4, Cl. 9.1 — Measured error results, a stated corpus and the test-set composition provide performance, verification and reliability evidence. Deployment relevance and generalization limits still need evaluation; the adopted target is not universal proof of validity. - SOC 2: CC4.1, CC7.2; ISO 27001: Cl. 9.1, A.8.29 — Defined-window detector results evaluate control effectiveness and support acceptance testing. The buyer still needs measurement owners, cadence and analysis; the optional under-5% target is a buyer choice, not a framework threshold. ISO/IEC 27001: Cl. 9.1: Metrics must evaluate information-security performance or control effectiveness; generic business metrics do not qualify. ## GRD-012: Apply policy by user, group, role, department, tool, account plan and risk context - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: POL-001 - URL: /r/GRD-012 **Acceptance criteria:** Show differentiated rules for high-risk and trusted populations, beyond a blanket allow or block, including distinct treatment by approval state: approved, restricted, unapproved, personal, free and unauthorized use. Resolve users to approved identity attributes from the directory or HR system so rules and reports can key off department and role. **Why it matters:** Different teams carry different risk. One rule for everyone is either too loose or too blunt. **How to verify:** Two pilot groups get different outcomes for the same content, driven by directory attributes. **OWASP adoption context:** User and business-context rules must follow employees across the listed AI settings; adoption tier alone is too coarse to decide authorization. **Mappings:** - SOC 2: CC6.3, CC6.7; ISO 27001: A.8.3, A.5.15 — Directory-resolved roles and other identity attributes let AI-use rules distinguish authorized populations, operations and destinations. This connects policy and identity context to contextual access decisions; showing differentiated rules alone does not demonstrate that access or data-transfer restrictions are enforced. ISO/IEC 27001: A.8.3: Restrictions must take effect before the operation. An attribute feed does not establish identity lifecycle management, and incorrect or stale HR/directory attributes can undermine policy. - NIST CSF 2.0: GV.PO-01, PR.AA-05 — Contextual rules and directory-resolved attributes support cybersecurity policy and access authorization. Test the resulting permissions in practice; consuming identity attributes does not manage identity or credential lifecycles. ## GRD-013: Support monitor, warn, block, and restrict actions - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT1–AT4 - Formerly: DAT-003 - URL: /r/GRD-013 **Acceptance criteria:** Set the action per policy and let the policy owner configure the intervention choices and block-page wording including removing any bypass, and record both the evaluation and the action. Support a monitor-first rollout. Where policy permits a user to proceed after a warning, require a business justification before continuing. Do not offer an override where policy disables bypass. **Why it matters:** A control that can only block drives work onto personal devices. Graduated actions let policy match the risk. **How to verify:** Pilot users see monitor, warn and block outcomes with your wording, and each action is logged. For a warning policy that permits proceeding, show that the user must enter a business justification before continuing. For a blocking policy configured with no bypass, show that the user cannot override the block. **OWASP adoption context:** Intervention options are relevant across ordinary employee AI and connected-agent workflows, but each surface may support different monitor or enforcement actions. **Mappings:** - NIST CSF 2.0: PR.DS-02 — Configured block or restrict actions can protect data in transit when they act before egress. Monitor and warning modes do not establish enforced prevention. - NIST AI RMF: MANAGE 1.3; ISO 42001: A.9.2 — Owner-configured interventions translate documented AI risk responses and responsible-use rules into operational choices. Their effect depends on the selected action; monitor-first rollout does not imply blocking. - OWASP ASI: ASI02 — Policy-controlled interventions can limit agent tool misuse when applied to the tool action itself. General prompt monitoring does not establish that unsafe tool invocations are constrained. - SOC 2: CC5.3, CC6.7; ISO 27001: Cl. 8.1, A.8.12, A.8.15 — Configurable interventions operationalize data-handling policy, and evaluation/action records provide an event trail. To prevent disclosure, restrictive actions must be enabled and tested before transfer; monitoring and warnings do not prevent egress. ISO/IEC 27001: A.8.12: Use an active, approved leakage-control workflow at the stated data boundary; classification alone is insufficient. If claiming blocking, demonstrate it before egress. A.8.15: Keep attributable event records with appropriate retention, protection and analysis; a live view is insufficient. Policy approval, rollout criteria and exception ownership remain organizational responsibilities. ## GRD-014: Prevent sensitive data reaching unauthorized tools or account tiers - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DAT-004 - URL: /r/GRD-014 **Acceptance criteria:** Block before egress while allowing legitimate work and treating sanctioned and personal tiers differently. **Why it matters:** The same content can be fine in an enterprise tenant and a reportable incident in a personal one. **How to verify:** The same sensitive content is allowed to the enterprise tenant and stopped for a personal account. **OWASP adoption context:** Unauthorized destinations and account tiers can occur throughout the listed employee AI contexts; an approved tool name alone does not establish an approved destination. **Mappings:** - NIST CSF 2.0: PR.AA-05, PR.DS-02; SOC 2: CC6.7; ISO 27001: A.8.12, A.8.3, A.5.14 — Blocking sensitive data before egress to unauthorized tools or account tiers enforces a concrete authorization and transfer boundary. Coverage must include actual routes and tier changes; sanctioned status does not authorize every transfer. Classification, monitoring and warnings alone do not enforce these restrictions. ISO/IEC 27001: A.8.12: Use an active, approved leakage-control workflow at the stated data boundary. If claiming blocking, demonstrate it before egress. A.8.3: Access restrictions must act before the operation. Correct sensitivity and account-tier identification are prerequisites. - NIST AI RMF: MANAGE 1.3 — Pre-egress blocking is a mitigation option for the identified AI disclosure risk. The buyer must connect the policy to documented risk priorities and response decisions. - ISO 42001: A.9.2 — Blocking sensitive data before it reaches an unauthorized tool or account implements a specific responsible-use rule for AI inputs. Define the permitted destinations and verify enforcement; destination approval alone does not establish conformity with the AI system’s intended functions. ## GRD-015: Coach employees in the moment - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT4, AT6 - Formerly: DAT-018 - URL: /r/GRD-015 **Acceptance criteria:** Show prompt-specific guidance naming the policy issue, and return the same feedback into developer tooling and MCP clients where the action originates there. **Why it matters:** Coaching that names the issue and the safe alternative changes behavior; an unexplained block teaches nothing. **How to verify:** Pilot users see prompt-specific guidance with your policy links in the browser, IDE and MCP client. **OWASP adoption context:** In-the-moment guidance is relevant across employee AI and connected-agent use, wherever the interaction can present a meaningful warning or explanation. **Mappings:** - NIST CSF 2.0: GV.PO-01, PR.AT-01; SOC 2: CC2.2, CC1.4 — Prompt-specific guidance communicates the policy issue and an approved action where the employee is working. This contributes to policy awareness and competence development, but receiving a warning does not demonstrate competence or complete training. - NIST AI RMF: GOVERN 2.2; ISO 42001: Cl. 7.2, Cl. 7.3 — In-context explanations of AI policy and safe actions contribute to AI-risk training, awareness and competence development. They must reach users in developer tools and MCP clients too; coaching alone does not demonstrate required competence. - ISO 27001: Cl. 7.3, A.6.3 — Delivered safe-action guidance is a security-awareness intervention at the decision point. A.6.3 needs guidance to reach relevant employees, including feedback from tools; recommendations alone are insufficient. Validate its reach and usefulness. A warning does not demonstrate competence or replace the wider awareness and training program. ## GRD-016: Explain each decision to the employee and the analyst - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DAT-020 - URL: /r/GRD-016 **Acceptance criteria:** Show which detection or policy triggered and highlight the content that caused it, both in the employee's coaching message and in the analyst's alert, so the employee can fix the prompt and the analyst can confirm the decision without opening another tool. **Why it matters:** Explaining the trigger lets the employee fix the prompt and the analyst confirm the decision, which cuts tickets on both sides. **How to verify:** The coaching message and the alert both show the detection that fired and highlight the content. **OWASP adoption context:** Employees and analysts meet these decisions in every listed context, so explanations should appear wherever the intervention does. **Mappings:** - NIST CSF 2.0: DE.AE-02, PR.AT-01; SOC 2: CC2.2, CC7.3; ISO 27001: A.5.25, A.6.3 — Naming the trigger and the content behind it gives analysts what they need to evaluate an event and gives employees specific, in-context awareness of the policy. Explanations must not expose more sensitive content than the viewer is entitled to see. - NIST AI RMF: MEASURE 2.9; ISO 42001: A.8.2 — Showing why a detection fired explains the control's output to the people it affects and documents how the decision was reached. It explains the decision, not the internal workings of the detection model. ## GRD-017: Provide sensible policy defaults and no-code authoring - Area: Runtime Guardrails - Verification: Walkthrough - OWASP adoption tier: AT0–AT4, AT6 - Formerly: POL-006 - URL: /r/GRD-017 **Acceptance criteria:** Editable baseline policies and recommended settings without regex or specialist rule writing. **Why it matters:** Policy work should not require regex skills. **How to verify:** Show the default policy set and author a new policy without writing patterns. **OWASP adoption context:** Policy-authoring usability and defaults are governance-platform concerns across adoption tiers, rather than properties of a particular AI deployment pattern. **Mappings:** - NIST CSF 2.0: GV.PO-01; NIST AI RMF: GOVERN 1.4; ISO 42001: A.2.2; SOC 2: CC5.3; ISO 27001: A.5.1, A.5.10 — Editable baseline policies and recommended settings help turn AI-risk decisions into documented security and acceptable-use rules. Easy authoring is an input to establishing and deploying policy; template availability does not establish approval, communication, review or enforcement. ## GRD-018: Turn acceptable-use policy into enforceable scenarios - Area: Runtime Guardrails - Verification: Walkthrough + Proof of value - OWASP adoption tier: AT0–AT4 - Formerly: GOV-007 - URL: /r/GRD-018 **Acceptance criteria:** Express AUP rules as policies and demonstrate enforcement. **Why it matters:** An acceptable-use policy only matters if it can be enforced and shown to be enforced. **How to verify:** Three clauses from your AUP are expressed as policies and successfully tested in your pilot. **OWASP adoption context:** Acceptable-use rules need concrete scenarios across the listed employee AI contexts rather than a policy that only addresses one application type. **Mappings:** - NIST CSF 2.0: GV.PO-01; ISO 42001: A.2.2, A.9.2; SOC 2: CC5.3, CC4.1; ISO 27001: Cl. 8.1, A.5.10, A.5.36 — Translating approved acceptable-use rules into executable scenarios connects organizational policy to responsible-use procedures and practical restrictions. Would-have-fired and actual-action records help evaluate implementation; simulation alone does not demonstrate operational enforcement, policy communication or a completed periodic compliance review. - NIST AI RMF: GOVERN 1.2 — Executable acceptable-use scenarios and their results help operationalize trustworthy-AI characteristics in organizational policy and practice. Coverage depends on which characteristics the approved rules actually address. ## GRD-019: Roll out policy in stages, starting in monitor-only mode - Area: Runtime Guardrails - Verification: Walkthrough + Proof of value - OWASP adoption tier: AT0–AT4, AT6 - Formerly: POL-007 - URL: /r/GRD-019 **Acceptance criteria:** Start new policies in monitor-only mode, then escalate to coaching and blocking group by group. Policy changes reach every enforcement point within minutes, and every change is recorded with who made it, what changed and when. **Why it matters:** Nobody should switch on blocking before seeing what monitoring finds. **How to verify:** A policy moves from monitor to coach to block for one pilot group; record how long changes take to apply. **OWASP adoption context:** Policies reach employees across every listed context, so staged rollout should apply to each surface, not only the browser. **Mappings:** - NIST CSF 2.0: PR.PS-01, ID.RA-07; SOC 2: CC8.1; ISO 27001: A.8.32, A.8.9 — Staged rollout, fast propagation and a change record bring policy updates under configuration and change control. The buyer still sets the approval and review steps that decide when a group moves from monitoring to enforcement. - NIST AI RMF: MANAGE 1.3; ISO 42001: Cl. 6.3 — Observing first and escalating by group is a planned, risk-based response to what monitoring finds. It is evidence of planned change; it does not decide on its own which response each risk needs. ## GRD-020: Scope exceptions to a single detection for a defined group - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: Tier-independent - Formerly: POL-009 - URL: /r/GRD-020 **Acceptance criteria:** Grant an exception for one detection, data class or tool to one group, leaving every other protection in place for that group. For example, a deal team can discuss financial projections without losing credential or personal-data protection. Document a named owner, business rationale and review date for each exception. **Why it matters:** A team that needs latitude on one data type should not lose every other protection. **How to verify:** One detection is relaxed for a pilot group while all other detections still fire for that group. Show the documented exception owner, business rationale and review date. **OWASP adoption context:** Exceptions apply wherever the group works, so a scoped exception should behave the same across every listed context. **Mappings:** - NIST CSF 2.0: ID.RA-07, PR.AA-05; SOC 2: CC6.3, CC5.3; ISO 27001: A.5.15, Cl. 6.1.3 — A narrowly scoped exception records a specific deviation and keeps least privilege in place for everything else. The exception still needs an owner, a rationale and a review date. ISO/IEC 27001: The exception record supports Cl. 6.1.3 only when linked to risk assessment, the risk owner’s approval of the treatment plan and acceptance of residual risk. A named owner, business rationale and review date alone do not establish those decisions. - NIST AI RMF: GOVERN 1.4 — Granular exceptions keep the risk-management process transparent about exactly which control is relaxed and for whom. The rationale for each exception must still be documented. ## GRD-021: Keep typical added inline latency under 300 ms - Area: Runtime Guardrails - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: ARC-013 - URL: /r/GRD-021 **Acceptance criteria:** State the added policy-decision latency and the conditions it was measured under, and document the behavior when a decision is slow or unavailable, including whether the control fails open or closed. **Why it matters:** Added delay decides whether real-time enforcement is practical or only theoretical. **How to verify:** Record the added decision time on pilot prompts and the behavior when a decision is slow. **OWASP adoption context:** The listed assistant, platform and agent contexts can place controls inline with work, making added latency and failure behavior important deployment tests. **Mappings:** - SOC 2: CC9.1 — Measured policy-decision latency and documented slow/unavailable behavior provide operational-design and disruption-planning inputs. The buyer must assess fail-open/fail-closed trade-offs; a latency number alone establishes neither adequate capacity nor acceptable risk, and 300 ms is not a framework threshold. - NIST AI RMF: MEASURE 2.3; ISO 42001: Cl. 9.1 — Latency results under stated test conditions provide performance-measurement evidence for evaluating AI operation against chosen objectives. The buyer must judge deployment relevance and acceptable failure behavior; documentation alone does not demonstrate performance under every operating condition. - ISO 27001: Cl. 9.1, Cl. 8.1 — Measured policy-decision delay and documented slow or unavailable behavior provide security-control performance and operational-design evidence. Define the measurement method, responsibility, cadence and evaluation, and adopt acceptable failure criteria. ISO sets no 300 ms target; a latency number does not establish capacity or acceptable fail-open risk. - NIST CSF 2.0: PR.IR-03 — Documented slow or unavailable behavior, including fail-open or fail-closed choices, informs resilience design. Test the behavior under adverse conditions and assess its acceptability; a latency measurement alone does not establish resource capacity. ## AGT-001: Govern tool calls at read, write and delete scope - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT1, AT3, AT4, AT6 - URL: /r/AGT-001 **Acceptance criteria:** Permit a read while refusing write, delete or other destructive actions, with every attempt logged and attributable. **Why it matters:** One agent can read, write and delete in the same workflow. Allow or deny per app is too blunt. **How to verify:** Reads to a connected system are allowed while attempts to change or delete information are blocked. **OWASP adoption context:** Citizen-built, code-executing and MCP-extended workflows can take consequential tool actions, making operation-level permissions relevant. **Mappings:** - NIST CSF 2.0: PR.AA-05; SOC 2: CC6.3; ISO 27001: A.8.3, A.8.15 — Allowing reads while refusing writes, deletes and destructive operations enforces least privilege at the tool-call boundary. Enforce restrictions before the operation and record every attempt with usable attribution, retention, protection and analysis. Warnings or a live view alone are insufficient; runtime refusal does not review or revoke the underlying connector grant. - ISO 42001: A.9.2 — A defined, enforced boundary between permitted reads and prohibited destructive actions implements a concrete responsible-use procedure for agents. It contributes to the wider AI-use process without implying that the standard prescribes these exact API scopes. - OWASP ASI: ASI02, ASI03 — Operation-level refusal limits destructive tool misuse and actions attempted through excessive or misapplied delegated identity. Attributable attempts help investigate those failures; the control covers the operations and tool paths where it is enforced. ## AGT-003: Inspect sensitive data retrieved through connectors mid-workflow - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT3, AT4, AT6 - URL: /r/AGT-003 **Acceptance criteria:** Detect when an agent picks up sensitive content from one connnected tool and attemps to share it with a separate tool, even if the user prompt was benign. **Why it matters:** Connectors pull sensitive data into a conversation even when the user's question is harmless. **How to verify:** When an agent picks up sensitive information from one tool or dataset and attempts to share it with a different tool, the even is blocked if it violates policy. **OWASP adoption context:** Embedded assistants, integrated platforms, citizen workflows and MCP extensions can retrieve sensitive data after a benign prompt; inspect the returned payload. **Mappings:** - NIST CSF 2.0: PR.DS-02, DE.CM-09; SOC 2: CC6.7, C1.1; ISO 27001: A.8.12 — Inspecting connector payloads reveals sensitive information entering a workflow even when the prompt is benign, supplying runtime evidence for transfer, confidentiality and leakage controls. Detection alone does not restrict later disclosure; finding sensitive content also does not establish poisoned context. SOC 2: C1.1: The Confidentiality category and relevant information must be in scope. ISO/IEC 27001: A.8.12: Operate inspection within a leakage-protection workflow with defined alert triage, warnings, blocking or another protective response. - NIST AI RMF: MEASURE 2.10 — Where retrieved content includes personal data, the findings inform examination of privacy risk within the AI workflow. Recognizing sensitive content is one input to that examination, not a complete privacy-risk assessment. ## PLT-002: Disclose where decisions are enforced and how the control fails - Area: Platform, Privacy & Assurance - Verification: Documentation + Live test - OWASP adoption tier: AT0–AT4 - Formerly: ARC-015 - URL: /r/PLT-002 **Acceptance criteria:** Enforce before submission, so a blocked payload is never sent and a denied tool call never runs. State where each decision is evaluated (device, browser or cloud), whether TLS interception, a forward proxy or a managed certificate is required, and whether each surface fails open or fails closed. **Why it matters:** Where a decision runs and how it fails decide whether data is actually stopped. **How to verify:** The vendor documents enforcement points and failure modes per surface, and the pilot confirms them. **OWASP adoption context:** Enforcement points and failure behavior can differ by surface, so each listed context needs its own answer. **Mappings:** - NIST CSF 2.0: PR.IR-03, PR.DS-02; SOC 2: CC6.7, CC9.1; ISO 27001: A.8.27, A.8.20 — A documented enforcement point and failure mode support secure-architecture and resilience decisions, and show whether data in transit is actually stopped. Neither fail-open nor fail-closed is right in every case; the buyer must choose per surface and test the behavior. SOC 2: CC6.7 supports restrictions on unauthorized data transfers. Tested fail-open/fail-closed behavior provides evidence for assessing disruption risks and selecting mitigation under CC9.1. The buyer must approve the trade-off and implement the response; documenting a failure mode alone does not establish a complete mitigation plan. - NIST AI RMF: MAP 4.2; ISO 42001: A.6.2.5 — Knowing where decisions run and what happens when they cannot be made documents the control's deployment requirements and dependencies. It is readiness evidence, not proof of correct behavior under failure. ## PLT-007: Resist common circumvention paths - Area: Platform, Privacy & Assurance - Verification: Live test - OWASP adoption tier: AT0, AT3, AT4, AT6 - Formerly: ARC-011 - URL: /r/PLT-007 **Acceptance criteria:** Test disabling the extension, switching browser or private mode, personal accounts and desktop or CLI routes; document residual gaps. **Why it matters:** A control that is easy to bypass gives false assurance. **How to verify:** Pilot testers try disabling the extension, switching browser and using CLI routes; record residual gaps. **OWASP adoption context:** Shadow tools and code-agent workflows are primary contexts for testing alternate execution and connection paths that may evade the intended controls. **Mappings:** - NIST CSF 2.0: ID.IM-02, ID.RA-01; NIST AI RMF: MEASURE 1.2; ISO 42001: A.6.2.4; SOC 2: CC4.1, CC7.1; ISO 27001: Cl. 9.1, Cl. 6.1.2, A.8.29 — Circumvention tests and recorded residual gaps provide control-effectiveness and verification/acceptance-testing evidence, identify vulnerabilities and inform risk assessment and improvements. Tests must match the deployment and include results; they do not establish that every route was tested or each gap was fixed or accepted by its risk owner. ISO/IEC 27001: Define responsibility, frequency and evaluation for security-performance or control-effectiveness measures; generic business metrics do not qualify.