{"source":"Harmonic Security","updated":"2026-10-21","updatedLabel":"October 2026","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.","count":69,"requirements":[{"id":"SPM-001","section":"AI Security Posture Management","requirement":"Classify previously unseen AI applications on first encounter","acceptance":"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.","tier":"AT0–AT4","whyItMatters":"Waiting for a catalog update leaves every new tool ungoverned during the period it is most likely to be tried.","verificationMethod":"LT","verificationTest":"An AI tool the vendor has not seen before is classified and risk-scored on first use, with the evidence shown.","formerly":"DIS-014","alsoIn":[],"sort":0,"adoptionContext":"Shadow AI is the primary first-encounter discovery scenario; an unfamiliar application should not require a prior catalog entry to become visible.","mappings":[{"frameworks":["csf","iso27001"],"explanation":"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.","kind":"framework","references":{"csf":["ID.AM-02","ID.RA-05"],"iso27001":["Cl. 6.1.2","A.5.9"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MAP 4.1"]},"relation":null,"conditions":[]},{"frameworks":["soc2"],"explanation":"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.","kind":"framework","references":{"soc2":["CC3.2","CC9.2"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.4.2"]},"relation":null,"conditions":[]}],"area":"AI Security Posture Management","areaSlug":"SPM","url":"/r/SPM-001","frameworkRefs":{"ISO27001":["Cl. 6.1.2","A.5.9"],"ISO42001":["A.4.2"],"NIST-CSF":["ID.AM-02","ID.RA-05"],"NIST-AI-RMF":["MAP 4.1"],"SOC2":["CC3.2","CC9.2"]}},{"id":"SPM-002","section":"AI Security Posture Management","requirement":"Detect AI use at the browser point of use","acceptance":"Show visibility in Chrome, Edge, Safari and Firefox where supported, including prompt context and account plan.","tier":"AT0","whyItMatters":"The browser is where most employee AI use happens, so it is the first place visibility has to work.","verificationMethod":"LT","verificationTest":"Pilot users' AI use in each supported browser appears with prompt context and account plan.","formerly":"DIS-002","alsoIn":[],"sort":1,"adoptionContext":"The listed contexts focus on browser access to personal-account AI and vendor assistants; the supported browser and capture path still determine visibility.","mappings":[{"frameworks":["csf","iso"],"explanation":"Browser prompt and account-plan telemetry makes personnel use and AI runtime activity visible for operational monitoring. Coverage is limited to supported browsers, and visibility alone does not establish adverse-event analysis.","kind":"framework","references":{"csf":["DE.CM-03","DE.CM-09"],"iso":["A.6.2.6"]},"relation":null,"conditions":[]},{"frameworks":["soc2"],"explanation":"Point-of-use browser telemetry provides evidence for anomaly monitoring; the acceptance test does not require anomaly analysis or incident evaluation.","kind":"framework","references":{"soc2":["CC7.2"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"Browser-use observations, including the prompt and account fields actually captured, provide application-activity signals for security monitoring. Demonstrate browser coverage, telemetry completeness and delivery to security analysis; visibility alone does not detect anomalies or prevent disclosure.","kind":"framework","references":{"iso27001":["A.8.16"]},"relation":null,"conditions":[]}],"area":"AI Security Posture Management","areaSlug":"SPM","url":"/r/SPM-002","frameworkRefs":{"ISO27001":["A.8.16"],"ISO42001":["A.6.2.6"],"NIST-CSF":["DE.CM-03","DE.CM-09"],"SOC2":["CC7.2"]}},{"id":"SPM-003","section":"AI Security Posture Management","requirement":"Detect endpoint AI activity beyond the browser","acceptance":"Identify desktop clients, IDEs, coding assistants, CLI tools and local agents on managed Windows and macOS endpoints.","tier":"AT0, AT1","whyItMatters":"Desktop apps, IDEs and CLI tools carry a growing share of AI use, and browser-only controls never see them.","verificationMethod":"LT","verificationTest":"Desktop assistants, coding tools and CLI tools used by pilot users appear, attributed to user, device and application.","formerly":"DIS-003","alsoIn":[],"sort":2,"adoptionContext":"Endpoint inspection complements browser visibility for shadow applications and code-executing agent activity on employee devices.","mappings":[{"frameworks":["csf","iso27001"],"explanation":"Finding desktop, IDE, CLI and local-agent activity fills software-discovery and monitoring gaps beyond browsers. These observations must feed maintained, owned inventory records and analysis; identification alone establishes neither.","kind":"framework","references":{"csf":["ID.AM-02","DE.CM-03","DE.CM-09"],"iso27001":["A.5.9","A.8.16"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"Visibility into AI clients and processes on managed endpoints contributes to in-life operation monitoring, subject to demonstrated Windows and macOS coverage.","kind":"framework","references":{"iso":["A.6.2.6"]},"relation":null,"conditions":[]},{"frameworks":["soc2"],"explanation":"Endpoint findings supply control information and monitoring inputs for otherwise hidden AI use. Client identification alone does not demonstrate suspicious-activity analysis.","kind":"framework","references":{"soc2":["CC2.1","CC7.2"]},"relation":null,"conditions":[]}],"area":"AI Security Posture Management","areaSlug":"SPM","url":"/r/SPM-003","frameworkRefs":{"ISO27001":["A.5.9","A.8.16"],"ISO42001":["A.6.2.6"],"NIST-CSF":["ID.AM-02","DE.CM-03","DE.CM-09"],"SOC2":["CC2.1","CC7.2"]}},{"id":"SPM-004","section":"AI Security Posture Management","requirement":"Detect direct model-provider API calls from employee devices","acceptance":"Attribute provider, process, device, user and destination for direct API use with no browser involved.","tier":"AT0, AT4","whyItMatters":"Scripts and tools that call model APIs directly bypass every browser control and often carry the most sensitive information.","verificationMethod":"LT","verificationTest":"A direct API call from a pilot device is attributed to provider, process, user and destination.","formerly":"DIS-004","alsoIn":[],"sort":3,"adoptionContext":"Direct API use can bypass a managed browser in shadow-AI and code-agent workflows, making the device-to-provider path the relevant discovery surface.","mappings":[{"frameworks":["csf","iso27001"],"explanation":"Provider, process, device, user and destination attribution reveals direct API activity for monitoring and supplier-service inventory records. Connection observations need to be incorporated into maintained records and analyzed for risk. A connection record is not supplier assessment or network enforcement; unsupported encrypted and offline paths remain gaps.","kind":"framework","references":{"csf":["ID.AM-04","DE.CM-01","DE.CM-06"],"iso27001":["A.8.16","A.5.9"]},"relation":null,"conditions":[]},{"frameworks":["soc2"],"explanation":"Actor and destination attribution makes non-browser API use available to anomaly monitoring. A separate detection and review process must determine whether the activity is suspicious.","kind":"framework","references":{"soc2":["CC7.2"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"Provider, process, device and destination attribution helps identify the AI resources in use. These observations are inputs to resource documentation, rather than a complete resource record or supplier assessment.","kind":"framework","references":{"iso":["A.4.2"]},"relation":null,"conditions":[]}],"area":"AI Security Posture Management","areaSlug":"SPM","url":"/r/SPM-004","frameworkRefs":{"ISO27001":["A.8.16","A.5.9"],"ISO42001":["A.4.2"],"NIST-CSF":["ID.AM-04","DE.CM-01","DE.CM-06"],"SOC2":["CC7.2"]}},{"id":"SPM-005","section":"AI Security Posture Management","requirement":"Discover local model runtimes and offline AI installations","acceptance":"Identify installation and running process for tools such as Ollama or LM Studio.","tier":"AT0, AT4","whyItMatters":"Local models move data off the monitored path entirely.","verificationMethod":"LT","verificationTest":"A local runtime installed on a pilot device is discovered and cataloged.","formerly":"DIS-005","alsoIn":[],"sort":4,"adoptionContext":"Local runtimes are relevant to shadow use and code-agent workflows even when no traffic reaches a hosted model provider.","mappings":[{"frameworks":["csf","iso27001"],"explanation":"Installed-versus-running local-runtime evidence supplies software-inventory and activity-monitoring inputs, including offline AI. Discovery alone neither maintains the inventory nor detects anomalies or controls installation. Finding a runtime does not establish prompt inspection.","kind":"framework","references":{"csf":["ID.AM-02","DE.CM-09"],"iso27001":["A.5.9","A.8.16"]},"relation":null,"conditions":[]},{"frameworks":["soc2"],"explanation":"Local-runtime discovery supplies control information about hidden software and access exposure. It does not itself restrict installation or access.","kind":"framework","references":{"soc2":["CC2.1","CC6.1"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"Identifying installed and running local model runtimes documents part of the AI tooling landscape. It does not establish computing capacity, resource adequacy or prompt-inspection coverage.","kind":"framework","references":{"iso":["A.4.4"]},"relation":null,"conditions":[]}],"area":"AI Security Posture Management","areaSlug":"SPM","url":"/r/SPM-005","frameworkRefs":{"ISO27001":["A.5.9","A.8.16"],"ISO42001":["A.4.4"],"NIST-CSF":["ID.AM-02","DE.CM-09"],"SOC2":["CC2.1","CC6.1"]}},{"id":"SPM-006","section":"AI Security Posture Management","requirement":"Discover AI embedded in sanctioned SaaS","acceptance":"Identify AI features inside existing SaaS tools, such as Google AI Mode.","tier":"AT0, AT4","whyItMatters":"AI features switched on inside approved SaaS create new data flows without a new application to approve.","verificationMethod":"LT","verificationTest":"A common SaaS application is identified and cataloged as an AI tool due to its embedded AI features.","formerly":"DIS-010","alsoIn":[],"sort":5,"adoptionContext":"Vendor-embedded and platform-integrated AI can be present inside already approved SaaS, so discovering the host application alone is insufficient.","mappings":[{"frameworks":["csf","iso27001"],"explanation":"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.","kind":"framework","references":{"csf":["ID.AM-02","ID.AM-04"],"iso27001":["A.5.9","A.5.22"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MAP 4.1"]},"relation":null,"conditions":[]},{"frameworks":["soc2"],"explanation":"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.","kind":"framework","references":{"soc2":["CC2.1","CC9.2"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.4.2"]},"relation":null,"conditions":[]}],"area":"AI Security Posture Management","areaSlug":"SPM","url":"/r/SPM-006","frameworkRefs":{"ISO27001":["A.5.9","A.5.22"],"ISO42001":["A.4.2"],"NIST-CSF":["ID.AM-02","ID.AM-04"],"NIST-AI-RMF":["MAP 4.1"],"SOC2":["CC2.1","CC9.2"]}},{"id":"SPM-007","section":"AI Security Posture Management","requirement":"Provide visibility for unmanaged endpoints","acceptance":"Use approved SaaS/API methods where no endpoint agent can be installed.","tier":"AT1, AT2","whyItMatters":"Contractors and personal devices still reach corporate AI tenants, and some will never run an agent.","verificationMethod":"W + D","verificationTest":"The vendor shows and documents the coverage method for an unmanaged device in your environment.","formerly":"DIS-012","alsoIn":[],"sort":6,"adoptionContext":"Shadow, vendor-embedded and platform-integrated use may occur without a managed endpoint; network or service-side visibility depends on the available architecture.","mappings":[{"frameworks":["csf"],"explanation":"Approved network, remote-MCP and SaaS/API observations provide network or service-monitoring inputs where an endpoint agent cannot run. They do not establish equivalent visibility into all device activity.","kind":"framework","references":{"csf":["DE.CM-01","DE.CM-06"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"Alternative collection methods contribute to the AI operation-monitoring arrangement for unmanaged endpoints. Its scope, gaps and operating process still need to be defined.","kind":"framework","references":{"iso":["A.6.2.6"]},"relation":null,"conditions":[]},{"frameworks":["soc2","iso27001"],"explanation":"Off-endpoint telemetry supplies otherwise missing evidence for security monitoring within the buyer’s boundary. Validate coverage gaps, analysis and review rather than assuming equivalent visibility. These methods do not harden the endpoint.","kind":"framework","references":{"soc2":["CC7.2"],"iso27001":["A.8.16"]},"relation":null,"conditions":[]}],"area":"AI Security Posture Management","areaSlug":"SPM","url":"/r/SPM-007","frameworkRefs":{"ISO27001":["A.8.16"],"ISO42001":["A.6.2.6"],"NIST-CSF":["DE.CM-01","DE.CM-06"],"SOC2":["CC7.2"]}},{"id":"SPM-008","section":"AI Security Posture Management","requirement":"Distinguish personal, free and guest accounts from sanctioned enterprise tenants","acceptance":"Report a reliable account-type split at the point of use and allow policy to vary depending on account plan.","tier":"AT0, AT1","whyItMatters":"Contractual protections attach to the enterprise tenant, not the domain. A personal account reaches the same URL with none of them.","verificationMethod":"LT","verificationTest":"Enterprise, personal and unauthenticated use of the same tool are each identified and handled per policy.","formerly":"DIS-006","alsoIn":["value"],"sort":7,"adoptionContext":"Personal-account and vendor-assistant contexts make account ownership and plan distinctions important; tier alone does not establish contractual safeguards.","mappings":[{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MAP 4.1"]},"relation":null,"conditions":[]},{"frameworks":["soc2","iso27001"],"explanation":"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.\nISO/IEC 27001: Account identification does not manage the identity lifecycle.","kind":"framework","references":{"soc2":["CC6.7","CC9.2"],"iso27001":["A.8.3","A.5.23"]},"relation":null,"conditions":[]},{"frameworks":["csf"],"explanation":"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.","kind":"framework","references":{"csf":["DE.CM-03"]},"relation":null,"conditions":[]}],"area":"AI Security Posture Management","areaSlug":"SPM","url":"/r/SPM-008","frameworkRefs":{"ISO27001":["A.8.3","A.5.23"],"NIST-CSF":["DE.CM-03"],"NIST-AI-RMF":["MAP 4.1"],"SOC2":["CC6.7","CC9.2"]}},{"id":"SPM-009","section":"AI Security Posture Management","requirement":"Risk-score AI tools, connectors and agent workflows","acceptance":"Configurable factors such as vendor location, training on inputs, trust-center availability, account tier, autonomy, data sensitivity and tool power.","tier":"AT0–AT2","whyItMatters":"The risk in an AI tool usually sits in its data-handling terms, which change without the domain changing.","verificationMethod":"W","verificationTest":"Risk scores, with sources and factors, for five tools.","formerly":"DIS-009","alsoIn":[],"sort":8,"adoptionContext":"Risk scoring spans ordinary employee AI and MCP-extended workflows because sensitivity, autonomy and tool power vary independently of approval status.","mappings":[{"frameworks":["csf"],"explanation":"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.","kind":"framework","references":{"csf":["GV.RM-06","ID.RA-05"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MAP 5.1"]},"relation":null,"conditions":[]},{"frameworks":["owasp"],"explanation":"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.","kind":"framework","references":{"owasp":["ASI04"]},"relation":null,"conditions":[]},{"frameworks":["soc2"],"explanation":"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.","kind":"framework","references":{"soc2":["CC3.2","CC9.2"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["Cl. 6.1.2","A.5.19"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["Cl. 6.1.2","Cl. 8.2","A.10.3"]},"relation":null,"conditions":[]}],"area":"AI Security Posture Management","areaSlug":"SPM","url":"/r/SPM-009","frameworkRefs":{"ISO27001":["Cl. 6.1.2","A.5.19"],"ISO42001":["Cl. 6.1.2","Cl. 8.2","A.10.3"],"NIST-CSF":["GV.RM-06","ID.RA-05"],"NIST-AI-RMF":["MAP 5.1"],"SOC2":["CC3.2","CC9.2"],"OWASP-ASI":["ASI04"]}},{"id":"SPM-010","section":"AI Security Posture Management","requirement":"Define default treatment for newly discovered AI services","acceptance":"Apply a documented default rule until the service is assessed as sanctioned, restricted or prohibited.","tier":"AT0, AT1","whyItMatters":"New tools arrive faster than they can be assessed, so the default decides what happens in the meantime.","verificationMethod":"LT","verificationTest":"A tool first used during the pilot receives the documented default treatment.","formerly":"POL-004","alsoIn":[],"sort":9,"adoptionContext":"Default treatment matters wherever employees can encounter a new AI service in the listed settings, before a full approval decision is available.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nISO/IEC 27001: The chosen default must be approved and fit the organization’s risk treatment.","kind":"framework","references":{"csf":["GV.PO-01"],"soc2":["CC5.3","CC6.7"],"iso27001":["Cl. 8.1","A.5.10","A.8.3"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MANAGE 1.1"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.9.2"]},"relation":null,"conditions":[]}],"area":"AI Security Posture Management","areaSlug":"SPM","url":"/r/SPM-010","frameworkRefs":{"ISO27001":["Cl. 8.1","A.5.10","A.8.3"],"ISO42001":["A.9.2"],"NIST-CSF":["GV.PO-01"],"NIST-AI-RMF":["MANAGE 1.1"],"SOC2":["CC5.3","CC6.7"]}},{"id":"SPM-011","section":"AI Security Posture Management","requirement":"Support the AI tool approval and review lifecycle","acceptance":"Define and track unapproved versus approved AI tools and MCP servers.","tier":"AT0–AT4, AT6","whyItMatters":"Without a governed approval path, teams route around the control.","verificationMethod":"W","verificationTest":"Walk a tool or MCP server request from intake to a recorded decision.","formerly":"GOV-008","alsoIn":["audit"],"sort":10,"adoptionContext":"Managed assistants, platforms and connected-agent workflows need approval status and periodic review; status should be visible throughout the tool lifecycle.","mappings":[{"frameworks":["rmf","soc2"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 6.1","MANAGE 3.1"],"soc2":["CC9.2","CC5.3"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["A.5.9","A.5.23"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.4.2"]},"relation":null,"conditions":[]},{"frameworks":["csf"],"explanation":"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.","kind":"framework","references":{"csf":["ID.AM-02"]},"relation":null,"conditions":[]}],"area":"AI Security Posture Management","areaSlug":"SPM","url":"/r/SPM-011","frameworkRefs":{"ISO27001":["A.5.9","A.5.23"],"ISO42001":["A.4.2"],"NIST-CSF":["ID.AM-02"],"NIST-AI-RMF":["GOVERN 6.1","MANAGE 3.1"],"SOC2":["CC9.2","CC5.3"]}},{"id":"GRD-001","section":"Runtime Guardrails","requirement":"Inspect prompt content in real time before submission","acceptance":"Classify typed or pasted content at submit time and reach a policy decision before content leaves for the provider.","tier":"AT0–AT4","whyItMatters":"A decision made after submission only tells you what was lost. Inspection before submission is what prevents the loss.","verificationMethod":"LT","verificationTest":"Sensitive pilot prompts receive a policy decision before they reach the provider; record the decision time.","formerly":"DAT-001","alsoIn":[],"sort":11,"adoptionContext":"Prompt inspection applies across the listed employee interaction contexts, including personal accounts and agent-assisted work, wherever the submission path is observable.","mappings":[{"frameworks":["csf"],"explanation":"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.","kind":"framework","references":{"csf":["PR.DS-02","PR.DS-10"]},"relation":null,"conditions":[]},{"frameworks":["soc2","iso27001"],"explanation":"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.\nISO/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.","kind":"framework","references":{"soc2":["CC6.7"],"iso27001":["A.8.12","A.5.14"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MANAGE 1.3"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.9.2"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-001","frameworkRefs":{"ISO27001":["A.8.12","A.5.14"],"ISO42001":["A.9.2"],"NIST-CSF":["PR.DS-02","PR.DS-10"],"NIST-AI-RMF":["MANAGE 1.3"],"SOC2":["CC6.7"]}},{"id":"GRD-002","section":"Runtime Guardrails","requirement":"Inspect file uploads before submission","acceptance":"Apply eligible detection models to uploaded files, summarize the alert, and document coverage differences between files and typed text.","tier":"AT0–AT3","whyItMatters":"Files carry far more data than typed prompts, and many tools treat uploads as a separate, weaker path.","verificationMethod":"LT","verificationTest":"Sensitive DOCX, PDF, XLSX and CSV uploads are inspected before submission; coverage differences are documented.","formerly":"DAT-005","alsoIn":[],"sort":12,"adoptionContext":"The listed shadow, assistant, platform and citizen-workflow contexts cover common upload paths; file-inspection support must be demonstrated for each eligible surface.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nISO/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.","kind":"framework","references":{"csf":["PR.DS-02"],"soc2":["CC6.7"],"iso27001":["A.8.12"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MANAGE 1.3"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.9.2"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-002","frameworkRefs":{"ISO27001":["A.8.12"],"ISO42001":["A.9.2"],"NIST-CSF":["PR.DS-02"],"NIST-AI-RMF":["MANAGE 1.3"],"SOC2":["CC6.7"]}},{"id":"GRD-003","section":"Runtime Guardrails","requirement":"Classify sensitive information semantically in ordinary business language","acceptance":"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.","tier":"AT0–AT4","whyItMatters":"Most valuable business information has no fixed format. Pattern matching misses it, and rewording defeats it.","verificationMethod":"LT","verificationTest":"Unstructured sensitive text, including translated and reworded versions, is detected on default configuration.","formerly":"DAT-002","alsoIn":[],"sort":13,"adoptionContext":"Semantic classification follows the business content across the listed employee AI contexts rather than relying on a particular application or account type.","mappings":[{"frameworks":["csf"],"explanation":"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.","kind":"framework","references":{"csf":["PR.DS-02","PR.DS-10"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.10"]},"relation":null,"conditions":[]},{"frameworks":["soc2","iso27001"],"explanation":"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.\nSOC 2: C1.1: The Confidentiality category and relevant information must be in scope.\nISO/IEC 27001: A.8.12: Use an operated leakage-protection workflow with defined alert triage, warnings, blocking or another protective response.","kind":"framework","references":{"soc2":["CC6.7","C1.1"],"iso27001":["A.8.12","A.5.12"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-003","frameworkRefs":{"ISO27001":["A.8.12","A.5.12"],"NIST-CSF":["PR.DS-02","PR.DS-10"],"NIST-AI-RMF":["MEASURE 2.10"],"SOC2":["CC6.7","C1.1"]}},{"id":"GRD-004","section":"Runtime Guardrails","requirement":"Detect and coach in the languages your workforce uses","acceptance":"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.","tier":"AT1–AT4","whyItMatters":"A control that only reads English leaves much of the workforce unprotected.","verificationMethod":"LT","verificationTest":"Sensitive information is detected in all the languages required for your workforce.","formerly":"DAT-019","alsoIn":[],"sort":14,"adoptionContext":"Employees write prompts in their working language across every listed context, so detection quality should be measured for each language in use.","mappings":[{"frameworks":["csf","iso27001"],"explanation":"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.","kind":"framework","references":{"csf":["PR.DS-10"],"iso27001":["A.8.12"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso","soc2"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.3","MEASURE 2.5"],"iso":["A.6.2.4"],"soc2":["CC4.1"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-004","frameworkRefs":{"ISO27001":["A.8.12"],"ISO42001":["A.6.2.4"],"NIST-CSF":["PR.DS-10"],"NIST-AI-RMF":["MEASURE 2.3","MEASURE 2.5"],"SOC2":["CC4.1"]}},{"id":"GRD-005","section":"Runtime Guardrails","requirement":"Detect general, customer, employee and bulk PII","acceptance":"Correctly classify realistic personal, customer, employee and multi-person records inside contextual prompts.","tier":"AT0–AT4","whyItMatters":"Personal data is the most regulated thing employees paste into AI, often as whole records rather than single fields.","verificationMethod":"LT","verificationTest":"Realistic customer, employee and multi-person records in pilot prompts are detected on default configuration.","formerly":"DAT-009","alsoIn":[],"sort":15,"adoptionContext":"Personal data can be submitted through any listed employee AI context; the tier does not determine whether the content is sensitive.","mappings":[{"frameworks":["csf"],"explanation":"Contextual recognition of individual and bulk personal records supplies a detection input for protecting data in transit. Classification alone does not prevent release.","kind":"framework","references":{"csf":["PR.DS-02"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"Personal-data findings make relevant privacy exposure visible for examination and documentation. Recognizing PII does not complete the AI system’s privacy-risk assessment.","kind":"framework","references":{"rmf":["MEASURE 2.10"]},"relation":null,"conditions":[]},{"frameworks":["soc2"],"explanation":"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.","kind":"framework","references":{"soc2":["CC6.7","C1.1"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["A.8.12","A.5.34"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-005","frameworkRefs":{"ISO27001":["A.8.12","A.5.34"],"NIST-CSF":["PR.DS-02"],"NIST-AI-RMF":["MEASURE 2.10"],"SOC2":["CC6.7","C1.1"]}},{"id":"GRD-006","section":"Runtime Guardrails","requirement":"Detect sensitive health and workforce information","acceptance":"Recognize sensitive patient, clinical-research and employee information in context, including when users summarize or rewrite it. Document supported prompts and file types.","tier":"AT0–AT4","whyItMatters":"Sensitive records can appear in everyday prose, not just structured forms or obvious identifiers.","verificationMethod":"LT","verificationTest":"Test synthetic health and workforce examples in prompts and supported files, including summarization requests. Compare results with nonsensitive reference text.","formerly":"DAT-010","alsoIn":[],"sort":16,"adoptionContext":"Employee records can flow through shadow use, assistants, integrated platforms and citizen workflows, making those the primary workforce-data test contexts.","mappings":[{"frameworks":["csf"],"explanation":"Recognizing named employee medical, accommodation, compensation and performance details supplies a detection input for in-transit protection. Detection alone does not restrict disclosure.","kind":"framework","references":{"csf":["PR.DS-02"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.10"]},"relation":null,"conditions":[]},{"frameworks":["soc2"],"explanation":"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.","kind":"framework","references":{"soc2":["CC6.7","C1.1"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["A.8.12","A.5.34"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-006","frameworkRefs":{"ISO27001":["A.8.12","A.5.34"],"NIST-CSF":["PR.DS-02"],"NIST-AI-RMF":["MEASURE 2.10"],"SOC2":["CC6.7","C1.1"]}},{"id":"GRD-007","section":"Runtime Guardrails","requirement":"Detect confidential commercial information","acceptance":"Cover pipeline, pricing, contracts, supplier terms, financial projections, M&A and investment data.","tier":"AT0–AT3","whyItMatters":"Pricing, contracts and deal information are often a company's most valuable data and rarely follow a pattern.","verificationMethod":"LT","verificationTest":"Commercial information in unstructured pilot prompts is detected on default configuration.","formerly":"DAT-011","alsoIn":[],"sort":17,"adoptionContext":"Commercially confidential information can appear across the listed employee AI settings; its sensitivity depends on the content and business context, not the tier.","mappings":[{"frameworks":["soc2","iso27001"],"explanation":"Recognition of designated confidential commercial information supports its identification, sensitivity classification and leakage rules. The buyer’s classification policy and enforcement action are still required.\nSOC 2: C1.1: The Confidentiality category and relevant information must be in scope.\nISO/IEC 27001: A.8.12: Use an operated leakage-protection workflow with defined alert triage, warnings, blocking or another protective response. Recognizing M&A or financial content does not classify every record.","kind":"framework","references":{"soc2":["C1.1","CC6.7"],"iso27001":["A.8.12","A.5.12"]},"relation":null,"conditions":[]},{"frameworks":["csf"],"explanation":"Recognizing confidential commercial content supplies a specific input to data-in-transit protection. Use findings in an operated leakage-protection workflow; classification alone neither prevents release nor maintains an inventory.","kind":"framework","references":{"csf":["PR.DS-02"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-007","frameworkRefs":{"ISO27001":["A.8.12","A.5.12"],"NIST-CSF":["PR.DS-02"],"SOC2":["C1.1","CC6.7"]}},{"id":"GRD-008","section":"Runtime Guardrails","requirement":"Detect secrets, technical configuration and security-operations detail","acceptance":"Detect standard and homegrown keys, API tokens, credentials, connection strings, internal hostnames, network ranges and infrastructure config, plus narrative incident reports and customer authentication or session detail.","tier":"AT0–AT4","whyItMatters":"One leaked credential or network detail can turn an AI prompt into a breach.","verificationMethod":"LT","verificationTest":"Standard and homegrown secrets, hostnames and incident details are detected in pilot prompts.","formerly":"DAT-012","alsoIn":[],"sort":18,"adoptionContext":"Secrets and configuration details can enter prompts across the listed employee AI settings, including technical and code-agent work.","mappings":[{"frameworks":["csf"],"explanation":"Detection of credentials, configuration and security narratives provides runtime/data-monitoring evidence and inputs to in-transit protection. A finding alone does not stop disclosure.","kind":"framework","references":{"csf":["PR.DS-02","DE.CM-09"]},"relation":null,"conditions":[]},{"frameworks":["soc2","iso27001"],"explanation":"Credential and infrastructure findings can feed leakage controls and protect authentication information. Detection does not manage credential allocation, storage, rotation or revocation; incident narratives are not automatically credentials.\nISO/IEC 27001: A.8.12: Use an operated leakage-protection workflow with defined alert triage, warnings, blocking or another protective response.","kind":"framework","references":{"soc2":["CC6.7","CC6.1"],"iso27001":["A.8.12","A.5.17"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"Detecting secrets and security-operations detail supplies a specific input to responsible AI-use procedures. This link requires documented prohibited-input rules and an operated disposition; the detector does not define or operate the whole process.","kind":"framework","references":{"iso":["A.9.2"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-008","frameworkRefs":{"ISO27001":["A.8.12","A.5.17"],"ISO42001":["A.9.2"],"NIST-CSF":["PR.DS-02","DE.CM-09"],"SOC2":["CC6.7","CC6.1"]}},{"id":"GRD-009","section":"Runtime Guardrails","requirement":"Detect proprietary source code and engineering content","acceptance":"Identify source code exposure across browser, IDE, desktop, CLI and agent workflows.","tier":"AT0–AT4","whyItMatters":"Source code is pasted into AI tools daily, across more surfaces than any other data type.","verificationMethod":"LT","verificationTest":"Proprietary code is detected in browser, IDE, CLI and agent use by pilot users.","formerly":"DAT-013","alsoIn":[],"sort":19,"adoptionContext":"Source code and engineering material can move through assistants, platforms and agent workflows as well as shadow tools; protection should follow the content.","mappings":[{"frameworks":["csf"],"explanation":"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.","kind":"framework","references":{"csf":["PR.DS-02","DE.CM-09"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MANAGE 1.3"]},"relation":null,"conditions":[]},{"frameworks":["soc2","iso27001"],"explanation":"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.\nSOC 2: C1.1: The Confidentiality category and relevant information must be in scope.\nISO/IEC 27001: A.8.12: Use an operated leakage-protection workflow with defined alert triage, warnings, blocking or another protective response.","kind":"framework","references":{"soc2":["C1.1","CC6.7"],"iso27001":["A.8.12"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.9.2"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-009","frameworkRefs":{"ISO27001":["A.8.12"],"ISO42001":["A.9.2"],"NIST-CSF":["PR.DS-02","DE.CM-09"],"NIST-AI-RMF":["MANAGE 1.3"],"SOC2":["C1.1","CC6.7"]}},{"id":"GRD-010","section":"Runtime Guardrails","requirement":"Support granular custom detections","acceptance":"Let authorized teams maintain custom keywords, client and project identifiers and deal codenames, with an audit trail.","tier":"AT0–AT4","whyItMatters":"Built-in models cannot know your client names, project codes or deal codenames.","verificationMethod":"W","verificationTest":"An authorized user adds a project codename and it is detected in the next pilot prompt, with the change audited.","formerly":"DAT-007","alsoIn":[],"sort":20,"adoptionContext":"Customer, project and deal vocabulary can appear across the listed employee AI settings, so custom detections should follow that vocabulary rather than one product.","mappings":[{"frameworks":["iso"],"explanation":"The audit trail of custom-detection changes supplies AI event-record evidence. It does not establish complete logging coverage, retention or record protection.","kind":"framework","references":{"iso":["A.6.2.8"]},"relation":null,"conditions":[]},{"frameworks":["soc2","iso27001"],"explanation":"Custom detections tailor leakage rules to company information, while their audit trail records administrative changes. Detection still needs a protective disposition, and the trail alone does not demonstrate change testing and approval.\nISO/IEC 27001: A.8.15: Keep attributable records with appropriate retention, protection and analysis; a live view alone is insufficient. A.8.12: Use an operated leakage-protection workflow with defined alert triage, warnings, blocking or another protective response. Enforce authorization; keywords cannot replace a complete information inventory or semantic detection.","kind":"framework","references":{"soc2":["CC6.7","CC8.1"],"iso27001":["A.8.15","A.8.12"]},"relation":null,"conditions":[]},{"frameworks":["csf"],"explanation":"Custom client, project and codename detections configure a specific sensitive-data signal for protecting AI submissions. Use those detections in an operated leakage-protection workflow; a detector vocabulary is not an inventory of data holdings.","kind":"framework","references":{"csf":["PR.DS-02"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-010","frameworkRefs":{"ISO27001":["A.8.15","A.8.12"],"ISO42001":["A.6.2.8"],"NIST-CSF":["PR.DS-02"],"SOC2":["CC6.7","CC8.1"]}},{"id":"GRD-011","section":"Runtime Guardrails","requirement":"Maintain acceptable detection quality","acceptance":"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.","tier":"AT0–AT4","whyItMatters":"False positives decide whether employees and the SOC tolerate a control. A noisy one gets switched off.","verificationMethod":"LT + D","verificationTest":"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.","formerly":"DAT-008","alsoIn":[],"sort":21,"adoptionContext":"Detection quality should be tested across the listed employee AI contexts because supported surfaces, payloads and user behavior can change error rates.","mappings":[{"frameworks":["csf"],"explanation":"Documented false-positive and false-negative results help identify improvements from evaluations and tests. These outcomes concern identifying improvements, not implementing every finding.","kind":"framework","references":{"csf":["ID.IM-01","ID.IM-02"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.3","MEASURE 2.5"],"iso":["A.6.2.4","Cl. 9.1"]},"relation":null,"conditions":[]},{"frameworks":["soc2","iso27001"],"explanation":"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.\nISO/IEC 27001: Cl. 9.1: Metrics must evaluate information-security performance or control effectiveness; generic business metrics do not qualify.","kind":"framework","references":{"soc2":["CC4.1","CC7.2"],"iso27001":["Cl. 9.1","A.8.29"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-011","frameworkRefs":{"ISO27001":["Cl. 9.1","A.8.29"],"ISO42001":["A.6.2.4","Cl. 9.1"],"NIST-CSF":["ID.IM-01","ID.IM-02"],"NIST-AI-RMF":["MEASURE 2.3","MEASURE 2.5"],"SOC2":["CC4.1","CC7.2"]}},{"id":"GRD-012","section":"Runtime Guardrails","requirement":"Apply policy by user, group, role, department, tool, account plan and risk context","acceptance":"Show differentiated rules for high-risk and trusted populations, beyond a blanket allow or block, including distinct treatment by approval state: approved, restricted, unapproved, personal, free and unauthorized use. Resolve users to approved identity attributes from the directory or HR system so rules and reports can key off department and role.","tier":"AT0–AT4","whyItMatters":"Different teams carry different risk. One rule for everyone is either too loose or too blunt.","verificationMethod":"LT","verificationTest":"Two pilot groups get different outcomes for the same content, driven by directory attributes.","formerly":"POL-001","alsoIn":[],"sort":22,"adoptionContext":"User and business-context rules must follow employees across the listed AI settings; adoption tier alone is too coarse to decide authorization.","mappings":[{"frameworks":["soc2","iso27001"],"explanation":"Directory-resolved roles and other identity attributes let AI-use rules distinguish authorized populations, operations and destinations. This connects policy and identity context to contextual access decisions; showing differentiated rules alone does not demonstrate that access or data-transfer restrictions are enforced.\nISO/IEC 27001: A.8.3: Restrictions must take effect before the operation. An attribute feed does not establish identity lifecycle management, and incorrect or stale HR/directory attributes can undermine policy.","kind":"framework","references":{"soc2":["CC6.3","CC6.7"],"iso27001":["A.8.3","A.5.15"]},"relation":null,"conditions":[]},{"frameworks":["csf"],"explanation":"Contextual rules and directory-resolved attributes support cybersecurity policy and access authorization. Test the resulting permissions in practice; consuming identity attributes does not manage identity or credential lifecycles.","kind":"framework","references":{"csf":["GV.PO-01","PR.AA-05"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-012","frameworkRefs":{"ISO27001":["A.8.3","A.5.15"],"NIST-CSF":["GV.PO-01","PR.AA-05"],"SOC2":["CC6.3","CC6.7"]}},{"id":"GRD-013","section":"Runtime Guardrails","requirement":"Support monitor, warn, block, and restrict actions","acceptance":"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.","tier":"AT1–AT4","whyItMatters":"A control that can only block drives work onto personal devices. Graduated actions let policy match the risk.","verificationMethod":"LT","verificationTest":"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.","formerly":"DAT-003","alsoIn":[],"sort":23,"adoptionContext":"Intervention options are relevant across ordinary employee AI and connected-agent workflows, but each surface may support different monitor or enforcement actions.","mappings":[{"frameworks":["csf"],"explanation":"Configured block or restrict actions can protect data in transit when they act before egress. Monitor and warning modes do not establish enforced prevention.","kind":"framework","references":{"csf":["PR.DS-02"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["MANAGE 1.3"],"iso":["A.9.2"]},"relation":null,"conditions":[]},{"frameworks":["owasp"],"explanation":"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.","kind":"framework","references":{"owasp":["ASI02"]},"relation":null,"conditions":[]},{"frameworks":["soc2","iso27001"],"explanation":"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.\nISO/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.","kind":"framework","references":{"soc2":["CC5.3","CC6.7"],"iso27001":["Cl. 8.1","A.8.12","A.8.15"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-013","frameworkRefs":{"ISO27001":["Cl. 8.1","A.8.12","A.8.15"],"ISO42001":["A.9.2"],"NIST-CSF":["PR.DS-02"],"NIST-AI-RMF":["MANAGE 1.3"],"SOC2":["CC5.3","CC6.7"],"OWASP-ASI":["ASI02"]}},{"id":"GRD-014","section":"Runtime Guardrails","requirement":"Prevent sensitive data reaching unauthorized tools or account tiers","acceptance":"Block before egress while allowing legitimate work and treating sanctioned and personal tiers differently.","tier":"AT0–AT4","whyItMatters":"The same content can be fine in an enterprise tenant and a reportable incident in a personal one.","verificationMethod":"LT","verificationTest":"The same sensitive content is allowed to the enterprise tenant and stopped for a personal account.","formerly":"DAT-004","alsoIn":[],"sort":24,"adoptionContext":"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":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nISO/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.","kind":"framework","references":{"csf":["PR.AA-05","PR.DS-02"],"soc2":["CC6.7"],"iso27001":["A.8.12","A.8.3","A.5.14"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MANAGE 1.3"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.9.2"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-014","frameworkRefs":{"ISO27001":["A.8.12","A.8.3","A.5.14"],"ISO42001":["A.9.2"],"NIST-CSF":["PR.AA-05","PR.DS-02"],"NIST-AI-RMF":["MANAGE 1.3"],"SOC2":["CC6.7"]}},{"id":"GRD-015","section":"Runtime Guardrails","requirement":"Coach employees in the moment","acceptance":"Show prompt-specific guidance naming the policy issue, and return the same feedback into developer tooling and MCP clients where the action originates there.","tier":"AT0–AT4, AT6","whyItMatters":"Coaching that names the issue and the safe alternative changes behavior; an unexplained block teaches nothing.","verificationMethod":"LT","verificationTest":"Pilot users see prompt-specific guidance with your policy links in the browser, IDE and MCP client.","formerly":"DAT-018","alsoIn":[],"sort":25,"adoptionContext":"In-the-moment guidance is relevant across employee AI and connected-agent use, wherever the interaction can present a meaningful warning or explanation.","mappings":[{"frameworks":["csf","soc2"],"explanation":"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.","kind":"framework","references":{"csf":["GV.PO-01","PR.AT-01"],"soc2":["CC2.2","CC1.4"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 2.2"],"iso":["Cl. 7.2","Cl. 7.3"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["Cl. 7.3","A.6.3"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-015","frameworkRefs":{"ISO27001":["Cl. 7.3","A.6.3"],"ISO42001":["Cl. 7.2","Cl. 7.3"],"NIST-CSF":["GV.PO-01","PR.AT-01"],"NIST-AI-RMF":["GOVERN 2.2"],"SOC2":["CC2.2","CC1.4"]}},{"id":"GRD-016","section":"Runtime Guardrails","requirement":"Explain each decision to the employee and the analyst","acceptance":"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.","tier":"AT0–AT4","whyItMatters":"Explaining the trigger lets the employee fix the prompt and the analyst confirm the decision, which cuts tickets on both sides.","verificationMethod":"LT","verificationTest":"The coaching message and the alert both show the detection that fired and highlight the content.","formerly":"DAT-020","alsoIn":["aidr"],"sort":26,"adoptionContext":"Employees and analysts meet these decisions in every listed context, so explanations should appear wherever the intervention does.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.","kind":"framework","references":{"csf":["DE.AE-02","PR.AT-01"],"soc2":["CC2.2","CC7.3"],"iso27001":["A.5.25","A.6.3"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.9"],"iso":["A.8.2"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-016","frameworkRefs":{"ISO27001":["A.5.25","A.6.3"],"ISO42001":["A.8.2"],"NIST-CSF":["DE.AE-02","PR.AT-01"],"NIST-AI-RMF":["MEASURE 2.9"],"SOC2":["CC2.2","CC7.3"]}},{"id":"GRD-017","section":"Runtime Guardrails","requirement":"Provide sensible policy defaults and no-code authoring","acceptance":"Editable baseline policies and recommended settings without regex or specialist rule writing.","tier":"AT0–AT4, AT6","whyItMatters":"Policy work should not require regex skills.","verificationMethod":"W","verificationTest":"Show the default policy set and author a new policy without writing patterns.","formerly":"POL-006","alsoIn":[],"sort":27,"adoptionContext":"Policy-authoring usability and defaults are governance-platform concerns across adoption tiers, rather than properties of a particular AI deployment pattern.","mappings":[{"frameworks":["csf","rmf","iso","soc2","iso27001"],"explanation":"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.","kind":"framework","references":{"csf":["GV.PO-01"],"rmf":["GOVERN 1.4"],"iso":["A.2.2"],"soc2":["CC5.3"],"iso27001":["A.5.1","A.5.10"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-017","frameworkRefs":{"ISO27001":["A.5.1","A.5.10"],"ISO42001":["A.2.2"],"NIST-CSF":["GV.PO-01"],"NIST-AI-RMF":["GOVERN 1.4"],"SOC2":["CC5.3"]}},{"id":"GRD-018","section":"Runtime Guardrails","requirement":"Turn acceptable-use policy into enforceable scenarios","acceptance":"Express AUP rules as policies and demonstrate enforcement.","tier":"AT0–AT4","whyItMatters":"An acceptable-use policy only matters if it can be enforced and shown to be enforced.","verificationMethod":"W + POV","verificationTest":"Three clauses from your AUP are expressed as policies and successfully tested in your pilot.","formerly":"GOV-007","alsoIn":["audit"],"sort":28,"adoptionContext":"Acceptable-use rules need concrete scenarios across the listed employee AI contexts rather than a policy that only addresses one application type.","mappings":[{"frameworks":["csf","iso","soc2","iso27001"],"explanation":"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.","kind":"framework","references":{"csf":["GV.PO-01"],"iso":["A.2.2","A.9.2"],"soc2":["CC5.3","CC4.1"],"iso27001":["Cl. 8.1","A.5.10","A.5.36"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 1.2"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-018","frameworkRefs":{"ISO27001":["Cl. 8.1","A.5.10","A.5.36"],"ISO42001":["A.2.2","A.9.2"],"NIST-CSF":["GV.PO-01"],"NIST-AI-RMF":["GOVERN 1.2"],"SOC2":["CC5.3","CC4.1"]}},{"id":"GRD-019","section":"Runtime Guardrails","requirement":"Roll out policy in stages, starting in monitor-only mode","acceptance":"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.","tier":"AT0–AT4, AT6","whyItMatters":"Nobody should switch on blocking before seeing what monitoring finds.","verificationMethod":"W + POV","verificationTest":"A policy moves from monitor to coach to block for one pilot group; record how long changes take to apply.","formerly":"POL-007","alsoIn":[],"sort":29,"adoptionContext":"Policies reach employees across every listed context, so staged rollout should apply to each surface, not only the browser.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.","kind":"framework","references":{"csf":["PR.PS-01","ID.RA-07"],"soc2":["CC8.1"],"iso27001":["A.8.32","A.8.9"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["MANAGE 1.3"],"iso":["Cl. 6.3"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-019","frameworkRefs":{"ISO27001":["A.8.32","A.8.9"],"ISO42001":["Cl. 6.3"],"NIST-CSF":["PR.PS-01","ID.RA-07"],"NIST-AI-RMF":["MANAGE 1.3"],"SOC2":["CC8.1"]}},{"id":"GRD-020","section":"Runtime Guardrails","requirement":"Scope exceptions to a single detection for a defined group","acceptance":"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.","tier":"Tier-independent","whyItMatters":"A team that needs latitude on one data type should not lose every other protection.","verificationMethod":"LT","verificationTest":"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.","formerly":"POL-009","alsoIn":[],"sort":30,"adoptionContext":"Exceptions apply wherever the group works, so a scoped exception should behave the same across every listed context.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nISO/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.","kind":"framework","references":{"csf":["ID.RA-07","PR.AA-05"],"soc2":["CC6.3","CC5.3"],"iso27001":["A.5.15","Cl. 6.1.3"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 1.4"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-020","frameworkRefs":{"ISO27001":["A.5.15","Cl. 6.1.3"],"NIST-CSF":["ID.RA-07","PR.AA-05"],"NIST-AI-RMF":["GOVERN 1.4"],"SOC2":["CC6.3","CC5.3"]}},{"id":"GRD-021","section":"Runtime Guardrails","requirement":"Keep typical added inline latency under 300 ms","acceptance":"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.","tier":"AT0–AT4","whyItMatters":"Added delay decides whether real-time enforcement is practical or only theoretical.","verificationMethod":"LT","verificationTest":"Record the added decision time on pilot prompts and the behavior when a decision is slow.","formerly":"ARC-013","alsoIn":[],"sort":31,"adoptionContext":"The listed assistant, platform and agent contexts can place controls inline with work, making added latency and failure behavior important deployment tests.","mappings":[{"frameworks":["soc2"],"explanation":"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.","kind":"framework","references":{"soc2":["CC9.1"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.3"],"iso":["Cl. 9.1"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["Cl. 9.1","Cl. 8.1"]},"relation":null,"conditions":[]},{"frameworks":["csf"],"explanation":"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.","kind":"framework","references":{"csf":["PR.IR-03"]},"relation":null,"conditions":[]}],"area":"Runtime Guardrails","areaSlug":"GRD","url":"/r/GRD-021","frameworkRefs":{"ISO27001":["Cl. 9.1","Cl. 8.1"],"ISO42001":["Cl. 9.1"],"NIST-CSF":["PR.IR-03"],"NIST-AI-RMF":["MEASURE 2.3"],"SOC2":["CC9.1"]}},{"id":"IDR-001","section":"AI Detection & Response","requirement":"Generate actionable alerts","acceptance":"Include tool, account type, detection type, policy, action, timestamp, and user or team context.","tier":"AT0–AT4","whyItMatters":"An alert the SOC cannot act on is noise. The fields decide whether triage takes seconds or a ticket.","verificationMethod":"LT","verificationTest":"Pilot alerts carry every listed field and can be triaged without opening another console.","formerly":"DAT-006","alsoIn":[],"sort":32,"adoptionContext":"Alerts need enough context to identify the originating employee AI workflow across the listed adoption settings, without unnecessarily reproducing sensitive content.","mappings":[{"frameworks":["csf"],"explanation":"Tool, account, policy, action, time and user context provide adverse-event analysis evidence and information suitable for authorized responders. An alert must actually reach the appropriate staff or tools; generation alone does not perform analysis.","kind":"framework","references":{"csf":["DE.AE-02","DE.AE-06"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"The contextual alert supplies an AI event record describing what was detected and what action occurred. Wider logging arrangements, including retention and protection, remain necessary.","kind":"framework","references":{"iso":["A.6.2.8"]},"relation":null,"conditions":[]},{"frameworks":["soc2","iso27001"],"explanation":"Context-rich alerts create an event trail and evidence for anomaly monitoring and incident triage. Determining incident significance, assigning ownership and responding require an operated review process.\nISO/IEC 27001: A.8.15: Keep attributable event records with appropriate retention, protection and analysis; a live view alone is insufficient.","kind":"framework","references":{"soc2":["CC7.2","CC7.3"],"iso27001":["A.8.15","A.5.25"]},"relation":null,"conditions":[]}],"area":"AI Detection & Response","areaSlug":"AIDR","url":"/r/IDR-001","frameworkRefs":{"ISO27001":["A.8.15","A.5.25"],"ISO42001":["A.6.2.8"],"NIST-CSF":["DE.AE-02","DE.AE-06"],"SOC2":["CC7.2","CC7.3"]}},{"id":"IDR-002","section":"AI Detection & Response","requirement":"Detect direct and indirect prompt injection attempts.","acceptance":"Identify, block, and flag prompt injection attempts, whether directly entered into the AI tool or read via connections to third-party tools.","tier":"AT0–AT4","whyItMatters":"Successful prompt injection can lead to sensitive data exfiltration or irreversible destructive agent actions.","verificationMethod":"LT","verificationTest":"Prompt injection attempts via user input or connected tools are detected and logged with evidence.","formerly":"DAT-014","alsoIn":[],"sort":33,"adoptionContext":"Jailbreak and misuse attempts can occur in any of the listed employee AI contexts; the tiers do not imply identical detection coverage.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nISO/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.","kind":"framework","references":{"csf":["DE.AE-02","DE.CM-09"],"soc2":["CC7.2"],"iso27001":["A.8.16","A.5.25"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 3.1"],"iso":["A.6.2.6"]},"relation":null,"conditions":[]}],"area":"AI Detection & Response","areaSlug":"AIDR","url":"/r/IDR-002","frameworkRefs":{"ISO27001":["A.8.16","A.5.25"],"ISO42001":["A.6.2.6"],"NIST-CSF":["DE.AE-02","DE.CM-09"],"NIST-AI-RMF":["MEASURE 3.1"],"SOC2":["CC7.2"]}},{"id":"IDR-003","section":"AI Detection & Response","requirement":"Identify use cases leading to elevated risk behavior.","acceptance":"Surface the use cases and teams that require additional training on safe usage principles.","tier":"AT0–AT4","whyItMatters":"Repeat exposure and under-use point to where risk reduction or enablement will pay off.","verificationMethod":"POV","verificationTest":"High-risk use cases and the associated users are identified in a pilot.","formerly":"VAL-005","alsoIn":["value"],"sort":34,"adoptionContext":"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":[{"frameworks":["csf","rmf","soc2","iso27001"],"explanation":"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.\nISO/IEC 27001: Confirm the need for monitoring and choose the interventions to apply.","kind":"framework","references":{"csf":["DE.CM-03"],"rmf":["MEASURE 3.1"],"soc2":["CC7.2"],"iso27001":["Cl. 9.1","A.8.16"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.6.2.6"]},"relation":null,"conditions":[]}],"area":"AI Detection & Response","areaSlug":"AIDR","url":"/r/IDR-003","frameworkRefs":{"ISO27001":["Cl. 9.1","A.8.16"],"ISO42001":["A.6.2.6"],"NIST-CSF":["DE.CM-03"],"NIST-AI-RMF":["MEASURE 3.1"],"SOC2":["CC7.2"]}},{"id":"IDR-004","section":"AI Detection & Response","requirement":"Integrate with SIEM, SOAR, ticketing, and identity systems","acceptance":"Use webhooks or APIs to consume relevant employee identity context and to push alerts into logging and response systems.","tier":"AT0–AT4","whyItMatters":"Security alerts need relevant context and need to stream to centralized repositories.","verificationMethod":"LT","verificationTest":"Pilot events can be enriched with employee identity context and streamed to your SIEM.","formerly":"GOV-003","alsoIn":[],"sort":35,"adoptionContext":"Operational integration with security, identity and service-management systems is a cross-tier governance capability.","mappings":[{"frameworks":["csf","soc2"],"explanation":"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.","kind":"framework","references":{"csf":["DE.AE-06"],"soc2":["CC7.3","CC7.4"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 4.3"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["A.5.25","A.8.15"]},"relation":null,"conditions":[]}],"area":"AI Detection & Response","areaSlug":"AIDR","url":"/r/IDR-004","frameworkRefs":{"ISO27001":["A.5.25","A.8.15"],"NIST-CSF":["DE.AE-06"],"NIST-AI-RMF":["GOVERN 4.3"],"SOC2":["CC7.3","CC7.4"]}},{"id":"AGT-001","section":"Agent & MCP Governance","requirement":"Govern tool calls at read, write and delete scope","acceptance":"Permit a read while refusing write, delete or other destructive actions, with every attempt logged and attributable.","tier":"AT1, AT3, AT4, AT6","whyItMatters":"One agent can read, write and delete in the same workflow. Allow or deny per app is too blunt.","verificationMethod":"LT","verificationTest":"Reads to a connected system are allowed while attempts to change or delete information are blocked.","formerly":null,"alsoIn":["guardrails"],"sort":36,"adoptionContext":"Citizen-built, code-executing and MCP-extended workflows can take consequential tool actions, making operation-level permissions relevant.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"Allowing reads while refusing writes, deletes and destructive operations enforces least privilege at the tool-call boundary. Enforce restrictions before the operation and record every attempt with usable attribution, retention, protection and analysis. Warnings or a live view alone are insufficient; runtime refusal does not review or revoke the underlying connector grant.","kind":"framework","references":{"csf":["PR.AA-05"],"soc2":["CC6.3"],"iso27001":["A.8.3","A.8.15"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"A defined, enforced boundary between permitted reads and prohibited destructive actions implements a concrete responsible-use procedure for agents. It contributes to the wider AI-use process without implying that the standard prescribes these exact API scopes.","kind":"framework","references":{"iso":["A.9.2"]},"relation":null,"conditions":[]},{"frameworks":["owasp"],"explanation":"Operation-level refusal limits destructive tool misuse and actions attempted through excessive or misapplied delegated identity. Attributable attempts help investigate those failures; the control covers the operations and tool paths where it is enforced.","kind":"framework","references":{"owasp":["ASI02","ASI03"]},"relation":null,"conditions":[]}],"area":"Agent & MCP Governance","areaSlug":"AGT","url":"/r/AGT-001","frameworkRefs":{"ISO27001":["A.8.3","A.8.15"],"ISO42001":["A.9.2"],"NIST-CSF":["PR.AA-05"],"SOC2":["CC6.3"],"OWASP-ASI":["ASI02","ASI03"]}},{"id":"AGT-002","section":"Agent & MCP Governance","requirement":"Flag destructive, over-scoped or anomalous agent actions","acceptance":"Detect excessive permissions, unexpected tools, destructive operations, abnormal call sequences and policy bypass.","tier":"AT3, AT4, AT6","whyItMatters":"Destructive or unusual agent actions are often the first sign of a hijacked or misconfigured agent.","verificationMethod":"LT","verificationTest":"A destructive or out-of-pattern tool call in the pilot is flagged with context.","formerly":null,"alsoIn":["aidr"],"sort":37,"adoptionContext":"The listed connected-agent contexts can produce abnormal tool sequences, excessive scope or destructive operations that ordinary prompt inspection may miss.","mappings":[{"frameworks":["csf","iso","soc2","iso27001"],"explanation":"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.\nISO/IEC 27001: A.8.16: Event assessment and response remain wider dependencies; test false-positive and response handling.","kind":"framework","references":{"csf":["DE.AE-02","DE.CM-09"],"iso":["A.6.2.6"],"soc2":["CC7.2","CC6.3"],"iso27001":["A.8.16","A.5.18"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MANAGE 4.1"]},"relation":null,"conditions":[]},{"frameworks":["owasp"],"explanation":"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.","kind":"framework","references":{"owasp":["ASI02","ASI03","ASI10"]},"relation":null,"conditions":[]}],"area":"Agent & MCP Governance","areaSlug":"AGT","url":"/r/AGT-002","frameworkRefs":{"ISO27001":["A.8.16","A.5.18"],"ISO42001":["A.6.2.6"],"NIST-CSF":["DE.AE-02","DE.CM-09"],"NIST-AI-RMF":["MANAGE 4.1"],"SOC2":["CC7.2","CC6.3"],"OWASP-ASI":["ASI02","ASI03","ASI10"]}},{"id":"AGT-003","section":"Agent & MCP Governance","requirement":"Inspect sensitive data retrieved through connectors mid-workflow","acceptance":"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.","tier":"AT3, AT4, AT6","whyItMatters":"Connectors pull sensitive data into a conversation even when the user's question is harmless.","verificationMethod":"LT","verificationTest":"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.","formerly":null,"alsoIn":["guardrails"],"sort":38,"adoptionContext":"Embedded assistants, integrated platforms, citizen workflows and MCP extensions can retrieve sensitive data after a benign prompt; inspect the returned payload.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nSOC 2: C1.1: The Confidentiality category and relevant information must be in scope.\nISO/IEC 27001: A.8.12: Operate inspection within a leakage-protection workflow with defined alert triage, warnings, blocking or another protective response.","kind":"framework","references":{"csf":["PR.DS-02","DE.CM-09"],"soc2":["CC6.7","C1.1"],"iso27001":["A.8.12"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.10"]},"relation":null,"conditions":[]}],"area":"Agent & MCP Governance","areaSlug":"AGT","url":"/r/AGT-003","frameworkRefs":{"ISO27001":["A.8.12"],"NIST-CSF":["PR.DS-02","DE.CM-09"],"NIST-AI-RMF":["MEASURE 2.10"],"SOC2":["CC6.7","C1.1"]}},{"id":"AGT-004","section":"Agent & MCP Governance","requirement":"Attribute every connector and tool call alert to a person","acceptance":"Answer which server and tool were called, by whom, using which identity, every time an alert or intervention fires.","tier":"AT3, AT4, AT6","whyItMatters":"Without attribution, an agent action cannot be investigated or tied to accountability.","verificationMethod":"LT","verificationTest":"Every pilot tool call alert shows the tool used, the surface, the user identity, and the result.","formerly":null,"alsoIn":["aidr","audit"],"sort":39,"adoptionContext":"The listed connected-agent contexts need an identity chain from the employee to the server and tool call, including the delegated identity actually used.","mappings":[{"frameworks":["soc2"],"explanation":"Linking the person, execution identity, server, tool, scope and result supplies usable information for correlating calls and reviewing identity use. It can reveal gaps between human and delegated identities; attribution alone does not authenticate the caller, manage the identity lifecycle or authorize the operation.","kind":"framework","references":{"soc2":["CC2.1","CC7.2"]},"relation":null,"conditions":[]},{"frameworks":["iso","iso27001"],"explanation":"The person-to-identity-to-tool chain supplies attribution needed for AI event records and an audit trail. Answering those questions does not by itself require persistent protected logs, and the chain must preserve the distinction between the person and any service or delegated identity.\nISO/IEC 27001: Human attribution must not expose credential values.","kind":"framework","references":{"iso":["A.6.2.8"],"iso27001":["A.8.15"]},"relation":null,"conditions":[]},{"frameworks":["owasp"],"explanation":"Visible identity and scope relationships help investigate inherited-identity abuse, excessive delegation and confused-deputy behavior. Attribution exposes how authority was used; it does not itself stop an unauthorized call.","kind":"framework","references":{"owasp":["ASI03"]},"relation":null,"conditions":[]},{"frameworks":["csf"],"explanation":"Joining the person, execution identity, server, tool, scope and result supports event correlation. Attribution does not authenticate the caller, manage identity lifecycles or authorize the operation.","kind":"framework","references":{"csf":["DE.AE-03"]},"relation":null,"conditions":[]}],"area":"Agent & MCP Governance","areaSlug":"AGT","url":"/r/AGT-004","frameworkRefs":{"ISO27001":["A.8.15"],"ISO42001":["A.6.2.8"],"NIST-CSF":["DE.AE-03"],"SOC2":["CC2.1","CC7.2"],"OWASP-ASI":["ASI03"]}},{"id":"AGT-005","section":"Agent & MCP Governance","requirement":"Provide targeted containment for a single connector or tool.","acceptance":"Disable or revoke one connector, tool, plugin, or integration for a user or group without switching off the whole AI tool.","tier":"AT1, AT2, AT3, AT6","whyItMatters":"When one connector misbehaves, switching off the whole AI tool punishes everyone.","verificationMethod":"LT","verificationTest":"One connector is disabled for one pilot group while the AI tool keeps working.","formerly":null,"alsoIn":["aidr"],"sort":40,"adoptionContext":"The listed agent contexts may share an AI client across multiple connectors, making targeted revocation preferable to disabling the whole tool when feasible.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nISO/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.","kind":"framework","references":{"csf":["RS.MI-01","RS.MI-02"],"soc2":["CC6.3","CC7.4"],"iso27001":["A.5.26","A.5.18"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["MANAGE 2.4"],"iso":["A.6.2.6"]},"relation":null,"conditions":[]},{"frameworks":["owasp"],"explanation":"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.","kind":"framework","references":{"owasp":["ASI08"]},"relation":null,"conditions":[]}],"area":"Agent & MCP Governance","areaSlug":"AGT","url":"/r/AGT-005","frameworkRefs":{"ISO27001":["A.5.26","A.5.18"],"ISO42001":["A.6.2.6"],"NIST-CSF":["RS.MI-01","RS.MI-02"],"NIST-AI-RMF":["MANAGE 2.4"],"SOC2":["CC6.3","CC7.4"],"OWASP-ASI":["ASI08"]}},{"id":"AGT-006","section":"Agent & MCP Governance","requirement":"Discover the MCP servers and connectors employees attach to their AI clients","acceptance":"Inventory local and remote MCP servers reached from desktop, IDE and CLI AI tools with owner, scope and exposure.","tier":"AT3, AT4, AT6","whyItMatters":"MCP-capable clients now ship inside IDEs, terminals and desktop apps, and each connector is a new path to corporate data.","verificationMethod":"LT","verificationTest":"Local and remote MCP servers used by pilot users appear with client, owner, scope and exposure.","formerly":"DIS-007","alsoIn":["spm"],"sort":41,"adoptionContext":"Citizen-built, code-executing and MCP-extended workflows can attach external servers, so connector discovery must reach those integration paths.","mappings":[{"frameworks":["csf","rmf"],"explanation":"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.","kind":"framework","references":{"csf":["GV.SC-04","ID.AM-04"],"rmf":["MAP 4.1"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.4.2","A.10.3"]},"relation":null,"conditions":[]},{"frameworks":["owasp"],"explanation":"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.","kind":"framework","references":{"owasp":["ASI04"]},"relation":null,"conditions":[]},{"frameworks":["soc2","iso27001"],"explanation":"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.\nISO/IEC 27001: Maintain usable, owned inventory records. Internally owned servers are not automatically suppliers, and discovery does not assess supplier security.","kind":"framework","references":{"soc2":["CC2.1","CC9.2"],"iso27001":["A.5.9","A.5.19"]},"relation":null,"conditions":[]}],"area":"Agent & MCP Governance","areaSlug":"AGT","url":"/r/AGT-006","frameworkRefs":{"ISO27001":["A.5.9","A.5.19"],"ISO42001":["A.4.2","A.10.3"],"NIST-CSF":["GV.SC-04","ID.AM-04"],"NIST-AI-RMF":["MAP 4.1"],"SOC2":["CC2.1","CC9.2"],"OWASP-ASI":["ASI04"]}},{"id":"AGT-007","section":"Agent & MCP Governance","requirement":"Map the actions available via each connector.","acceptance":"Show, per connector/MCP server, what actions are available and which are currently enabled.","tier":"AT3, AT4, AT6","whyItMatters":"Approving a connector without knowing which actions it exposes and which are enabled leaves the scope of available functionality unclear.","verificationMethod":"W","verificationTest":"For three connectors you name, the console lists the actions each exposes and shows which are currently enabled.","formerly":"DIS-008","alsoIn":["spm"],"sort":42,"adoptionContext":null,"mappings":[{"frameworks":["soc2","iso27001"],"explanation":"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.","kind":"framework","references":{"soc2":["CC3.2","CC6.3"],"iso27001":["Cl. 6.1.2","A.5.18"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"Knowing which actions a connector exposes helps identify risks and control needs associated with third-party components.","kind":"framework","references":{"rmf":["MAP 4.2"]},"relation":null,"conditions":[]},{"frameworks":["owasp"],"explanation":"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.","kind":"framework","references":{"owasp":["ASI03"]},"relation":null,"conditions":[]}],"area":"Agent & MCP Governance","areaSlug":"AGT","url":"/r/AGT-007","frameworkRefs":{"ISO27001":["Cl. 6.1.2","A.5.18"],"NIST-AI-RMF":["MAP 4.2"],"SOC2":["CC3.2","CC6.3"],"OWASP-ASI":["ASI03"]}},{"id":"AGT-008","section":"Agent & MCP Governance","requirement":"Support local and remote MCP gateway placement for employee AI clients","acceptance":"Support applicable Windows, macOS and Linux patterns, allow endpoint-integrated or remote placement, and define traffic coverage for each.","tier":"AT3, AT4, AT6","whyItMatters":"Different MCP clients need different gateway placements to be covered.","verificationMethod":"W + D","verificationTest":"The vendor shows local and remote MCP gateway placement and documents what each covers.","formerly":"ARC-005","alsoIn":[],"sort":43,"adoptionContext":"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":[{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MAP 4.2"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.4.5"]},"relation":null,"conditions":[]},{"frameworks":["owasp"],"explanation":"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.","kind":"framework","references":{"owasp":["ASI04"]},"relation":null,"conditions":[]}],"area":"Agent & MCP Governance","areaSlug":"AGT","url":"/r/AGT-008","frameworkRefs":{"ISO42001":["A.4.5"],"NIST-AI-RMF":["MAP 4.2"],"OWASP-ASI":["ASI04"]}},{"id":"AGT-009","section":"Agent & MCP Governance","requirement":"Detect indirect prompt injection in content agents read","acceptance":"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.","tier":"AT3, AT4, AT6","whyItMatters":"A poisoned tool response can turn a trusted agent into an attacker's tool while the user's prompt looks harmless.","verificationMethod":"LT","verificationTest":"Injected instructions in content returned to pilot users' agents are detected and attributed to their source.","formerly":"DAT-014","alsoIn":["aidr"],"sort":44,"adoptionContext":"Indirect injection enters through connected-agent workflows and retrieved content; the listed tiers do not imply identical detection coverage.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nISO/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.","kind":"framework","references":{"csf":["DE.AE-02","DE.CM-09"],"soc2":["CC7.2"],"iso27001":["A.8.16","A.5.25"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 3.1"],"iso":["A.6.2.6"]},"relation":null,"conditions":[]},{"frameworks":["owasp"],"explanation":"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.","kind":"framework","references":{"owasp":["ASI01","ASI06"]},"relation":null,"conditions":[]}],"area":"Agent & MCP Governance","areaSlug":"AGT","url":"/r/AGT-009","frameworkRefs":{"ISO27001":["A.8.16","A.5.25"],"ISO42001":["A.6.2.6"],"NIST-CSF":["DE.AE-02","DE.CM-09"],"NIST-AI-RMF":["MEASURE 3.1"],"SOC2":["CC7.2"],"OWASP-ASI":["ASI01","ASI06"]}},{"id":"VAL-001","section":"AI Usage, Spend & Value","requirement":"Measure AI usage and adoption by tool, team, function and workflow","acceptance":"Report volumes, active users, trends and the sanctioned/unsanctioned split at privacy-appropriate aggregation.","tier":"AT0–AT4","whyItMatters":"Usage is the denominator for every cost, risk and value figure.","verificationMethod":"POV","verificationTest":"Usage by tool, team and function from pilot data, at privacy-appropriate aggregation.","formerly":null,"alsoIn":[],"sort":45,"adoptionContext":"Adoption reporting spans the listed employee AI contexts so sanctioned usage does not hide shadow or agent-assisted activity; privacy limits still govern the telemetry.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"Workforce usage and the sanctioned/unsanctioned split provide technology-monitoring context and inputs to security-performance and acceptable-use review. Adoption volumes and active-user counts alone are business analytics; security conclusions need relevant analysis and follow-up.","kind":"framework","references":{"csf":["DE.CM-03"],"soc2":["CC7.2"],"iso27001":["Cl. 9.1","A.5.36"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"The sanctioned and unsanctioned usage split provides policy-performance evidence when included in AI-management-system evaluation. Define the relevant objectives and evaluation method; pure activity volumes do not establish responsible-use objectives or effectiveness.","kind":"framework","references":{"iso":["Cl. 9.1"]},"relation":null,"conditions":[]}],"area":"AI Usage, Spend & Value","areaSlug":"VAL","url":"/r/VAL-001","frameworkRefs":{"ISO27001":["Cl. 9.1","A.5.36"],"ISO42001":["Cl. 9.1"],"NIST-CSF":["DE.CM-03"],"SOC2":["CC7.2"]}},{"id":"VAL-002","section":"AI Usage, Spend & Value","requirement":"Classify AI activity into business-relevant use cases","acceptance":"Turn raw telemetry into recognizable tasks, workflows and functions.","tier":"Tier-independent","whyItMatters":"Tool-level data cannot tell a team drafting contracts from one summarizing public research.","verificationMethod":"POV","verificationTest":"Top use cases by function from pilot data, with personal conversations excluded.","formerly":null,"alsoIn":[],"sort":46,"adoptionContext":"Business-use classification can describe activity from any adoption tier; a deployment pattern alone does not identify the business purpose.","mappings":[{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["MAP 1.1"],"iso":["A.9.4"]},"relation":null,"conditions":[]}],"area":"AI Usage, Spend & Value","areaSlug":"VAL","url":"/r/VAL-002","frameworkRefs":{"ISO42001":["A.9.4"],"NIST-AI-RMF":["MAP 1.1"]}},{"id":"VAL-003","section":"AI Usage, Spend & Value","requirement":"Measure spend, waste and portfolio decisions","acceptance":"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.","tier":"Tier-independent","whyItMatters":"License waste and duplicate tools are often the fastest way to fund the control.","verificationMethod":"POV + W","verificationTest":"Licensed versus active use for one enterprise AI tool, and the cost method explained.","formerly":null,"alsoIn":[],"sort":47,"adoptionContext":"Portfolio cost, overlap and retirement decisions can compare AI services across adoption tiers rather than treating a tier as a measure of value.","mappings":[{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 1.7"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.4.5"]},"relation":null,"conditions":[]}],"area":"AI Usage, Spend & Value","areaSlug":"VAL","url":"/r/VAL-003","frameworkRefs":{"ISO42001":["A.4.5"],"NIST-AI-RMF":["GOVERN 1.7"]}},{"id":"VAL-004","section":"AI Usage, Spend & Value","requirement":"Measure productivity and business-value signals","acceptance":"Identify time saved, throughput, completion and quality indicators with stated assumptions.","tier":"Tier-independent","whyItMatters":"Risk without value is a brake. Value without risk is a blind spot.","verificationMethod":"POV","verificationTest":"Value indicators for pilot functions, shown with their assumptions.","formerly":null,"alsoIn":[],"sort":48,"adoptionContext":"Productivity and value evidence can be assessed across adoption tiers; the workflow, baseline and assumptions determine meaningful comparisons.","mappings":[{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MAP 3.1","MEASURE 4.3"]},"relation":null,"conditions":[]}],"area":"AI Usage, Spend & Value","areaSlug":"VAL","url":"/r/VAL-004","frameworkRefs":{"NIST-AI-RMF":["MAP 3.1","MEASURE 4.3"]}},{"id":"VAL-005","section":"AI Usage, Spend & Value","requirement":"Generate targeted training and enablement recommendations","acceptance":"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.","tier":"","whyItMatters":"Training aimed at the teams and behaviors that actually create risk works better than blanket training.","verificationMethod":"POV","verificationTest":"Prioritized enablement recommendations from pilot data, and a measure of whether behavior changed.","formerly":null,"alsoIn":[],"sort":49,"adoptionContext":"Training recommendations should reflect observed needs across the listed employee AI contexts instead of assuming that adoption tier determines competence.","mappings":[{"frameworks":["csf","rmf","iso","soc2"],"explanation":"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.","kind":"framework","references":{"csf":["PR.AT-01","PR.AT-02"],"rmf":["GOVERN 2.2"],"iso":["Cl. 7.2","Cl. 7.3"],"soc2":["CC1.4","CC2.2","CC4.1"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["Cl. 9.1","Cl. 7.3","A.6.3"]},"relation":null,"conditions":[]}],"area":"AI Usage, Spend & Value","areaSlug":"VAL","url":"/r/VAL-005","frameworkRefs":{"ISO27001":["Cl. 9.1","Cl. 7.3","A.6.3"],"ISO42001":["Cl. 7.2","Cl. 7.3"],"NIST-CSF":["PR.AT-01","PR.AT-02"],"NIST-AI-RMF":["GOVERN 2.2"],"SOC2":["CC1.4","CC2.2","CC4.1"]}},{"id":"VAL-006","section":"AI Usage, Spend & Value","requirement":"Measure employee self-remediation","acceptance":"Record whether a warned user cancels, edits, redirects or proceeds, and calculate a remediation rate where privacy allows.","tier":"AT0–AT4","whyItMatters":"Self-remediation shows whether coaching changes behavior or just records it.","verificationMethod":"POV","verificationTest":"Share of coached pilot interventions where the employee edits or cancels, and the trend over the pilot.","formerly":null,"alsoIn":[],"sort":50,"adoptionContext":"Shadow, embedded-assistant and integrated-platform interactions are primary contexts for observing whether employees cancel, edit or proceed after a warning.","mappings":[{"frameworks":["csf","iso"],"explanation":"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.","kind":"framework","references":{"csf":["ID.IM-01","PR.AT-01"],"iso":["Cl. 7.3","Cl. 9.1"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 4.1"]},"relation":null,"conditions":[]},{"frameworks":["soc2"],"explanation":"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.","kind":"framework","references":{"soc2":["CC4.1"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["Cl. 9.1","A.6.3"]},"relation":null,"conditions":[]}],"area":"AI Usage, Spend & Value","areaSlug":"VAL","url":"/r/VAL-006","frameworkRefs":{"ISO27001":["Cl. 9.1","A.6.3"],"ISO42001":["Cl. 7.3","Cl. 9.1"],"NIST-CSF":["ID.IM-01","PR.AT-01"],"NIST-AI-RMF":["MEASURE 4.1"],"SOC2":["CC4.1"]}},{"id":"VAL-007","section":"AI Usage, Spend & Value","requirement":"Provide role-based dashboards and reporting, up to board level","acceptance":"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.","tier":"AT0–AT2","whyItMatters":"Each audience, from SOC to board, needs its own view of the same data.","verificationMethod":"W","verificationTest":"The same pilot data shown through executive, function and security views.","formerly":"GOV-009","alsoIn":[],"sort":51,"adoptionContext":"Role-based governance reporting can combine workforce AI evidence from any adoption tier while limiting the detail each audience receives.","mappings":[{"frameworks":["iso","soc2","iso27001"],"explanation":"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.","kind":"framework","references":{"iso":["Cl. 9.1","Cl. 9.3"],"soc2":["CC2.1","CC2.2","CC4.1"],"iso27001":["Cl. 9.1","Cl. 9.3.2"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 2.1"]},"relation":null,"conditions":[]},{"frameworks":["csf"],"explanation":"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.","kind":"framework","references":{"csf":["GV.OV-03"]},"relation":null,"conditions":[]}],"area":"AI Usage, Spend & Value","areaSlug":"VAL","url":"/r/VAL-007","frameworkRefs":{"ISO27001":["Cl. 9.1","Cl. 9.3.2"],"ISO42001":["Cl. 9.1","Cl. 9.3"],"NIST-CSF":["GV.OV-03"],"NIST-AI-RMF":["GOVERN 2.1"],"SOC2":["CC2.1","CC2.2","CC4.1"]}},{"id":"AUD-001","section":"Audit & Evidence","requirement":"Keep a configurable record of each conversation","acceptance":"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.","tier":"Tier-independent","whyItMatters":"The conversation, not the single prompt, is the unit an investigator or auditor needs to see.","verificationMethod":"W","verificationTest":"Show one pilot conversation's record at full, partial and metadata-only capture settings.","formerly":"GOV-014","alsoIn":["aidr"],"sort":52,"adoptionContext":"Logging-depth choices apply across adoption tiers, balancing needed evidence against data minimization and any applicable retention rule.","mappings":[{"frameworks":["csf","iso","soc2"],"explanation":"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.\nSOC 2: P3.1/P4.2 require the Privacy category and relevant information in scope.","kind":"framework","references":{"csf":["PR.PS-04"],"iso":["A.6.2.8"],"soc2":["CC7.2","P3.1","P4.2"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.8"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["A.8.15","A.5.34"]},"relation":null,"conditions":[]}],"area":"Audit & Evidence","areaSlug":"AUD","url":"/r/AUD-001","frameworkRefs":{"ISO27001":["A.8.15","A.5.34"],"ISO42001":["A.6.2.8"],"NIST-CSF":["PR.PS-04"],"NIST-AI-RMF":["MEASURE 2.8"],"SOC2":["CC7.2","P3.1","P4.2"]}},{"id":"AUD-002","section":"Audit & Evidence","requirement":"Export audit and forensic evidence","acceptance":"API, CSV, webhook or evidence package suitable for audit and incident response use.","tier":"Tier-independent","whyItMatters":"Evidence has to leave the console in a form legal, HR and auditors can use.","verificationMethod":"W","verificationTest":"Export an evidence package for one pilot incident.","formerly":"GOV-002","alsoIn":[],"sort":53,"adoptionContext":"Evidence export serves investigation and audit across adoption tiers; the relevant source and access restrictions still follow the records.","mappings":[{"frameworks":["csf","iso","soc2","iso27001"],"explanation":"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.","kind":"framework","references":{"csf":["RS.AN-07"],"iso":["A.6.2.8"],"soc2":["CC2.1","CC7.3"],"iso27001":["A.5.28"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 4.3"]},"relation":null,"conditions":[]}],"area":"Audit & Evidence","areaSlug":"AUD","url":"/r/AUD-002","frameworkRefs":{"ISO27001":["A.5.28"],"ISO42001":["A.6.2.8"],"NIST-CSF":["RS.AN-07"],"NIST-AI-RMF":["GOVERN 4.3"],"SOC2":["CC2.1","CC7.3"]}},{"id":"AUD-003","section":"Audit & Evidence","requirement":"Restrict and audit access to raw prompt content","acceptance":"Provide RBAC controls over who can read full prompt content, and record each access to it.","tier":"Tier-independent","whyItMatters":"Raw prompts are among the most sensitive data the control holds, so access must be limited and logged.","verificationMethod":"W","verificationTest":"Only an authorized role can open full prompt content, and each access is recorded.","formerly":"GOV-005","alsoIn":["platform"],"sort":54,"adoptionContext":"Raw prompt access needs protection across the listed employee AI settings, independently of whether the underlying application is sanctioned.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nISO/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.","kind":"framework","references":{"csf":["PR.AA-05","PR.DS-01"],"soc2":["CC6.3","CC7.2"],"iso27001":["A.8.3","A.8.15"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.10"]},"relation":null,"conditions":[]}],"area":"Audit & Evidence","areaSlug":"AUD","url":"/r/AUD-003","frameworkRefs":{"ISO27001":["A.8.3","A.8.15"],"NIST-CSF":["PR.AA-05","PR.DS-01"],"NIST-AI-RMF":["MEASURE 2.10"],"SOC2":["CC6.3","CC7.2"]}},{"id":"PLT-001","section":"Platform, Privacy & Assurance","requirement":"Minimize endpoint and network architecture risk","acceptance":"Support agentless and optional-agent patterns, and avoid kernel mode, reverse proxy and major network changes unless justified and tested.","tier":"AT0–AT4","whyItMatters":"Kernel components, proxies and network changes add operational risk that should be justified.","verificationMethod":"D","verificationTest":"The vendor documents the deployment architecture and justifies any privileged component.","formerly":"ARC-006","alsoIn":[],"sort":55,"adoptionContext":"Endpoint and network design risks span the listed employee AI settings; broad coverage should not assume that one deployment architecture fits every surface.","mappings":[{"frameworks":["soc2","iso27001"],"explanation":"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.","kind":"framework","references":{"soc2":["CC6.1","CC8.1"],"iso27001":["A.8.27","A.8.29"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MAP 4.2"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.6.2.5"]},"relation":null,"conditions":[]},{"frameworks":["csf"],"explanation":"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.","kind":"framework","references":{"csf":["PR.PS-01"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-001","frameworkRefs":{"ISO27001":["A.8.27","A.8.29"],"ISO42001":["A.6.2.5"],"NIST-CSF":["PR.PS-01"],"NIST-AI-RMF":["MAP 4.2"],"SOC2":["CC6.1","CC8.1"]}},{"id":"PLT-002","section":"Platform, Privacy & Assurance","requirement":"Disclose where decisions are enforced and how the control fails","acceptance":"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.","tier":"AT0–AT4","whyItMatters":"Where a decision runs and how it fails decide whether data is actually stopped.","verificationMethod":"D + LT","verificationTest":"The vendor documents enforcement points and failure modes per surface, and the pilot confirms them.","formerly":"ARC-015","alsoIn":["guardrails"],"sort":56,"adoptionContext":"Enforcement points and failure behavior can differ by surface, so each listed context needs its own answer.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nSOC 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.","kind":"framework","references":{"csf":["PR.IR-03","PR.DS-02"],"soc2":["CC6.7","CC9.1"],"iso27001":["A.8.27","A.8.20"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["MAP 4.2"],"iso":["A.6.2.5"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-002","frameworkRefs":{"ISO27001":["A.8.27","A.8.20"],"ISO42001":["A.6.2.5"],"NIST-CSF":["PR.IR-03","PR.DS-02"],"NIST-AI-RMF":["MAP 4.2"],"SOC2":["CC6.7","CC9.1"]}},{"id":"PLT-003","section":"Platform, Privacy & Assurance","requirement":"Deploy silently through endpoint management with release controls","acceptance":"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.","tier":"AT0–AT4","whyItMatters":"Deployment is where enterprise controls most often fail.","verificationMethod":"POV","verificationTest":"Pilot devices are deployed silently through your endpoint management, with deployment health visible.","formerly":"ARC-016","alsoIn":[],"sort":57,"adoptionContext":"Endpoint components underpin coverage in every listed context, so deployment health determines real coverage.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.","kind":"framework","references":{"csf":["PR.PS-02","ID.AM-08"],"soc2":["CC8.1"],"iso27001":["A.8.32","A.8.9"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["MANAGE 2.4"],"iso":["A.6.2.5"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-003","frameworkRefs":{"ISO27001":["A.8.32","A.8.9"],"ISO42001":["A.6.2.5"],"NIST-CSF":["PR.PS-02","ID.AM-08"],"NIST-AI-RMF":["MANAGE 2.4"],"SOC2":["CC8.1"]}},{"id":"PLT-004","section":"Platform, Privacy & Assurance","requirement":"Support Linux endpoints","acceptance":"Provide Linux visibility or document an equivalent coverage method.","tier":"AT0, AT4","whyItMatters":"Engineering teams on Linux are often the heaviest AI users.","verificationMethod":"LT","verificationTest":"AI use on a pilot Linux endpoint is visible, or an equivalent method is shown.","formerly":"ARC-003","alsoIn":[],"sort":58,"adoptionContext":"Linux support is relevant to shadow applications and code-agent workflows on employee endpoints; the operating system is a coverage choice, not an adoption tier itself.","mappings":[{"frameworks":["csf","iso27001"],"explanation":"Linux visibility or a tested network, MCP or API alternative can close an endpoint-monitoring blind spot. Platform support or a documented alternative is not itself anomaly detection or endpoint security; equivalent coverage must be demonstrated.","kind":"framework","references":{"csf":["DE.CM-09"],"iso27001":["A.8.16"]},"relation":null,"conditions":[]},{"frameworks":["soc2"],"explanation":"Linux visibility or an equivalent collection route can supply security-monitoring telemetry within the system boundary. Demonstrate actual, attributable security-relevant events; documenting an available method alone does not establish monitoring coverage.","kind":"framework","references":{"soc2":["CC7.2"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-004","frameworkRefs":{"ISO27001":["A.8.16"],"NIST-CSF":["DE.CM-09"],"SOC2":["CC7.2"]}},{"id":"PLT-005","section":"Platform, Privacy & Assurance","requirement":"Support network-based AI traffic detection where the architecture requires it","acceptance":"Integrate with SASE or network controls, identify AI hosts and protocols, and state whether the implementation is passive or inline.","tier":"AT0–AT2","whyItMatters":"Some architectures need network-level coverage, and the difference between passive and inline matters.","verificationMethod":"W + D","verificationTest":"The vendor shows the network integration and states whether it is passive or inline.","formerly":"ARC-001","alsoIn":[],"sort":59,"adoptionContext":"Shadow, vendor-embedded and platform-integrated AI can create network-visible traffic; whether network inspection is appropriate depends on the architecture.","mappings":[{"frameworks":["soc2"],"explanation":"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.","kind":"framework","references":{"soc2":["CC7.2"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MAP 4.2"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.4.5"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["A.8.16"]},"relation":null,"conditions":[]},{"frameworks":["csf"],"explanation":"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.","kind":"framework","references":{"csf":["DE.CM-01","DE.CM-06"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-005","frameworkRefs":{"ISO27001":["A.8.16"],"ISO42001":["A.4.5"],"NIST-CSF":["DE.CM-01","DE.CM-06"],"NIST-AI-RMF":["MAP 4.2"],"SOC2":["CC7.2"]}},{"id":"PLT-006","section":"Platform, Privacy & Assurance","requirement":"Scale enforcement and telemetry to the full population","acceptance":"Demonstrate capacity, latency and availability, and dashboard, drill-down, search and export performance, at the target scale.","tier":"AT2, AT4, AT6","whyItMatters":"A control proven at a few thousand users can behave like a different product at full scale.","verificationMethod":"D + POV","verificationTest":"The vendor provides a reference at your scale and demonstrates console performance on pilot data.","formerly":"ARC-007","alsoIn":[],"sort":60,"adoptionContext":"Population-scale capacity and availability matter across adoption tiers, with the actual workload and deployment determining the test conditions.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nISO/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.","kind":"framework","references":{"csf":["PR.IR-04"],"soc2":["A1.1"],"iso27001":["Cl. 9.1","A.8.6"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.3"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.4.5"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-006","frameworkRefs":{"ISO27001":["Cl. 9.1","A.8.6"],"ISO42001":["A.4.5"],"NIST-CSF":["PR.IR-04"],"NIST-AI-RMF":["MEASURE 2.3"],"SOC2":["A1.1"]}},{"id":"PLT-007","section":"Platform, Privacy & Assurance","requirement":"Resist common circumvention paths","acceptance":"Test disabling the extension, switching browser or private mode, personal accounts and desktop or CLI routes; document residual gaps.","tier":"AT0, AT3, AT4, AT6","whyItMatters":"A control that is easy to bypass gives false assurance.","verificationMethod":"LT","verificationTest":"Pilot testers try disabling the extension, switching browser and using CLI routes; record residual gaps.","formerly":"ARC-011","alsoIn":["guardrails"],"sort":61,"adoptionContext":"Shadow tools and code-agent workflows are primary contexts for testing alternate execution and connection paths that may evade the intended controls.","mappings":[{"frameworks":["csf","rmf","iso","soc2","iso27001"],"explanation":"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.\nISO/IEC 27001: Define responsibility, frequency and evaluation for security-performance or control-effectiveness measures; generic business metrics do not qualify.","kind":"framework","references":{"csf":["ID.IM-02","ID.RA-01"],"rmf":["MEASURE 1.2"],"iso":["A.6.2.4"],"soc2":["CC4.1","CC7.1"],"iso27001":["Cl. 9.1","Cl. 6.1.2","A.8.29"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-007","frameworkRefs":{"ISO27001":["Cl. 9.1","Cl. 6.1.2","A.8.29"],"ISO42001":["A.6.2.4"],"NIST-CSF":["ID.IM-02","ID.RA-01"],"NIST-AI-RMF":["MEASURE 1.2"],"SOC2":["CC4.1","CC7.1"]}},{"id":"PLT-008","section":"Platform, Privacy & Assurance","requirement":"Separate administrative roles, and authenticate them through enterprise SSO","acceptance":"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.","tier":"Tier-independent","whyItMatters":"Whoever can change policy or read prompts holds a lot of power, so roles must be separated and every action recorded.","verificationMethod":"W","verificationTest":"Show separate policy, investigation and exception roles, SSO login and the record of an admin action.","formerly":"POL-002","alsoIn":["audit"],"sort":62,"adoptionContext":"Administrative role separation and enterprise authentication apply to governance of workforce AI regardless of the end-user adoption tier.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nISO/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.","kind":"framework","references":{"csf":["GV.RR-02","PR.AA-03","PR.AA-05"],"soc2":["CC6.1","CC6.3"],"iso27001":["A.5.3","A.8.2","A.8.3","A.8.5","A.8.15"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 2.1"],"iso":["A.3.2","Cl. 5.3"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-008","frameworkRefs":{"ISO27001":["A.5.3","A.8.2","A.8.3","A.8.5","A.8.15"],"ISO42001":["A.3.2","Cl. 5.3"],"NIST-CSF":["GV.RR-02","PR.AA-03","PR.AA-05"],"NIST-AI-RMF":["GOVERN 2.1"],"SOC2":["CC6.1","CC6.3"]}},{"id":"PLT-009","section":"Platform, Privacy & Assurance","requirement":"Control telemetry residency, retention, encryption, deletion and masking","acceptance":"Validate region, retention period, encryption, deletion behavior, identity masking and exclusions with Legal and Privacy.","tier":"AT0, AT4","whyItMatters":"Residency, retention and masking are the first questions privacy and legal teams ask.","verificationMethod":"D + W","verificationTest":"The vendor documents region, retention, encryption, deletion and masking, and shows the settings.","formerly":"GOV-004","alsoIn":[],"sort":63,"adoptionContext":"Telemetry protection and retention choices apply across adoption tiers; actual data, deployment location and applicable obligations determine the settings.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nSOC 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.\nISO/IEC 27001: These settings do not establish cryptographic key governance.","kind":"framework","references":{"csf":["PR.DS-01","PR.DS-02"],"soc2":["CC6.1","CC6.7","C1.1","C1.2","P4.2","P4.3"],"iso27001":["A.8.10","A.8.11","A.8.24","A.5.33","A.5.31","A.5.34"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.10"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.4.3"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-009","frameworkRefs":{"ISO27001":["A.8.10","A.8.11","A.8.24","A.5.33","A.5.31","A.5.34"],"ISO42001":["A.4.3"],"NIST-CSF":["PR.DS-01","PR.DS-02"],"NIST-AI-RMF":["MEASURE 2.10"],"SOC2":["CC6.1","CC6.7","C1.1","C1.2","P4.2","P4.3"]}},{"id":"PLT-010","section":"Platform, Privacy & Assurance","requirement":"Offer required hosting regions","acceptance":"Document processing and storage locations, regional failover, subprocessor boundaries and tenant residency enforcement.","tier":"Tier-independent","whyItMatters":"Where data is processed and stored is often a contractual and legal requirement.","verificationMethod":"D","verificationTest":"The vendor documents processing and storage locations, failover and subprocessor boundaries.","formerly":"ARC-008","alsoIn":[],"sort":64,"adoptionContext":"Hosting and subprocessor-location choices are cross-tier deployment concerns; adoption tier does not create a universal residency obligation.","mappings":[{"frameworks":["csf","rmf","soc2"],"explanation":"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.","kind":"framework","references":{"csf":["GV.SC-07"],"rmf":["MAP 4.1"],"soc2":["CC9.2"]},"relation":null,"conditions":[]},{"frameworks":["iso"],"explanation":"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.","kind":"framework","references":{"iso":["A.4.5","A.10.3"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"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.","kind":"framework","references":{"iso27001":["A.5.23","A.5.31","A.5.34"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-010","frameworkRefs":{"ISO27001":["A.5.23","A.5.31","A.5.34"],"ISO42001":["A.4.5","A.10.3"],"NIST-CSF":["GV.SC-07"],"NIST-AI-RMF":["MAP 4.1"],"SOC2":["CC9.2"]}},{"id":"PLT-011","section":"Platform, Privacy & Assurance","requirement":"Inspect uploaded content without permanent file retention","acceptance":"Webhook, pointer or in-place inspection so source files stay in enterprise-controlled storage.","tier":"AT0–AT4","whyItMatters":"Copying every uploaded file into another vendor's storage creates a second copy to protect.","verificationMethod":"D + W","verificationTest":"The vendor documents and shows how uploads are inspected without permanent retention.","formerly":"GOV-012","alsoIn":[],"sort":65,"adoptionContext":"Upload inspection across the listed employee AI contexts should avoid unnecessary permanent copies, regardless of which tool receives the content.","mappings":[{"frameworks":["csf"],"explanation":"In-place or pointer-based inspection can examine data in use while limiting copied personal data and unnecessary retention by the inspection service. Buffers, logs, derived content and subprocessors still need checking; reduced copying does not prove zero retention or an operated leakage-prevention workflow.","kind":"framework","references":{"csf":["PR.DS-10"]},"relation":null,"conditions":[]},{"frameworks":["soc2"],"explanation":"Avoiding permanent copies can support personal-data retention limits when the Privacy category and relevant inspection service are in scope. Verify buffers, logs, derived content and subprocessors; enterprise source-file retention remains separate. Non-retention does not demonstrate that less personal information was collected or read.","kind":"framework","references":{"soc2":["P4.2"]},"relation":null,"conditions":[]},{"frameworks":["iso27001"],"explanation":"Keeping inspected files in enterprise-controlled storage can limit unnecessary PII copies. The privacy link depends on personal data being present and actual copying limits, including caches, previews, derived content and subprocessors. Non-retention does not demonstrate deletion or an operated leakage-prevention workflow.","kind":"framework","references":{"iso27001":["A.5.34"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-011","frameworkRefs":{"ISO27001":["A.5.34"],"NIST-CSF":["PR.DS-10"],"SOC2":["P4.2"]}},{"id":"PLT-012","section":"Platform, Privacy & Assurance","requirement":"Support pseudonymized and aggregate-only views where required","acceptance":"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.","tier":"Tier-independent","whyItMatters":"Where works councils or local law restrict individual attribution, monitoring still has to be possible.","verificationMethod":"W","verificationTest":"Pilot data viewed at team level with individual identity withheld.","formerly":"GOV-013","alsoIn":[],"sort":66,"adoptionContext":"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":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nSOC 2: P4.1 requires the Privacy category and relevant information in scope.\nISO/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.","kind":"framework","references":{"csf":["GV.OC-02","PR.AA-05"],"soc2":["CC6.3","P4.1"],"iso27001":["A.8.11","A.8.3","A.5.34"]},"relation":null,"conditions":[]},{"frameworks":["rmf"],"explanation":"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.","kind":"framework","references":{"rmf":["GOVERN 1.1","MEASURE 2.10"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-012","frameworkRefs":{"ISO27001":["A.8.11","A.8.3","A.5.34"],"NIST-CSF":["GV.OC-02","PR.AA-05"],"NIST-AI-RMF":["GOVERN 1.1","MEASURE 2.10"],"SOC2":["CC6.3","P4.1"]}},{"id":"PLT-013","section":"Platform, Privacy & Assurance","requirement":"Limit monitoring scope by design","acceptance":"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.","tier":"Tier-independent","whyItMatters":"Works councils and privacy teams judge the architecture, not the policy document.","verificationMethod":"W + D","verificationTest":"Show that non-AI browsing is not captured, a ring-fenced user is excluded, and the configuration is documented.","formerly":"GOV-016","alsoIn":[],"sort":67,"adoptionContext":"Monitoring reaches employees in every listed context, so scope limits should be enforced on each surface, not only in the browser.","mappings":[{"frameworks":["csf","soc2","iso27001"],"explanation":"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.\nSOC 2: P3.1, P4.1 require the Privacy category and relevant information in scope.","kind":"framework","references":{"csf":["GV.OC-03","PR.DS-10"],"soc2":["P3.1","P4.1"],"iso27001":["A.5.34"]},"relation":null,"conditions":[]},{"frameworks":["rmf","iso"],"explanation":"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.","kind":"framework","references":{"rmf":["MEASURE 2.10"],"iso":["A.5.4"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-013","frameworkRefs":{"ISO27001":["A.5.34"],"ISO42001":["A.5.4"],"NIST-CSF":["GV.OC-03","PR.DS-10"],"NIST-AI-RMF":["MEASURE 2.10"],"SOC2":["P3.1","P4.1"]}},{"id":"PLT-014","section":"Platform, Privacy & Assurance","requirement":"Maintain security assurance","acceptance":"Current evidence for SOC 2 Type II and ISO 27001.","tier":"Tier-independent","whyItMatters":"Standard assurance should be evidenced, not assumed.","verificationMethod":"D","verificationTest":"Current SOC 2 Type II report, ISO 27001 certificate and privacy terms are provided.","formerly":"ARC-009","alsoIn":[],"sort":68,"adoptionContext":"Supplier assurance supports procurement and oversight across adoption tiers, with the buyer’s own scope and use determining the relevant evidence.","mappings":[{"frameworks":["csf","rmf","iso","soc2","iso27001"],"explanation":"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.","kind":"framework","references":{"csf":["GV.SC-06","GV.SC-07"],"rmf":["GOVERN 6.1","MANAGE 3.1"],"iso":["A.10.3"],"soc2":["CC9.2"],"iso27001":["A.5.19","A.5.22"]},"relation":null,"conditions":[]}],"area":"Platform, Privacy & Assurance","areaSlug":"PLT","url":"/r/PLT-014","frameworkRefs":{"ISO27001":["A.5.19","A.5.22"],"ISO42001":["A.10.3"],"NIST-CSF":["GV.SC-06","GV.SC-07"],"NIST-AI-RMF":["GOVERN 6.1","MANAGE 3.1"],"SOC2":["CC9.2"]}}]}