{"title":"AI Security Posture Management (SPM) Requirements — 13 Workforce AI Security Controls","description":"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.","updated":"2026-10-21","count":13,"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":"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"]}}]}