# AI Security Posture Management (SPM) Requirements — 13 Workforce AI Security Controls > Discover every AI tool, account, model and agent in use, and keep posture continuously assessed. 13 vendor evaluation requirements with acceptance criteria, verification tests and framework mappings. Source: Harmonic Security, updated October 2026. 13 requirements. Disclaimer: Mappings indicate relevant contributions, not complete compliance, certification, assurance, a conformity assessment or legal advice. Read each explanation and its scope conditions. Legal applicability depends on jurisdiction, role, use and effective dates. Reference summaries are selective; consult current official sources and full licensed standards before relying on them. ## SPM-001: Classify previously unseen AI applications on first encounter - Area: AI Security Posture Management - Verification: Live test - OWASP adoption tier: AT0–AT4 - Formerly: DIS-014 - URL: /r/SPM-001 **Acceptance criteria:** Identify and risk-score an AI application the platform has not seen before, without waiting for a signature, category list or catalog update, and show the evidence behind the classification. **Why it matters:** Waiting for a catalog update leaves every new tool ungoverned during the period it is most likely to be tried. **How to verify:** An AI tool the vendor has not seen before is classified and risk-scored on first use, with the evidence shown. **OWASP adoption context:** Shadow AI is the primary first-encounter discovery scenario; an unfamiliar application should not require a prior catalog entry to become visible. **Mappings:** - NIST CSF 2.0: ID.AM-02, ID.RA-05; ISO 27001: Cl. 6.1.2, A.5.9 — Evidence-based first-encounter classification supplies timely software-inventory and risk-assessment inputs without catalog delay. A classification or score is not a maintained, owned inventory or a complete risk assessment. - NIST AI RMF: MAP 4.1 — Evidence behind unfamiliar-app classification helps map third-party AI component risks. The buyer must validate that evidence; signature-free detection is an implementation choice, not a complete risk-mapping process. - SOC 2: CC3.2, CC9.2 — New-service classification and scoring inform risk evaluation and supplier review. The buyer must validate scoring evidence and make the subsequent due-diligence and treatment decisions. - ISO 42001: A.4.2 — First-encounter identity and classification evidence help identify an AI resource for documentation. A one-time classification does not establish continued operational monitoring or support. ## SPM-002: Detect AI use at the browser point of use - Area: AI Security Posture Management - Verification: Live test - OWASP adoption tier: AT0 - Formerly: DIS-002 - URL: /r/SPM-002 **Acceptance criteria:** Show visibility in Chrome, Edge, Safari and Firefox where supported, including prompt context and account plan. **Why it matters:** The browser is where most employee AI use happens, so it is the first place visibility has to work. **How to verify:** Pilot users' AI use in each supported browser appears with prompt context and account plan. **OWASP adoption context:** The listed contexts focus on browser access to personal-account AI and vendor assistants; the supported browser and capture path still determine visibility. **Mappings:** - NIST CSF 2.0: DE.CM-03, DE.CM-09; ISO 42001: A.6.2.6 — 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. - SOC 2: CC7.2 — Point-of-use browser telemetry provides evidence for anomaly monitoring; the acceptance test does not require anomaly analysis or incident evaluation. - ISO 27001: A.8.16 — 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. ## SPM-003: Detect endpoint AI activity beyond the browser - Area: AI Security Posture Management - Verification: Live test - OWASP adoption tier: AT0, AT1 - Formerly: DIS-003 - URL: /r/SPM-003 **Acceptance criteria:** Identify desktop clients, IDEs, coding assistants, CLI tools and local agents on managed Windows and macOS endpoints. **Why it matters:** Desktop apps, IDEs and CLI tools carry a growing share of AI use, and browser-only controls never see them. **How to verify:** Desktop assistants, coding tools and CLI tools used by pilot users appear, attributed to user, device and application. **OWASP adoption context:** Endpoint inspection complements browser visibility for shadow applications and code-executing agent activity on employee devices. **Mappings:** - NIST CSF 2.0: ID.AM-02, DE.CM-03, DE.CM-09; ISO 27001: A.5.9, A.8.16 — 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. - ISO 42001: A.6.2.6 — Visibility into AI clients and processes on managed endpoints contributes to in-life operation monitoring, subject to demonstrated Windows and macOS coverage. - SOC 2: CC2.1, CC7.2 — Endpoint findings supply control information and monitoring inputs for otherwise hidden AI use. Client identification alone does not demonstrate suspicious-activity analysis. ## SPM-004: Detect direct model-provider API calls from employee devices - Area: AI Security Posture Management - Verification: Live test - OWASP adoption tier: AT0, AT4 - Formerly: DIS-004 - URL: /r/SPM-004 **Acceptance criteria:** Attribute provider, process, device, user and destination for direct API use with no browser involved. **Why it matters:** Scripts and tools that call model APIs directly bypass every browser control and often carry the most sensitive information. **How to verify:** A direct API call from a pilot device is attributed to provider, process, user and destination. **OWASP adoption context:** 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:** - NIST CSF 2.0: ID.AM-04, DE.CM-01, DE.CM-06; ISO 27001: A.8.16, A.5.9 — 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. - SOC 2: CC7.2 — 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. - ISO 42001: A.4.2 — 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. ## SPM-005: Discover local model runtimes and offline AI installations - Area: AI Security Posture Management - Verification: Live test - OWASP adoption tier: AT0, AT4 - Formerly: DIS-005 - URL: /r/SPM-005 **Acceptance criteria:** Identify installation and running process for tools such as Ollama or LM Studio. **Why it matters:** Local models move data off the monitored path entirely. **How to verify:** A local runtime installed on a pilot device is discovered and cataloged. **OWASP adoption context:** Local runtimes are relevant to shadow use and code-agent workflows even when no traffic reaches a hosted model provider. **Mappings:** - NIST CSF 2.0: ID.AM-02, DE.CM-09; ISO 27001: A.5.9, A.8.16 — 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. - SOC 2: CC2.1, CC6.1 — Local-runtime discovery supplies control information about hidden software and access exposure. It does not itself restrict installation or access. - ISO 42001: A.4.4 — 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. ## SPM-006: Discover AI embedded in sanctioned SaaS - Area: AI Security Posture Management - Verification: Live test - OWASP adoption tier: AT0, AT4 - Formerly: DIS-010 - URL: /r/SPM-006 **Acceptance criteria:** Identify AI features inside existing SaaS tools, such as Google AI Mode. **Why it matters:** AI features switched on inside approved SaaS create new data flows without a new application to approve. **How to verify:** A common SaaS application is identified and cataloged as an AI tool due to its embedded AI features. **OWASP adoption context:** Vendor-embedded and platform-integrated AI can be present inside already approved SaaS, so discovering the host application alone is insufficient. **Mappings:** - NIST CSF 2.0: ID.AM-02, ID.AM-04; ISO 27001: A.5.9, A.5.22 — Discovery of AI features within existing SaaS supplies updates to the software and service inventory and flags supplier-service changes. A discovery finding must feed maintained records and does not itself complete change review. - NIST AI RMF: MAP 4.1 — Identifying embedded AI makes new third-party components and supplier capabilities visible for risk mapping and supplier governance. Existing SaaS approval does not assess the newly discovered AI feature. - SOC 2: CC2.1, CC9.2 — Embedded-feature findings keep control information and the supplier-risk picture current. The buyer still needs to review the feature and decide its permitted use. - ISO 42001: A.4.2 — Discovering an embedded SaaS AI feature identifies an AI resource or component for the resource record. Existing SaaS approval does not establish assessment of that newly discovered feature. ## SPM-007: Provide visibility for unmanaged endpoints - Area: AI Security Posture Management - Verification: Walkthrough + Documentation - OWASP adoption tier: AT1, AT2 - Formerly: DIS-012 - URL: /r/SPM-007 **Acceptance criteria:** Use approved SaaS/API methods where no endpoint agent can be installed. **Why it matters:** Contractors and personal devices still reach corporate AI tenants, and some will never run an agent. **How to verify:** The vendor shows and documents the coverage method for an unmanaged device in your environment. **OWASP adoption context:** Shadow, vendor-embedded and platform-integrated use may occur without a managed endpoint; network or service-side visibility depends on the available architecture. **Mappings:** - NIST CSF 2.0: DE.CM-01, DE.CM-06 — 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. - ISO 42001: A.6.2.6 — Alternative collection methods contribute to the AI operation-monitoring arrangement for unmanaged endpoints. Its scope, gaps and operating process still need to be defined. - SOC 2: CC7.2; ISO 27001: A.8.16 — 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. ## SPM-008: Distinguish personal, free and guest accounts from sanctioned enterprise tenants - Area: AI Security Posture Management - Verification: Live test - OWASP adoption tier: AT0, AT1 - Formerly: DIS-006 - URL: /r/SPM-008 **Acceptance criteria:** Report a reliable account-type split at the point of use and allow policy to vary depending on account plan. **Why it matters:** Contractual protections attach to the enterprise tenant, not the domain. A personal account reaches the same URL with none of them. **How to verify:** Enterprise, personal and unauthenticated use of the same tool are each identified and handled per policy. **OWASP adoption context:** Personal-account and vendor-assistant contexts make account ownership and plan distinctions important; tier alone does not establish contractual safeguards. **Mappings:** - NIST AI RMF: MAP 4.1 — The account-plan distinction helps identify the third-party service context and supplier terms needing risk review. A plan label alone does not establish the applicable relationship or complete its assessment. - SOC 2: CC6.7, CC9.2; ISO 27001: A.8.3, A.5.23 — Reliable account-tier context can inform permitted data destinations, access restrictions and enterprise-cloud or supplier rules. The policy linkage must work in practice; classification alone does not enforce those rules. ISO/IEC 27001: Account identification does not manage the identity lifecycle. - NIST CSF 2.0: DE.CM-03 — The observed personal, free, guest or enterprise account context supports monitoring employee technology use. An account-plan label does not manage identities or credentials or enforce access. ## SPM-009: Risk-score AI tools, connectors and agent workflows - Area: AI Security Posture Management - Verification: Walkthrough - OWASP adoption tier: AT0–AT2 - Formerly: DIS-009 - URL: /r/SPM-009 **Acceptance criteria:** Configurable factors such as vendor location, training on inputs, trust-center availability, account tier, autonomy, data sensitivity and tool power. **Why it matters:** The risk in an AI tool usually sits in its data-handling terms, which change without the domain changing. **How to verify:** Risk scores, with sources and factors, for five tools. **OWASP adoption context:** Risk scoring spans ordinary employee AI and MCP-extended workflows because sensitivity, autonomy and tool power vary independently of approval status. **Mappings:** - NIST CSF 2.0: GV.RM-06, ID.RA-05 — Configurable risk factors can support a repeatable method for documenting and prioritizing inherent risk. The buyer must still define the method and connect scores to threats, likelihood, impact and response decisions. - NIST AI RMF: MAP 5.1 — Sensitivity, autonomy and tool-power factors can inform the likelihood and magnitude of impacts. A product score does not by itself document the full range of beneficial and harmful impacts. - OWASP ASI: ASI04 — Scoring connectors and agent workflows helps prioritize review of runtime-fetched tools and components exposed to agentic supply-chain risk. Scores do not verify component integrity. - SOC 2: CC3.2, CC9.2 — The configurable factors provide an AI risk-analysis step and inputs to repeat assessments and supplier due diligence. Risk criteria, likelihood, impact, ownership, acceptance and treatment remain the buyer’s responsibilities; a trust center is not assurance. - ISO 27001: Cl. 6.1.2, A.5.19 — Security-relevant scoring factors supply risk-analysis inputs; external-vendor factors also support supplier due diligence. The buyer must define risk criteria, likelihood, impact, ownership, acceptance and treatment. A score or vendor trust center is not a complete assessment or assurance; the supplier link applies only to external relationships. - ISO 42001: Cl. 6.1.2, Cl. 8.2, A.10.3 — ISO/IEC 42001: Validated tool and workflow risk factors provide inputs to the defined AI risk-assessment process and periodic or change-driven reassessments. A score does not establish a complete assessment, risk acceptance, treatment plan or assessment of effects on people or society. Supplier-specific factors, such as provider use of inputs and account terms, can also inform a defined responsible-AI supplier review; this supplier link applies only to external suppliers and validated evidence. ## SPM-010: Define default treatment for newly discovered AI services - Area: AI Security Posture Management - Verification: Live test - OWASP adoption tier: AT0, AT1 - Formerly: POL-004 - URL: /r/SPM-010 **Acceptance criteria:** Apply a documented default rule until the service is assessed as sanctioned, restricted or prohibited. **Why it matters:** New tools arrive faster than they can be assessed, so the default decides what happens in the meantime. **How to verify:** A tool first used during the pilot receives the documented default treatment. **OWASP adoption context:** Default treatment matters wherever employees can encounter a new AI service in the listed settings, before a full approval decision is available. **Mappings:** - NIST CSF 2.0: GV.PO-01; SOC 2: CC5.3, CC6.7; ISO 27001: Cl. 8.1, A.5.10, A.8.3 — Applying a documented default while a new service awaits assessment puts interim acceptable-use policy into operation. The default contributes to information-access and transfer restrictions only when its selected action actually restricts them; an applied permissive default is still a policy decision. ISO/IEC 27001: The chosen default must be approved and fit the organization’s risk treatment. - NIST AI RMF: MANAGE 1.1 — The interim rule records whether and under what conditions use may proceed before the service assessment is complete. It contributes to the proceed-or-do-not-proceed decision without replacing an assessment against the intended purpose and objectives. - ISO 42001: A.9.2 — A documented default for an unclassified AI service provides an interim responsible-use rule. The chosen default must be approved and fit the organization’s risk treatment; approval status is not the AI system’s intended function. ## SPM-011: Support the AI tool approval and review lifecycle - Area: AI Security Posture Management - Verification: Walkthrough - OWASP adoption tier: AT0–AT4, AT6 - Formerly: GOV-008 - URL: /r/SPM-011 **Acceptance criteria:** Define and track unapproved versus approved AI tools and MCP servers. **Why it matters:** Without a governed approval path, teams route around the control. **How to verify:** Walk a tool or MCP server request from intake to a recorded decision. **OWASP adoption context:** Managed assistants, platforms and connected-agent workflows need approval status and periodic review; status should be visible throughout the tool lifecycle. **Mappings:** - NIST AI RMF: GOVERN 6.1, MANAGE 3.1; SOC 2: CC9.2, CC5.3 — Approved/unapproved tool and MCP-server records supply inventory context and inputs to third-party governance and permitted-use review. Tracking status alone does not establish assessment criteria, due diligence, approval authority, periodic supplier review, retirement decisions, enforcement or conformity of actual use with its intended purpose. - ISO 27001: A.5.9, A.5.23 — Tool identity and approval status provide asset-register fields and, for cloud services, approval tracking within an operated cloud-use process. A status flag does not establish assessment criteria, approval authority, supplier due diligence, periodic review or retirement decisions. - ISO 42001: A.4.2 — Approved and unapproved tool records document AI resources and their status. They do not assess supplier responsibility or establish that actual use matches the system’s intended functions. - NIST CSF 2.0: ID.AM-02 — Approved and unapproved tool states provide concrete software and service-inventory attributes. Status tracking does not itself assess or manage changes and exceptions for cybersecurity risk. ## AGT-006: Discover the MCP servers and connectors employees attach to their AI clients - Area: Agent & MCP Governance - Verification: Live test - OWASP adoption tier: AT3, AT4, AT6 - Formerly: DIS-007 - URL: /r/AGT-006 **Acceptance criteria:** Inventory local and remote MCP servers reached from desktop, IDE and CLI AI tools with owner, scope and exposure. **Why it matters:** MCP-capable clients now ship inside IDEs, terminals and desktop apps, and each connector is a new path to corporate data. **How to verify:** Local and remote MCP servers used by pilot users appear with client, owner, scope and exposure. **OWASP adoption context:** Citizen-built, code-executing and MCP-extended workflows can attach external servers, so connector discovery must reach those integration paths. **Mappings:** - NIST CSF 2.0: GV.SC-04, ID.AM-04; NIST AI RMF: MAP 4.1 — The MCP and connector inventory identifies third-party components and services, with owner, scope and exposure to inform supplier prioritization and component-risk mapping. Discovery alone does not assess their risks. - ISO 42001: A.4.2, A.10.3 — ISO/IEC 42001: The local and remote MCP/connector inventory documents resources relevant to AI activities, including their owner, scope and exposure, supporting A.4.2. External MCP servers and connectors also identify supplier relationships to govern under A.10.3; locally owned servers are not automatically suppliers. Inventory does not establish supplier due diligence or trustworthiness. - OWASP ASI: ASI04 — The inventory exposes external MCP servers and runtime-connected components relevant to agentic supply-chain compromise. It provides a review surface, not evidence that components are trustworthy. - SOC 2: CC2.1, CC9.2; ISO 27001: A.5.9, A.5.19 — Owned connector records supply usable inventory/control information and inputs to supplier-risk review. Keeping the register current does not itself approve a connector or reduce its permissions. ISO/IEC 27001: Maintain usable, owned inventory records. Internally owned servers are not automatically suppliers, and discovery does not assess supplier security. ## AGT-007: Map the actions available via each connector. - Area: Agent & MCP Governance - Verification: Walkthrough - OWASP adoption tier: AT3, AT4, AT6 - Formerly: DIS-008 - URL: /r/AGT-007 **Acceptance criteria:** Show, per connector/MCP server, what actions are available and which are currently enabled. **Why it matters:** Approving a connector without knowing which actions it exposes and which are enabled leaves the scope of available functionality unclear. **How to verify:** For three connectors you name, the console lists the actions each exposes and shows which are currently enabled. **Mappings:** - SOC 2: CC3.2, CC6.3; ISO 27001: Cl. 6.1.2, A.5.18 — An inventory of connector actions and their enabled status supports risk assessment and access-rights review. It provides review inputs; it does not demonstrate effective permissions or their enforcement. - NIST AI RMF: MAP 4.2 — Knowing which actions a connector exposes helps identify risks and control needs associated with third-party components. - OWASP ASI: ASI03 — Reviewing available and enabled actions helps identify unnecessarily broad functionality. Assessing identity and privilege abuse also requires evidence about agent identities, credentials and delegated permissions. These mappings concern action visibility and review, not reachable-file discovery or data-flow mapping.