# NIST AI RMF Mapping — 54 Workforce AI Security Requirements > Workforce AI security requirements mapped to NIST AI Risk Management Framework, clause by clause. Govern, Map, Measure and Manage functions for trustworthy AI. Source: Harmonic Security, updated October 2026. 54 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. ## SPM-001: Classify previously unseen AI applications on first encounter - Area: AI Security Posture Management - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DIS-014 - URL: /r/SPM-001 **Acceptance criteria:** Identify and risk-score an AI application the platform has not seen before, without waiting for a signature, category list or catalog update, and show the evidence behind the classification. **Why it matters:** Waiting for a catalog update leaves every new tool ungoverned during the period it is most likely to be tried. **How to verify:** An AI tool the vendor has not seen before is classified and risk-scored on first use, with the evidence shown. **OWASP adoption context:** Shadow AI is the primary first-encounter discovery scenario; an unfamiliar application should not require a prior catalog entry to become visible. **Mappings:** - NIST CSF 2.0: ID.AM-02, ID.RA-05; ISO 27001: Cl. 6.1.2, A.5.9 — Evidence-based first-encounter classification supplies timely software-inventory and risk-assessment inputs without catalog delay. A classification or score is not a maintained, owned inventory or a complete risk assessment. - NIST AI RMF: MAP 4.1 — Evidence behind unfamiliar-app classification helps map third-party AI component risks. The buyer must validate that evidence; signature-free detection is an implementation choice, not a complete risk-mapping process. - SOC 2: CC3.2, CC9.2 — New-service classification and scoring inform risk evaluation and supplier review. The buyer must validate scoring evidence and make the subsequent due-diligence and treatment decisions. - ISO 42001: A.4.2 — First-encounter identity and classification evidence help identify an AI resource for documentation. A one-time classification does not establish continued operational monitoring or support. ## SPM-006: Discover AI embedded in sanctioned SaaS - Area: AI Security Posture Management - Verification: Live test - OWASP adoption tier: AT0, AT4 - Formerly: DIS-010 - URL: /r/SPM-006 **Acceptance criteria:** Identify AI features inside existing SaaS tools, such as Google AI Mode. **Why it matters:** AI features switched on inside approved SaaS create new data flows without a new application to approve. **How to verify:** A common SaaS application is identified and cataloged as an AI tool due to its embedded AI features. **OWASP adoption context:** Vendor-embedded and platform-integrated AI can be present inside already approved SaaS, so discovering the host application alone is insufficient. **Mappings:** - NIST CSF 2.0: ID.AM-02, ID.AM-04; ISO 27001: A.5.9, A.5.22 — Discovery of AI features within existing SaaS supplies updates to the software and service inventory and flags supplier-service changes. A discovery finding must feed maintained records and does not itself complete change review. - NIST AI RMF: MAP 4.1 — Identifying embedded AI makes new third-party components and supplier capabilities visible for risk mapping and supplier governance. Existing SaaS approval does not assess the newly discovered AI feature. - SOC 2: CC2.1, CC9.2 — Embedded-feature findings keep control information and the supplier-risk picture current. The buyer still needs to review the feature and decide its permitted use. - ISO 42001: A.4.2 — Discovering an embedded SaaS AI feature identifies an AI resource or component for the resource record. Existing SaaS approval does not establish assessment of that newly discovered feature. ## SPM-008: Distinguish personal, free and guest accounts from sanctioned enterprise tenants - Area: AI Security Posture Management - Verification: Live test - OWASP adoption tier: AT0, AT1 - Formerly: DIS-006 - URL: /r/SPM-008 **Acceptance criteria:** Report a reliable account-type split at the point of use and allow policy to vary depending on account plan. **Why it matters:** Contractual protections attach to the enterprise tenant, not the domain. A personal account reaches the same URL with none of them. **How to verify:** Enterprise, personal and unauthenticated use of the same tool are each identified and handled per policy. **OWASP adoption context:** Personal-account and vendor-assistant contexts make account ownership and plan distinctions important; tier alone does not establish contractual safeguards. **Mappings:** - NIST AI RMF: MAP 4.1 — The account-plan distinction helps identify the third-party service context and supplier terms needing risk review. A plan label alone does not establish the applicable relationship or complete its assessment. - SOC 2: CC6.7, CC9.2; ISO 27001: A.8.3, A.5.23 — Reliable account-tier context can inform permitted data destinations, access restrictions and enterprise-cloud or supplier rules. The policy linkage must work in practice; classification alone does not enforce those rules. ISO/IEC 27001: Account identification does not manage the identity lifecycle. - NIST CSF 2.0: DE.CM-03 — The observed personal, free, guest or enterprise account context supports monitoring employee technology use. An account-plan label does not manage identities or credentials or enforce access. ## SPM-009: Risk-score AI tools, connectors and agent workflows - Area: AI Security Posture Management - Verification: Walkthrough - OWASP adoption tier: AT0–AT2 - Formerly: DIS-009 - URL: /r/SPM-009 **Acceptance criteria:** Configurable factors such as vendor location, training on inputs, trust-center availability, account tier, autonomy, data sensitivity and tool power. **Why it matters:** The risk in an AI tool usually sits in its data-handling terms, which change without the domain changing. **How to verify:** Risk scores, with sources and factors, for five tools. **OWASP adoption context:** Risk scoring spans ordinary employee AI and MCP-extended workflows because sensitivity, autonomy and tool power vary independently of approval status. **Mappings:** - NIST CSF 2.0: GV.RM-06, ID.RA-05 — Configurable risk factors can support a repeatable method for documenting and prioritizing inherent risk. The buyer must still define the method and connect scores to threats, likelihood, impact and response decisions. - NIST AI RMF: MAP 5.1 — Sensitivity, autonomy and tool-power factors can inform the likelihood and magnitude of impacts. A product score does not by itself document the full range of beneficial and harmful impacts. - OWASP ASI: ASI04 — Scoring connectors and agent workflows helps prioritize review of runtime-fetched tools and components exposed to agentic supply-chain risk. Scores do not verify component integrity. - SOC 2: CC3.2, CC9.2 — The configurable factors provide an AI risk-analysis step and inputs to repeat assessments and supplier due diligence. Risk criteria, likelihood, impact, ownership, acceptance and treatment remain the buyer’s responsibilities; a trust center is not assurance. - ISO 27001: Cl. 6.1.2, A.5.19 — Security-relevant scoring factors supply risk-analysis inputs; external-vendor factors also support supplier due diligence. The buyer must define risk criteria, likelihood, impact, ownership, acceptance and treatment. A score or vendor trust center is not a complete assessment or assurance; the supplier link applies only to external relationships. - ISO 42001: Cl. 6.1.2, Cl. 8.2, A.10.3 — ISO/IEC 42001: Validated tool and workflow risk factors provide inputs to the defined AI risk-assessment process and periodic or change-driven reassessments. A score does not establish a complete assessment, risk acceptance, treatment plan or assessment of effects on people or society. Supplier-specific factors, such as provider use of inputs and account terms, can also inform a defined responsible-AI supplier review; this supplier link applies only to external suppliers and validated evidence. ## SPM-010: Define default treatment for newly discovered AI services - Area: AI Security Posture Management - Verification: Live test - OWASP adoption tier: AT0, AT1 - Formerly: POL-004 - URL: /r/SPM-010 **Acceptance criteria:** Apply a documented default rule until the service is assessed as sanctioned, restricted or prohibited. **Why it matters:** New tools arrive faster than they can be assessed, so the default decides what happens in the meantime. **How to verify:** A tool first used during the pilot receives the documented default treatment. **OWASP adoption context:** Default treatment matters wherever employees can encounter a new AI service in the listed settings, before a full approval decision is available. **Mappings:** - NIST CSF 2.0: GV.PO-01; SOC 2: CC5.3, CC6.7; ISO 27001: Cl. 8.1, A.5.10, A.8.3 — Applying a documented default while a new service awaits assessment puts interim acceptable-use policy into operation. The default contributes to information-access and transfer restrictions only when its selected action actually restricts them; an applied permissive default is still a policy decision. ISO/IEC 27001: The chosen default must be approved and fit the organization’s risk treatment. - NIST AI RMF: MANAGE 1.1 — The interim rule records whether and under what conditions use may proceed before the service assessment is complete. It contributes to the proceed-or-do-not-proceed decision without replacing an assessment against the intended purpose and objectives. - ISO 42001: A.9.2 — A documented default for an unclassified AI service provides an interim responsible-use rule. The chosen default must be approved and fit the organization’s risk treatment; approval status is not the AI system’s intended function. ## SPM-011: Support the AI tool approval and review lifecycle - Area: AI Security Posture Management - Verification: Walkthrough - OWASP adoption tier: AT0–AT4, AT6 - Formerly: GOV-008 - URL: /r/SPM-011 **Acceptance criteria:** Define and track unapproved versus approved AI tools and MCP servers. **Why it matters:** Without a governed approval path, teams route around the control. **How to verify:** Walk a tool or MCP server request from intake to a recorded decision. **OWASP adoption context:** Managed assistants, platforms and connected-agent workflows need approval status and periodic review; status should be visible throughout the tool lifecycle. **Mappings:** - NIST AI RMF: GOVERN 6.1, MANAGE 3.1; SOC 2: CC9.2, CC5.3 — Approved/unapproved tool and MCP-server records supply inventory context and inputs to third-party governance and permitted-use review. Tracking status alone does not establish assessment criteria, due diligence, approval authority, periodic supplier review, retirement decisions, enforcement or conformity of actual use with its intended purpose. - ISO 27001: A.5.9, A.5.23 — Tool identity and approval status provide asset-register fields and, for cloud services, approval tracking within an operated cloud-use process. A status flag does not establish assessment criteria, approval authority, supplier due diligence, periodic review or retirement decisions. - ISO 42001: A.4.2 — Approved and unapproved tool records document AI resources and their status. They do not assess supplier responsibility or establish that actual use matches the system’s intended functions. - NIST CSF 2.0: ID.AM-02 — Approved and unapproved tool states provide concrete software and service-inventory attributes. Status tracking does not itself assess or manage changes and exceptions for cybersecurity risk. ## 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-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-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-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. ## IDR-002: Detect direct and indirect prompt injection attempts. - Area: AI Detection & Response - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DAT-014 - URL: /r/IDR-002 **Acceptance criteria:** Identify, block, and flag prompt injection attempts, whether directly entered into the AI tool or read via connections to third-party tools. **Why it matters:** Successful prompt injection can lead to sensitive data exfiltration or irreversible destructive agent actions. **How to verify:** Prompt injection attempts via user input or connected tools are detected and logged with evidence. **OWASP adoption context:** Jailbreak and misuse attempts can occur in any of the listed employee AI contexts; the tiers do not imply identical detection coverage. **Mappings:** - NIST CSF 2.0: DE.AE-02, DE.CM-09; SOC 2: CC7.2; ISO 27001: A.8.16, A.5.25 — Evidence of jailbreak, bypass and misuse attempts supports adverse-event analysis, security monitoring and event triage. A prompt attack is not automatically malware, and detection does not guarantee blocking. ISO/IEC 27001: A.8.16: Demonstrate analysis of anomalous or risky behavior beyond usage collection. Validate surface coverage, known gaps and false positives, with an event-assessment and response process. - NIST AI RMF: MEASURE 3.1; ISO 42001: A.6.2.6 — Detection evidence, tested coverage and known gaps support continuing identification of AI risks and operational monitoring. Findings must feed an ongoing tracking and review process; a detector alone does not establish that process. ## IDR-003: Identify use cases leading to elevated risk behavior. - Area: AI Detection & Response - Verification: Proof of value - OWASP adoption tier: AT0–AT4 - Formerly: VAL-005 - URL: /r/IDR-003 **Acceptance criteria:** Surface the use cases and teams that require additional training on safe usage principles. **Why it matters:** Repeat exposure and under-use point to where risk reduction or enablement will pay off. **How to verify:** High-risk use cases and the associated users are identified in a pilot. **OWASP adoption context:** Risky use and repeat exposure patterns can appear across the listed employee AI settings; low use is not itself proof of risk or failure. **Mappings:** - NIST CSF 2.0: DE.CM-03; NIST AI RMF: MEASURE 3.1; SOC 2: CC7.2; ISO 27001: Cl. 9.1, A.8.16 — Team-level risky-use and recurring-exposure patterns provide findings for usage monitoring, AI-risk tracking and evaluation against responsible-use/security objectives. Under-use alone is an enablement signal rather than a security anomaly; assessment and intervention remain necessary beyond surfacing patterns. ISO/IEC 27001: Confirm the need for monitoring and choose the interventions to apply. - ISO 42001: A.6.2.6 — Observed risky-use and recurring-exposure patterns provide ongoing operational-monitoring findings for in-scope AI systems or controls. Under-use alone is an enablement signal; surfacing patterns does not establish responsible-use objectives or complete assessment and intervention. ## IDR-004: Integrate with SIEM, SOAR, ticketing, and identity systems - Area: AI Detection & Response - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: GOV-003 - URL: /r/IDR-004 **Acceptance criteria:** Use webhooks or APIs to consume relevant employee identity context and to push alerts into logging and response systems. **Why it matters:** Security alerts need relevant context and need to stream to centralized repositories. **How to verify:** Pilot events can be enriched with employee identity context and streamed to your SIEM. **OWASP adoption context:** Operational integration with security, identity and service-management systems is a cross-tier governance capability. **Mappings:** - NIST CSF 2.0: DE.AE-06; SOC 2: CC7.3, CC7.4 — Structured webhooks and APIs can route adverse-event evidence into authorized staff’s monitoring, triage and incident-response workflows. A connector contributes only when delivery, ingestion, successful processing and the associated operational workflow are configured and exercised; it does not itself establish incident decisions or response ownership. - NIST AI RMF: GOVERN 4.3 — Feeding AI events into enterprise incident, ticket and evidence workflows enables organizational information sharing about AI issues. The connected teams still need to operate the associated reporting and response practices. - ISO 27001: A.5.25, A.8.15 — Structured telemetry and incident-ticket integration supply logging, analysis and event-triage inputs. Demonstrate delivery, ingestion, successful processing, correlation and triage routing. An endpoint alone does not establish incident decisions, response ownership or completed response. ## AGT-002: Flag destructive, over-scoped or anomalous agent actions - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT3, AT4, AT6 - URL: /r/AGT-002 **Acceptance criteria:** Detect excessive permissions, unexpected tools, destructive operations, abnormal call sequences and policy bypass. **Why it matters:** Destructive or unusual agent actions are often the first sign of a hijacked or misconfigured agent. **How to verify:** A destructive or out-of-pattern tool call in the pilot is flagged with context. **OWASP adoption context:** The listed connected-agent contexts can produce abnormal tool sequences, excessive scope or destructive operations that ordinary prompt inspection may miss. **Mappings:** - NIST CSF 2.0: DE.AE-02, DE.CM-09; ISO 42001: A.6.2.6; SOC 2: CC7.2, CC6.3; ISO 27001: A.8.16, A.5.18 — Detecting destructive operations, unexpected tools, abnormal call sequences and policy bypass supplies adverse-event analysis and monitoring of agent behavior. Excess-permission findings also inform access-right review; detection does not prevent an operation or reduce its permissions. ISO/IEC 27001: A.8.16: Event assessment and response remain wider dependencies; test false-positive and response handling. - NIST AI RMF: MANAGE 4.1 — Runtime findings supply the monitoring and evaluation component of post-deployment risk management. A detection capability alone does not establish the wider plan for user input, incident response, recovery and change management. - OWASP ASI: ASI02, ASI03, ASI10 — Destructive calls and excessive permissions expose tool-misuse and identity-abuse patterns; abnormal sequences and policy bypass can also flag rogue-agent behavior. These are indicators for investigation, rather than proof that every anomalous agent is compromised or that the behavior is contained. ## 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. ## AGT-005: Provide targeted containment for a single connector or tool. - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT1, AT2, AT3, AT6 - URL: /r/AGT-005 **Acceptance criteria:** Disable or revoke one connector, tool, plugin, or integration for a user or group without switching off the whole AI tool. **Why it matters:** When one connector misbehaves, switching off the whole AI tool punishes everyone. **How to verify:** One connector is disabled for one pilot group while the AI tool keeps working. **OWASP adoption context:** The listed agent contexts may share an AI client across multiple connectors, making targeted revocation preferable to disabling the whole tool when feasible. **Mappings:** - NIST CSF 2.0: RS.MI-01, RS.MI-02; SOC 2: CC6.3, CC7.4; ISO 27001: A.5.26, A.5.18 — Disabling an affected connector or revoking its token removes a specific access path and supplies an incident-containment action. It contributes to eradication only where it removes the compromised access mechanism; containment alone does not establish complete eradication or incident response. ISO/IEC 27001: A.5.26: Integrate containment into the buyer’s incident process. A.5.18: Review effective access and adjust or revoke it where required; cached access and in-flight actions may survive revocation. - NIST AI RMF: MANAGE 2.4; ISO 42001: A.6.2.6 — A targeted disablement mechanism enables disengagement of an unsafe AI dependency while other functions remain available. It contributes to operational response, but the capability alone does not establish who has authority to invoke it or a complete operational-support process. - OWASP ASI: ASI08 — Isolating a connector, tool or token can interrupt propagation through an agent workflow, matching the isolation and circuit-breaker approach to cascading failures. The scope and timing of disablement determine which downstream actions it can contain. ## AGT-006: Discover the MCP servers and connectors employees attach to their AI clients - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT3, AT4, AT6 - Formerly: DIS-007 - URL: /r/AGT-006 **Acceptance criteria:** Inventory local and remote MCP servers reached from desktop, IDE and CLI AI tools with owner, scope and exposure. **Why it matters:** MCP-capable clients now ship inside IDEs, terminals and desktop apps, and each connector is a new path to corporate data. **How to verify:** Local and remote MCP servers used by pilot users appear with client, owner, scope and exposure. **OWASP adoption context:** Citizen-built, code-executing and MCP-extended workflows can attach external servers, so connector discovery must reach those integration paths. **Mappings:** - NIST CSF 2.0: GV.SC-04, ID.AM-04; NIST AI RMF: MAP 4.1 — The MCP and connector inventory identifies third-party components and services, with owner, scope and exposure to inform supplier prioritization and component-risk mapping. Discovery alone does not assess their risks. - ISO 42001: A.4.2, A.10.3 — ISO/IEC 42001: The local and remote MCP/connector inventory documents resources relevant to AI activities, including their owner, scope and exposure, supporting A.4.2. External MCP servers and connectors also identify supplier relationships to govern under A.10.3; locally owned servers are not automatically suppliers. Inventory does not establish supplier due diligence or trustworthiness. - OWASP ASI: ASI04 — The inventory exposes external MCP servers and runtime-connected components relevant to agentic supply-chain compromise. It provides a review surface, not evidence that components are trustworthy. - SOC 2: CC2.1, CC9.2; ISO 27001: A.5.9, A.5.19 — Owned connector records supply usable inventory/control information and inputs to supplier-risk review. Keeping the register current does not itself approve a connector or reduce its permissions. ISO/IEC 27001: Maintain usable, owned inventory records. Internally owned servers are not automatically suppliers, and discovery does not assess supplier security. ## AGT-007: Map the actions available via each connector. - Area: Agent & MCP Governance - Verification: Walkthrough - OWASP adoption tier: AT3, AT4, AT6 - Formerly: DIS-008 - URL: /r/AGT-007 **Acceptance criteria:** Show, per connector/MCP server, what actions are available and which are currently enabled. **Why it matters:** Approving a connector without knowing which actions it exposes and which are enabled leaves the scope of available functionality unclear. **How to verify:** For three connectors you name, the console lists the actions each exposes and shows which are currently enabled. **Mappings:** - SOC 2: CC3.2, CC6.3; ISO 27001: Cl. 6.1.2, A.5.18 — An inventory of connector actions and their enabled status supports risk assessment and access-rights review. It provides review inputs; it does not demonstrate effective permissions or their enforcement. - NIST AI RMF: MAP 4.2 — Knowing which actions a connector exposes helps identify risks and control needs associated with third-party components. - OWASP ASI: ASI03 — Reviewing available and enabled actions helps identify unnecessarily broad functionality. Assessing identity and privilege abuse also requires evidence about agent identities, credentials and delegated permissions. These mappings concern action visibility and review, not reachable-file discovery or data-flow mapping. ## AGT-008: Support local and remote MCP gateway placement for employee AI clients - Area: Agent & MCP Governance - Verification: Walkthrough + Documentation - OWASP adoption tier: AT3, AT4, AT6 - Formerly: ARC-005 - URL: /r/AGT-008 **Acceptance criteria:** Support applicable Windows, macOS and Linux patterns, allow endpoint-integrated or remote placement, and define traffic coverage for each. **Why it matters:** Different MCP clients need different gateway placements to be covered. **How to verify:** The vendor shows local and remote MCP gateway placement and documents what each covers. **OWASP adoption context:** Citizen-built, code-executing and MCP-extended workflows motivate local or remote gateway placement; these contexts do not necessarily involve agent-to-agent communication. **Mappings:** - NIST AI RMF: MAP 4.2 — Documented MCP gateway placement identifies where component controls can operate and which traffic they cover. It supplies architecture evidence rather than proof of effective authentication or inspection. - ISO 42001: A.4.5 — Operating-system patterns, local or remote gateways and their dependencies provide computing-resource information for AI deployment. Availability of placement options does not establish secure operation. - OWASP ASI: ASI04 — An MCP gateway’s location and coverage can establish an inspection boundary for runtime-fetched servers and other agentic supply-chain components. Placement alone neither assesses their trustworthiness nor prevents malicious components. ## AGT-009: Detect indirect prompt injection in content agents read - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT3, AT4, AT6 - Formerly: DAT-014 - URL: /r/AGT-009 **Acceptance criteria:** Identify malicious instructions from the sources that AI systems are able to read from. Name the originating connector or source, respond before the agent acts where configured, and demonstrate tested coverage and known gaps. **Why it matters:** A poisoned tool response can turn a trusted agent into an attacker's tool while the user's prompt looks harmless. **How to verify:** Injected instructions in content returned to pilot users' agents are detected and attributed to their source. **OWASP adoption context:** Indirect injection enters through connected-agent workflows and retrieved content; the listed tiers do not imply identical detection coverage. **Mappings:** - NIST CSF 2.0: DE.AE-02, DE.CM-09; SOC 2: CC7.2; ISO 27001: A.8.16, A.5.25 — Evidence and source attribution for injection, jailbreak and bypass behavior support adverse-event analysis, security monitoring and event triage. Test connector responses, retrieved content and tool outputs even with benign user prompts; prompt injection is not automatically malware, and detection does not guarantee blocking or constitute malware prevention. ISO/IEC 27001: A.8.16: Demonstrate analysis of anomalous or risky behavior beyond usage collection. Validate surface coverage, known gaps and false positives, with an event-assessment and response process. - NIST AI RMF: MEASURE 3.1; ISO 42001: A.6.2.6 — Detection evidence, originating sources, tested coverage and known gaps support continuing identification of AI risks and operational monitoring. Findings must feed an ongoing tracking and review process; a detector alone does not establish that process. - OWASP ASI: ASI01, ASI06 — Direct and indirect malicious instructions can hijack agent goals under ASI01. ASI06 applies when content poisons retained or retrievable context; a malicious connector response is not automatically memory poisoning. Detection coverage must be demonstrated, and blocking is not guaranteed. ## VAL-002: Classify AI activity into business-relevant use cases - Area: AI Usage, Spend & Value - Verification: Proof of value - OWASP adoption tier: Tier-independent - URL: /r/VAL-002 **Acceptance criteria:** Turn raw telemetry into recognizable tasks, workflows and functions. **Why it matters:** Tool-level data cannot tell a team drafting contracts from one summarizing public research. **How to verify:** Top use cases by function from pilot data, with personal conversations excluded. **OWASP adoption context:** Business-use classification can describe activity from any adoption tier; a deployment pattern alone does not identify the business purpose. **Mappings:** - NIST AI RMF: MAP 1.1; ISO 42001: A.9.4 — Recognizable tasks and workflows provide context for documenting intended purposes and beneficial uses, and allow actual activity to be compared with intended use. Observed activity does not itself determine that purpose or demonstrate conformity with it. ## VAL-003: Measure spend, waste and portfolio decisions - Area: AI Usage, Spend & Value - Verification: Proof of value + Walkthrough - OWASP adoption tier: Tier-independent - URL: /r/VAL-003 **Acceptance criteria:** Report licenses, tokens, provider cost, model efficiency, redundant tools and cost per task or outcome, and produce the evidence behind a decision to scale, pause, optimize or retire a tool. **Why it matters:** License waste and duplicate tools are often the fastest way to fund the control. **How to verify:** Licensed versus active use for one enterprise AI tool, and the cost method explained. **OWASP adoption context:** Portfolio cost, overlap and retirement decisions can compare AI services across adoption tiers rather than treating a tier as a measure of value. **Mappings:** - NIST AI RMF: GOVERN 1.7 — Cost and outcome evidence can inform a decision to retire an AI tool. The relationship is an input to decommissioning decisions; financial optimization does not establish safe retirement or treatment of residual risks. - ISO 42001: A.4.5 — Token use and model efficiency provide resource-consumption information for identified in-scope AI services. Cost or ROI alone is insufficient, and these metrics establish neither capacity adequacy nor responsible-AI supplier alignment. ## VAL-004: Measure productivity and business-value signals - Area: AI Usage, Spend & Value - Verification: Proof of value - OWASP adoption tier: Tier-independent - URL: /r/VAL-004 **Acceptance criteria:** Identify time saved, throughput, completion and quality indicators with stated assumptions. **Why it matters:** Risk without value is a brake. Value without risk is a blind spot. **How to verify:** Value indicators for pilot functions, shown with their assumptions. **OWASP adoption context:** Productivity and value evidence can be assessed across adoption tiers; the workflow, baseline and assumptions determine meaningful comparisons. **Mappings:** - NIST AI RMF: MAP 3.1, MEASURE 4.3 — Time saved, throughput and quality indicators with stated assumptions inform benefit assessment and context-relevant AI performance evaluation against chosen responsible-use objectives. Their meaning and validity need evaluation; reporting business-value metrics alone establishes neither realized benefit nor security effectiveness. ## VAL-005: Generate targeted training and enablement recommendations - Area: AI Usage, Spend & Value - Verification: Proof of value - URL: /r/VAL-005 **Acceptance criteria:** Turn observed usage and detection telemetry into prioritized interventions, templates, coaching and sanctioned-tool adoption, aimed at the teams and behaviors that actually generate risk, and measure whether behavior changes. **Why it matters:** Training aimed at the teams and behaviors that actually create risk works better than blanket training. **How to verify:** Prioritized enablement recommendations from pilot data, and a measure of whether behavior changed. **OWASP adoption context:** Training recommendations should reflect observed needs across the listed employee AI contexts instead of assuming that adoption tier determines competence. **Mappings:** - NIST CSF 2.0: PR.AT-01, PR.AT-02; NIST AI RMF: GOVERN 2.2; ISO 42001: Cl. 7.2, Cl. 7.3; SOC 2: CC1.4, CC2.2, CC4.1 — Usage and detection telemetry can target AI/security training and coaching at relevant teams and roles, while behavior changes provide evaluation evidence. Recommendations do not establish delivered training or required competence; effectiveness measures must relate to the awareness or risk-control objective being evaluated. - ISO 27001: Cl. 9.1, Cl. 7.3, A.6.3 — Measured changes in risky behavior provide security-effectiveness evidence; targeted coaching can support awareness when it reaches employees. Define the relevant objective, baseline, responsibility, measurement cadence and evaluation. Recommendations alone are not delivered training and do not determine or assess required competence. ## VAL-006: Measure employee self-remediation - Area: AI Usage, Spend & Value - Verification: Proof of value - OWASP adoption tier: AT0–AT4 - URL: /r/VAL-006 **Acceptance criteria:** Record whether a warned user cancels, edits, redirects or proceeds, and calculate a remediation rate where privacy allows. **Why it matters:** Self-remediation shows whether coaching changes behavior or just records it. **How to verify:** Share of coached pilot interventions where the employee edits or cancels, and the trend over the pilot. **OWASP adoption context:** Shadow, embedded-assistant and integrated-platform interactions are primary contexts for observing whether employees cancel, edit or proceed after a warning. **Mappings:** - NIST CSF 2.0: ID.IM-01, PR.AT-01; ISO 42001: Cl. 7.3, Cl. 9.1 — Post-warning cancel, edit, redirect and proceed behavior provides evidence for evaluating AI/security awareness interventions and identifying improvements. A remediation rate does not prove competence, safe final content or an effective overall program; meaningful denominators and privacy-appropriate collection are needed. - NIST AI RMF: MEASURE 4.1 — Cancel, edit, redirect and proceed telemetry can inform context-sensitive evaluation of measurements. It complements rather than replaces consultation with end users and domain experts. - SOC 2: CC4.1 — Responses to a security warning and the remediation rate provide evidence for evaluating that intervention. Define the denominator and sampling window and use privacy-appropriate collection; a click or edit does not prove safe final content or an effective overall program. - ISO 27001: Cl. 9.1, A.6.3 — Responses to a security warning and a defined remediation rate evaluate a specific security intervention. The training link applies when the metric evaluates a delivered awareness intervention. Define the objective, denominator, sampling window, responsibility, cadence and evaluation; a click or edit does not prove safe content, competence or understanding of ISMS duties. ## VAL-007: Provide role-based dashboards and reporting, up to board level - Area: AI Usage, Spend & Value - Verification: Walkthrough - OWASP adoption tier: AT0–AT2 - Formerly: GOV-009 - URL: /r/VAL-007 **Acceptance criteria:** Tailor views for Security, IT, GRC, Legal, executives and business units, filter by unit, tool, environment, owner and risk, and summarize adoption, risk, policy, incidents and recommendations with trends and supporting evidence. **Why it matters:** Each audience, from SOC to board, needs its own view of the same data. **How to verify:** The same pilot data shown through executive, function and security views. **OWASP adoption context:** Role-based governance reporting can combine workforce AI evidence from any adoption tier while limiting the detail each audience receives. **Mappings:** - ISO 42001: Cl. 9.1, Cl. 9.3; SOC 2: CC2.1, CC2.2, CC4.1; ISO 27001: Cl. 9.1, Cl. 9.3.2 — Evidence-backed risk, policy and incident trends provide information for performance evaluation, oversight and management review. Responsible people must receive, review and act on it; a dashboard is not a completed review, and adoption metrics alone are not security-effectiveness evidence. - NIST AI RMF: GOVERN 2.1 — Role-tailored reporting helps communicate AI-risk information to people with governance responsibilities across teams. Providing views does not itself assign those responsibilities or establish accountability. - NIST CSF 2.0: GV.OV-03 — Evidence-backed risk, policy and incident trends provide inputs to cybersecurity performance oversight. Responsible people must review and use the reporting; a dashboard is not a completed review, and adoption alone is not security-effectiveness evidence. ## AUD-001: Keep a configurable record of each conversation - Area: Audit & Evidence - Verification: Walkthrough - OWASP adoption tier: Tier-independent - Formerly: GOV-014 - URL: /r/AUD-001 **Acceptance criteria:** Record the prompts, responses, uploaded files and tool calls that make up each conversation, with content capture set per policy: full, partial, metadata-only or none, in line with privacy and retention rules. **Why it matters:** The conversation, not the single prompt, is the unit an investigator or auditor needs to see. **How to verify:** Show one pilot conversation's record at full, partial and metadata-only capture settings. **OWASP adoption context:** Logging-depth choices apply across adoption tiers, balancing needed evidence against data minimization and any applicable retention rule. **Mappings:** - NIST CSF 2.0: PR.PS-04; ISO 42001: A.6.2.8; SOC 2: CC7.2, P3.1, P4.2 — Selectable prompt/response capture provides AI/security logging evidence while letting privacy and retention policy constrain content depth. The buyer must test that each chosen mode preserves needed event metadata; capture configuration alone establishes neither log integrity nor an adequate monitoring and retention process. SOC 2: P3.1/P4.2 require the Privacy category and relevant information in scope. - NIST AI RMF: MEASURE 2.8 — Choosing and documenting content depth can supply evidence for evaluating transparency and accountability alongside privacy trade-offs. A configuration option alone does not establish the evaluation or its adequacy. - ISO 27001: A.8.15, A.5.34 — Configurable prompt and response capture supports logging design and privacy minimization. Preserve needed event metadata, usable attribution and appropriate retention, protection and analysis even when content capture is disabled. Capture-depth options alone establish neither log integrity, record protection nor lawful monitoring. ## AUD-002: Export audit and forensic evidence - Area: Audit & Evidence - Verification: Walkthrough - OWASP adoption tier: Tier-independent - Formerly: GOV-002 - URL: /r/AUD-002 **Acceptance criteria:** API, CSV, webhook or evidence package suitable for audit and incident response use. **Why it matters:** Evidence has to leave the console in a form legal, HR and auditors can use. **How to verify:** Export an evidence package for one pilot incident. **OWASP adoption context:** Evidence export serves investigation and audit across adoption tiers; the relevant source and access restrictions still follow the records. **Mappings:** - NIST CSF 2.0: RS.AN-07; ISO 42001: A.6.2.8; SOC 2: CC2.1, CC7.3; ISO 27001: A.5.28 — Exportable AI-event and incident records provide usable information for incident analysis and evidence handling. Preserve source identifiers, times, provenance and integrity through export into the relevant evidence procedure. Format support alone establishes neither accuracy, completeness, chain of custody, recorded investigation actions nor an internal-audit program or incident decision. - NIST AI RMF: GOVERN 4.3 — Evidence packages make AI-event information available to people responsible for testing, incident identification and information sharing. An export facility is an input to those practices, rather than the complete practice. ## AUD-003: Restrict and audit access to raw prompt content - Area: Audit & Evidence - Verification: Walkthrough - OWASP adoption tier: Tier-independent - Formerly: GOV-005 - URL: /r/AUD-003 **Acceptance criteria:** Provide RBAC controls over who can read full prompt content, and record each access to it. **Why it matters:** Raw prompts are among the most sensitive data the control holds, so access must be limited and logged. **How to verify:** Only an authorized role can open full prompt content, and each access is recorded. **OWASP adoption context:** Raw prompt access needs protection across the listed employee AI settings, independently of whether the underlying application is sanctioned. **Mappings:** - NIST CSF 2.0: PR.AA-05, PR.DS-01; SOC 2: CC6.3, CC7.2; ISO 27001: A.8.3, A.8.15 — Role-scoped access restricts who can read raw prompts, helping protect stored content, while records of each read supply monitoring evidence. Restrictions must operate across relevant access paths; logged reads still require review and follow-up to detect misuse. ISO/IEC 27001: Enforce restrictions before access across the UI, exports, APIs, search and administrators. Retain, protect and analyze attributed access logs; logging access does not authorize it. - NIST AI RMF: MEASURE 2.10 — Restricted and recorded access to identifiable prompt content provides evidence of a treatment for privacy risk. The broader examination and documentation of privacy impacts remain necessary. ## PLT-001: Minimize endpoint and network architecture risk - Area: Platform, Privacy & Assurance - Verification: Documentation - OWASP adoption tier: AT0–AT4 - Formerly: ARC-006 - URL: /r/PLT-001 **Acceptance criteria:** Support agentless and optional-agent patterns, and avoid kernel mode, reverse proxy and major network changes unless justified and tested. **Why it matters:** Kernel components, proxies and network changes add operational risk that should be justified. **How to verify:** The vendor documents the deployment architecture and justifies any privileged component. **OWASP adoption context:** Endpoint and network design risks span the listed employee AI settings; broad coverage should not assume that one deployment architecture fits every surface. **Mappings:** - SOC 2: CC6.1, CC8.1; ISO 27001: A.8.27, A.8.29 — Justified, tested deployment choices provide secure-architecture, configuration and change/acceptance-review inputs and can reduce unnecessary privileged interception exposure. Agentless deployment is not intrinsically more secure, and these frameworks do not prohibit kernel components or reverse proxies. - NIST AI RMF: MAP 4.2 — Agent choices and justified network changes document AI component controls, computing resources and deployment requirements. Tests provide readiness evidence, but the configuration still needs assessment in the actual deployment environment. - ISO 42001: A.6.2.5 — Justified and tested deployment choices provide readiness evidence when assessed against a defined deployment plan and acceptance criteria. Avoiding kernel components or reverse proxies is not itself resource documentation or proof of safe deployment. - NIST CSF 2.0: PR.PS-01 — Justified, tested deployment choices can provide configuration-acceptance evidence when assessed against a security baseline. Agentless deployment is not inherently safer, and avoiding a technology class does not establish a network-access safeguard. ## 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-003: Deploy silently through endpoint management with release controls - Area: Platform, Privacy & Assurance - Verification: Proof of value - OWASP adoption tier: AT0–AT4 - Formerly: ARC-016 - URL: /r/PLT-003 **Acceptance criteria:** Deploy and update every component silently through the buyer's endpoint management tools on Windows, macOS and Linux and all major browsers, with release rings, version pinning, rollback and a central view of deployment health by device. **Why it matters:** Deployment is where enterprise controls most often fail. **How to verify:** Pilot devices are deployed silently through your endpoint management, with deployment health visible. **OWASP adoption context:** Endpoint components underpin coverage in every listed context, so deployment health determines real coverage. **Mappings:** - NIST CSF 2.0: PR.PS-02, ID.AM-08; SOC 2: CC8.1; ISO 27001: A.8.32, A.8.9 — Managed deployment with release rings, pinning and rollback brings the control's own software under change and configuration management. Deployment health still has to be monitored; an install that fails silently does not meet this requirement. - NIST AI RMF: MANAGE 2.4; ISO 42001: A.6.2.5 — Staged releases and rollback let the buyer contain a faulty update without losing protection everywhere. They are deployment safeguards, not evidence that each release is correct. ## PLT-005: Support network-based AI traffic detection where the architecture requires it - Area: Platform, Privacy & Assurance - Verification: Walkthrough + Documentation - OWASP adoption tier: AT0–AT2 - Formerly: ARC-001 - URL: /r/PLT-005 **Acceptance criteria:** Integrate with SASE or network controls, identify AI hosts and protocols, and state whether the implementation is passive or inline. **Why it matters:** Some architectures need network-level coverage, and the difference between passive and inline matters. **How to verify:** The vendor shows the network integration and states whether it is passive or inline. **OWASP adoption context:** Shadow, vendor-embedded and platform-integrated AI can create network-visible traffic; whether network inspection is appropriate depends on the architecture. **Mappings:** - SOC 2: CC7.2 — AI host and protocol identification adds network and external-service monitoring evidence and informs network-protection design. Passive versus inline coverage identifies the architecture; it does not prove enforced access restrictions, segmentation or secure network configuration. - NIST AI RMF: MAP 4.2 — Supported protocols, integration points and passive/inline boundaries help document controls for AI components and associated dependencies. The architecture description must be tied to actual deployed coverage. - ISO 42001: A.4.5 — Network coverage and deployment dependencies inform the computing-resource record for the AI system. An integration claim is not evidence that those resources are adequate or securely operated. - ISO 27001: A.8.16 — Observed AI hosts and protocols supply network-activity signals for security monitoring. Demonstrate traffic results and missed paths; passive visibility does not establish network enforcement, segmentation or secure configuration. - NIST CSF 2.0: DE.CM-01, DE.CM-06 — Observed AI hosts and protocols support network monitoring; observable external AI service traffic can also inform service-provider monitoring. Passive detection does not protect a network from unauthorized access, so show the traffic actually observed and the remaining gaps. ## PLT-006: Scale enforcement and telemetry to the full population - Area: Platform, Privacy & Assurance - Verification: Documentation + Proof of value - OWASP adoption tier: AT2, AT4, AT6 - Formerly: ARC-007 - URL: /r/PLT-006 **Acceptance criteria:** Demonstrate capacity, latency and availability, and dashboard, drill-down, search and export performance, at the target scale. **Why it matters:** A control proven at a few thousand users can behave like a different product at full scale. **How to verify:** The vendor provides a reference at your scale and demonstrates console performance on pilot data. **OWASP adoption context:** Population-scale capacity and availability matter across adoption tiers, with the actual workload and deployment determining the test conditions. **Mappings:** - NIST CSF 2.0: PR.IR-04; SOC 2: A1.1; ISO 27001: Cl. 9.1, A.8.6 — Recorded capacity, latency and availability at the target population provide resource-adequacy and security-control performance evidence, including availability planning where the SOC 2 Availability category and relevant information are in scope. A benchmark does not establish ongoing capacity monitoring or resilience under all loads; the user-count target is buyer-specific. ISO/IEC 27001: Define responsibility, frequency and evaluation for security-performance or control-effectiveness measures. Test sustained load and spare capacity; a demonstration does not establish ongoing monitoring or adjustment, and ISO prescribes no particular latency. - NIST AI RMF: MEASURE 2.3 — Recorded performance tests at deployment-like scale provide measurement evidence and clarify the conditions in which results apply. The buyer must judge whether those conditions represent production use. - ISO 42001: A.4.5 — Population-scale results inform computing-resource needs for enforcement and telemetry. The target user count is a buyer criterion, and a demonstration does not by itself establish continuing resource adequacy. ## 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. ## PLT-008: Separate administrative roles, and authenticate them through enterprise SSO - Area: Platform, Privacy & Assurance - Verification: Walkthrough - OWASP adoption tier: Tier-independent - Formerly: POL-002 - URL: /r/PLT-008 **Acceptance criteria:** Separate policy, approval, administration, investigation and exception duties; authenticate administrators through enterprise SSO; apply least-privilege roles over policy, alerts, raw prompts, exports and dashboards; and record administrative and investigative actions. **Why it matters:** Whoever can change policy or read prompts holds a lot of power, so roles must be separated and every action recorded. **How to verify:** Show separate policy, investigation and exception roles, SSO login and the record of an admin action. **OWASP adoption context:** Administrative role separation and enterprise authentication apply to governance of workforce AI regardless of the end-user adoption tier. **Mappings:** - NIST CSF 2.0: GV.RR-02, PR.AA-03, PR.AA-05; SOC 2: CC6.1, CC6.3; ISO 27001: A.5.3, A.8.2, A.8.3, A.8.5, A.8.15 — Separating administrative duties, authenticating administrators through enterprise SSO and restricting access to prompts, exports and policy functions implement authenticated, least-privilege administration. Recorded administrative and investigative actions provide an activity trail. The role assignments must actually prevent conflicting duties; SSO alone does not establish authentication strength. ISO/IEC 27001: A.5.3: Adopt the organizational process and validate this requirement against the buyer’s actual ISMS scope; product availability is not implementation. A.8.3: Apply restrictions before the operation. A.8.5: SSO must meet buyer-approved authentication requirements; its presence alone does not prove MFA or session strength. A.8.15: Logs need usable attribution and appropriate retention, protection and analysis; a live view alone is insufficient. - NIST AI RMF: GOVERN 2.1; ISO 42001: A.3.2, Cl. 5.3 — Distinct policy, approval, investigation and exception duties make AI-risk responsibilities and authorities concrete. The roles provide evidence for governance assignments and lines of responsibility; these references do not prescribe enterprise SSO or establish every organization-wide role and communication path. ## PLT-009: Control telemetry residency, retention, encryption, deletion and masking - Area: Platform, Privacy & Assurance - Verification: Documentation + Walkthrough - OWASP adoption tier: AT0, AT4 - Formerly: GOV-004 - URL: /r/PLT-009 **Acceptance criteria:** Validate region, retention period, encryption, deletion behavior, identity masking and exclusions with Legal and Privacy. **Why it matters:** Residency, retention and masking are the first questions privacy and legal teams ask. **How to verify:** The vendor documents region, retention, encryption, deletion and masking, and shows the settings. **OWASP adoption context:** Telemetry protection and retention choices apply across adoption tiers; actual data, deployment location and applicable obligations determine the settings. **Mappings:** - NIST CSF 2.0: PR.DS-01, PR.DS-02; SOC 2: CC6.1, CC6.7, C1.1, C1.2, P4.2, P4.3; ISO 27001: A.8.10, A.8.11, A.8.24, A.5.33, A.5.31, A.5.34 — Validation of telemetry encryption, masking, retention and deletion provides assurance inputs for data protection and applicable confidentiality/privacy objectives. Stored and transmitted data need separate consideration; validation alone does not demonstrate operating safeguards, and these frameworks do not prescribe a universal hosting region or retention period. SOC 2: C1.1/C1.2 require the Confidentiality category and relevant information in scope; P4.2/P4.3 require Privacy and relevant information in scope. ISO/IEC 27001: These settings do not establish cryptographic key governance. - NIST AI RMF: MEASURE 2.10 — Legal and Privacy review of masking, location, retention and deletion provides evidence for examination and documentation of AI privacy risk. It is one part of assessing that risk across the system lifecycle. - ISO 42001: A.4.3 — Telemetry location, retention and handling settings provide facts for documenting AI data resources. A.4.3 does not itself prescribe all the listed safeguards, a hosting region or a retention minimum. ## PLT-010: Offer required hosting regions - Area: Platform, Privacy & Assurance - Verification: Documentation - OWASP adoption tier: Tier-independent - Formerly: ARC-008 - URL: /r/PLT-010 **Acceptance criteria:** Document processing and storage locations, regional failover, subprocessor boundaries and tenant residency enforcement. **Why it matters:** Where data is processed and stored is often a contractual and legal requirement. **How to verify:** The vendor documents processing and storage locations, failover and subprocessor boundaries. **OWASP adoption context:** Hosting and subprocessor-location choices are cross-tier deployment concerns; adoption tier does not create a universal residency obligation. **Mappings:** - NIST CSF 2.0: GV.SC-07; NIST AI RMF: MAP 4.1; SOC 2: CC9.2 — Documented processing locations, regional failover and subprocessor boundaries supply evidence for assessing third-party dependencies and associated supplier and legal risks. Location records do not verify residency enforcement or resolve those risks; US/EU hosting is not a universal requirement. - ISO 42001: A.4.5, A.10.3 — Hosting, failover and subprocessor details inform computing-resource documentation and supplier responsibilities. Region availability alone does not establish suitable supplier terms or operating residency controls. - ISO 27001: A.5.23, A.5.31, A.5.34 — Documented locations and residency-enforcement arrangements support the buyer’s cloud-use governance and applicable data-location/privacy obligations. Documentation alone does not demonstrate residency enforcement. US/EU hosting is not universally required by ISO and does not prove lawful transfer, suitable subprocessor agreements or failover arrangements. ## PLT-012: Support pseudonymized and aggregate-only views where required - Area: Platform, Privacy & Assurance - Verification: Walkthrough - OWASP adoption tier: Tier-independent - Formerly: GOV-013 - URL: /r/PLT-012 **Acceptance criteria:** Provide role-scoped views that withhold individual identity while preserving team, department and tool-level analysis, so monitoring can proceed where works councils, unions or local law restrict individual attribution. **Why it matters:** Where works councils or local law restrict individual attribution, monitoring still has to be possible. **How to verify:** Pilot data viewed at team level with individual identity withheld. **OWASP adoption context:** Privacy-appropriate reporting views can be needed across the listed employee AI contexts; the tier itself does not determine whether individual attribution is permissible. **Mappings:** - NIST CSF 2.0: GV.OC-02, PR.AA-05; SOC 2: CC6.3, P4.1; ISO 27001: A.8.11, A.8.3, A.5.34 — Role-scoped views that withhold identity implement access restriction and masking while enabling team-level monitoring aligned with relevant stakeholder and privacy requirements. Pseudonymization or aggregation does not guarantee anonymity; the buyer must establish the permitted use and validate re-identification and alternate-access risks. SOC 2: P4.1 requires the Privacy category and relevant information in scope. ISO/IEC 27001: Operate masking within the buyer’s ISMS scope and enforce restrictions before access; monitoring or warnings alone are insufficient. Check local law and workforce-consultation duties separately. - NIST AI RMF: GOVERN 1.1, MEASURE 2.10 — Withholding identity supplies a concrete privacy-risk treatment and evidence for evaluating impacts on individuals and relevant AI obligations. It does not replace the privacy/individual-impact assessment or determine which workforce-monitoring obligations apply. ## PLT-013: Limit monitoring scope by design - Area: Platform, Privacy & Assurance - Verification: Walkthrough + Documentation - OWASP adoption tier: Tier-independent - Formerly: GOV-016 - URL: /r/PLT-013 **Acceptance criteria:** Monitor AI destinations and agent activity only, not general browsing. Minimize captured content and allow full capture to be switched off, ring-fence named individuals such as executives, exclude personal conversations from analytics, and document the configuration for privacy, legal and workforce review. **Why it matters:** Works councils and privacy teams judge the architecture, not the policy document. **How to verify:** Show that non-AI browsing is not captured, a ring-fenced user is excluded, and the configuration is documented. **OWASP adoption context:** Monitoring reaches employees in every listed context, so scope limits should be enforced on each surface, not only in the browser. **Mappings:** - NIST CSF 2.0: GV.OC-03, PR.DS-10; SOC 2: P3.1, P4.1; ISO 27001: A.5.34 — Limiting collection to AI activity, minimizing content and ring-fencing sensitive individuals protects personal information within the monitoring itself. A documented configuration supports review; it does not settle whether the monitoring is lawful. SOC 2: P3.1, P4.1 require the Privacy category and relevant information in scope. - NIST AI RMF: MEASURE 2.10; ISO 42001: A.5.4 — Privacy-limited monitoring is a concrete treatment for the privacy risk the control itself creates for employees. It does not replace an impact assessment of the monitoring. ## PLT-014: Maintain security assurance - Area: Platform, Privacy & Assurance - Verification: Documentation - OWASP adoption tier: Tier-independent - Formerly: ARC-009 - URL: /r/PLT-014 **Acceptance criteria:** Current evidence for SOC 2 Type II and ISO 27001. **Why it matters:** Standard assurance should be evidenced, not assumed. **How to verify:** Current SOC 2 Type II report, ISO 27001 certificate and privacy terms are provided. **OWASP adoption context:** Supplier assurance supports procurement and oversight across adoption tiers, with the buyer’s own scope and use determining the relevant evidence. **Mappings:** - NIST CSF 2.0: GV.SC-06, GV.SC-07; NIST AI RMF: GOVERN 6.1, MANAGE 3.1; ISO 42001: A.10.3; SOC 2: CC9.2; ISO 27001: A.5.19, A.5.22 — Current vendor reports and certificates provide inputs to pre-contract due diligence, supplier governance and continuing risk assessment. The buyer must evaluate service scope, reporting period, certificate expiry, findings, exclusions and its own responsibilities; vendor assurance neither certifies the buyer nor satisfies its controls.