7.4 The vendor-neutral control matrix
One matrix mapping every control to deployment model and posture so readers can apply the handbook to any AI surface.
7.4 The vendor-neutral control matrix
Last reviewed: August 18, 2026
Primer
A vendor-neutral matrix keeps the control objective stable when providers rename or combine products. Map each workflow to a deployment model, data class, and risk tier. Then use the provider notes to find the settings and evidence for that surface.
The seven domains align with the rest of the handbook: governance and rollout, identity, supply chain, runtime and autonomy, data protection, threats and incident response, and observability. The approach also supports NIST CSF 2.0, the NIST AI RMF, and the OWASP LLM Top 10 by assigning ownership, human oversight, evidence, and scenario-based testing.
How to use the matrix
Map the workflow to every deployment model it uses. A desktop agent that launches a hosted task belongs in two columns.
Apply the baseline cells for those columns.
Raise controls for regulated data, sensitive connected systems, write-capable actions, public publishing, and production autonomy.
Record status, owner, evidence, last-tested date, and any exception with an expiry date in 7.3 The security team checklist.
Revisit the mapping after incidents, material vendor changes, architecture changes, or new execution paths.
Control matrix
Minimum posture: interactive surfaces
Governance & rollout (7.1-7.4)
Inventory product, plan, cohort, data classes, apps, owners, training, evidence, and exit path; pilot before broad access
Inventory every client and execution path; approve repositories, environments, autonomy, support, and rollback
Inventory the app, browser, local permissions, remote execution, sensitive sites, action boundaries, and stop path
Identity (1.1-1.7)
SSO and lifecycle management where supported; role-gate connectors, agents, publishing, and administration
Managed user identity plus separate agent, project, and credential inventory; role-gate code execution
SSO; role-gate browser or desktop control; preserve the initiating user and task identity
Supply chain (2.1-2.10)
Approved apps and connectors only; record scopes, data classes, actions, and update triggers
Allowlisted MCP servers; review skills, plugins, hooks, packages, SDKs, and updates
Approved extensions and local integrations only; no unmanaged installation or update path
Runtime & autonomy (3.1-3.9)
No autonomous actions beyond the approved baseline; require approval for high-impact writes
Sandboxed execution; centrally enforced approvals, filesystem scope, and egress where supported
Explicit enablement by cohort; protect sensitive sites and apps; bound local and remote actions
Data protection (4.1-4.7)
Tested DLP or evidence path; retention, derived stores, deletion, data use, and cross-app sharing reviewed
Secrets scanning; deny sensitive paths; retention and residency verified for local and hosted context
DLP plus endpoint controls; govern clipboard, upload, download, generated files, links, and publishing
Threats & IR (5.1-5.7)
Test injection through connected content; define session, connector, and account containment
Test injection, exfiltration, tool and memory poisoning, spoofed results, SSRF, replay, cost exhaustion, and dependency compromise
Test malicious web and app content; exercise revocation of sessions, tasks, credentials, and outputs
Observability (6.1-6.7)
Reconcile workspace audit and compliance records; document message, file, and action gaps
Route versioned runtime and control events; measure delivery and completeness; preserve user, task, tool, target, and outcome attribution
Map endpoint, browser, provider, and target-system evidence; test investigation paths before enablement
Minimum posture: programmatic surfaces
Governance & rollout (7.1-7.4)
Named owners; approved purpose, data classes, action limits, stop criteria, expansion gate, recovery, and exit plan
Inventory organization, project, service, models, tools, data classes, and owners; pilot before production
Inventory builders, agents, owners, templates, connections, collaborators, publishing, and lifecycle state
Identity (1.1-1.7)
Dedicated agent identity with vaulted, scoped credentials and a tested revocation path
Workload identity or scoped project credentials; separate projects and service accounts by boundary
Role-gate builder access and publishing; every agent and connection has a named owner
Supply chain (2.1-2.10)
Pin and review agent definitions, models, tools, SDKs, containers, and other dependencies
Review tool definitions, SDKs, package sources, model changes, and deployment artifacts
Treat templates, marketplace components, actions, knowledge sources, and connections as supply chain
Runtime & autonomy (3.1-3.9)
Isolate tasks; manage secrets; restrict egress; limit spend, rate, duration, and actions; test the kill switch
Put guardrails, authorization, approval gates, limits, and stop behavior inside the application loop
Use least-privilege connections; require approval for sensitive writes; define execution and publishing boundaries
Data protection (4.1-4.7)
Verify state, memory, retrieval stores, residency, retention, deletion, encryption, and Zero Data Retention eligibility
Verify data controls per endpoint; redact logs and traces; keep secrets out of prompts and tool arguments
Scope connection credentials; prohibit personal connections; review generated artifacts and cross-app sharing
Threats & IR (5.1-5.7)
Threat-model the tool chain; test injection, memory and data poisoning, spoofed results, SSRF, replay, cost exhaustion, and containment
Run abuse-case tests before launch and after model, tool, or authorization changes
Review inherited permissions, agent-owned credentials, hidden instructions, and confused-deputy paths
Observability (6.1-6.7)
Capture versioned session, identity, approval, tool, target, outcome, spend, and stop events; reconcile completeness and latency
Combine traces and application logs with per-request user, project, model, tool, and decision attribution
Log runs, versions, connections, collaborators, publishing, and actions; keep evidence attributable to an owner
Owners, evidence, and handbook references
Governance & rollout
AI governance lead + business owner
Inventory, risk tier, training, pilot decision, RACI, exception register, exit exercise, review history
7.1-7.4
Identity
Identity lead + platform engineering
IdP and role exports, entitlement review, credential and agent-identity inventories, revocation tests
1.1-1.7
Supply chain
Security + platform engineering
Intake register, allowlists, provenance checks, dependency inventory, versioned review records
2.1-2.10
Runtime & autonomy
Platform engineering + security
Managed policies, isolation evidence, approval and denial events, egress tests, kill-switch exercise
3.1-3.9
Data protection
Data protection + compliance
DLP tests, data-store and flow map, regional, retention and deletion settings, contract terms, redaction tests
4.1-4.7
Threats & IR
Security architecture + testing + IR
Threat models, abuse-case and red-team reports, advisory tracking, tabletop and containment records
5.1-5.7
Observability
Security operations
Coverage matrix, versioned schema, latency and completeness measures, reconciliation reports, detections, review records
6.1-6.7
Common failure modes
A product is assigned to one column even though it crosses local, browser, and hosted execution.
Provider-wide settings are assumed to cover every surface and authentication path.
Controls are copied from workforce chat into autonomous agents without adding runtime, identity, and containment requirements.
Owners and evidence are vague.
An unavailable provider control is silently treated as passed instead of a gap, compensating control, or rollout blocker.
The matrix is not updated when a provider combines products or adds a new execution path.
Anthropic mapping
Use these mappings when applying the matrix:
Claude Web
Workforce chat
Connected apps and artifacts add supply-chain and cross-app data-flow controls
Claude Mobile
Workforce chat
Mobile device management, local sharing, and remote task initiation need separate evidence
Claude Desktop (Chat / Cowork / Code)
Workforce chat, browser or desktop agent, coding agent
Map the specific workspace and whether execution is local or remote
Claude Code
Coding agent
CLI, IDE, desktop Code, hosted tasks, and remote dispatch have different runtime and evidence paths
Claude Design
Workforce creative surface
Review input assets, generated outputs, sharing, retention, and audit evidence
Claude in Chrome
Browser agent
Protect sensitive sites and test untrusted web content
Claude Cowork
Browser or desktop agent
Remote research tasks also map to hosted agent
Claude Tag
Hosted agent
Slack identity, service accounts, Access bundles, Agent Proxy egress, retained memory, and downstream evidence
Claude for Microsoft 365
Browser or desktop agent
Cross-app actions and Office-agent telemetry are required considerations
Anthropic API & Agent Platform
API application and hosted agent
Includes API projects, SDKs, tool use, and Managed Agents
Within Claude Desktop (Chat / Cowork / Code), assess each section separately. Chat mainly inherits workspace identity, connector, retention, and audit controls, while the native app adds endpoint and local-integration exposure. Cowork can act through local folders, apps, browser use, and computer use or run remotely, so the selected matrix columns depend on the workflow. Code brings local repository, shell, filesystem, network, MCP, hook, sandbox, and approval risks into the desktop.
Claude Code can run through the CLI, IDE, desktop Code experience, and hosted or remote paths where enabled. For CLI and IDE, prioritize local identity, repository trust, filesystem scope, credentials, sandboxing, approvals, egress, MCP, and hooks. For hosted tasks, prioritize remote isolation, repository access, secrets, egress, retention, limits, termination, and hosted logs. For remote dispatch, preserve the initiator and test revocation.
Anthropic currently excludes Cowork and its Microsoft 365 add-ins from audit logs, the Compliance API, and data exports. Test the available OpenTelemetry feeds and downstream system logs before production. Managed Agents stays under the Anthropic API & Agent Platform taxonomy because its identity, SDK, dependency, hosted-runtime, retention, and observability controls belong to the API and hosted-agent planes.
Anthropic documentation
Applicable Harmonic guide
OpenAI mapping
Use these mappings when applying the matrix:
ChatGPT Web
Workforce chat
Apps, Work, generated files, Sites, and agentic actions can add other columns
ChatGPT Mobile
Workforce chat
Mobile device controls and remote task initiation need separate evidence
ChatGPT Desktop (Work / Codex)
Browser or desktop agent and coding agent
Map the Work or Codex section and whether execution is local or hosted
Codex
Coding agent
CLI, IDE, desktop, web or cloud, and remote dispatch have different runtime and evidence paths
OpenAI API Platform
API application and hosted agent
Includes organizations, projects, service accounts, Responses API, Agents SDK, and hosted workflows
Agent Builder
Low-code agent builder
Legacy transition surface; shutdown is scheduled for November 30, 2026
ChatGPT Desktop (Work / Codex) is one installation with distinct security paths. Work can use connected apps, research, local computer capabilities, file creation, and Sites publishing. Review app scopes, browser and computer-use boundaries, local permissions, generated artifacts, publishing, and action evidence. Codex in the desktop uses repositories, shell, filesystem, network, MCP, plugins, hooks, sandboxing, approvals, and managed configuration.
Codex also runs through the CLI, IDE, web or cloud tasks, and remote workflows. Local clients depend on repository trust, operating-system identity, filesystem scope, credentials, egress, and centrally enforced policy. Hosted tasks depend on remote environment isolation, repository access, cloud secrets, egress, retention, spend, termination, and provider or repository evidence. Remote dispatch must preserve initiator attribution and support task, session, and credential revocation.
For the OpenAI API Platform, inventory organizations, projects, service accounts, keys, model and tool access, data controls, rate and spend limits, and log sources. The Responses API and Agents SDK map to API application and hosted-agent controls. Agent Builder maps to the low-code column while teams migrate; record the target architecture, owner, and migration date before the scheduled November 30, 2026 shutdown.
The Enterprise Compliance API covers messages and responses across Chat, Work, and ChatGPT-authenticated Codex, but not Work files, actions, or tool calls. API-key-authenticated Codex follows API organization and project settings and requires separate evidence.
OpenAI documentation
Applicable Harmonic guides
Practitioner FAQs
Which deployment models should a program cover?
Most enterprise use fits six models: workforce chat, coding agents, browser or desktop agents, hosted agents, API applications, and low-code agent builders. A single product may use several models. Map the workflow, not only the product name.
How should risk posture change the baseline?
Regulated data, sensitive connected systems, write-capable actions, public publishing, and production autonomy raise requirements for identity, egress, approval, evidence, and containment. A small pilot on synthetic data may relax selected controls with a documented, time-bounded exception.
How should vendor settings be handled?
Keep provider settings in implementation notes mapped to a neutral control. When a provider renames or combines a product, update the mapping and retest the evidence path. The underlying control objective should remain stable.
Applicable regulations and frameworks
G.1 Map your controls to NIST AI RMF and CSF 2.0
This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes.
G.3 DORA and AI resilience in financial services
Conditional: for a DORA-regulated workflow, this supports risk-based rollout, control validation, and recovery readiness.
G.4 Colorado AI Act and the US state patchwork
Conditional: for covered Colorado ADMT, this supports the use-case inventory and technical control record.
G.5 SANS Critical AI Security Guidelines mapping
This article implements relevant SANS Deployment Strategies and GRC guidance.
G.6 Write an AI Acceptable Use Policy that holds up
This article supplies a technical or process control used to enforce the acceptable-use policy.
G.7 Ownership and RACI for AI security
This control depends on the ownership and evidence responsibilities defined in the RACI.
G.8 ISO/IEC 42001 AI management system
This article supports ISO/IEC 42001 AIMS preparation through scope, inventory, control selection, owners, and evidence.
G.9 HIPAA controls for AI systems handling PHI
Conditional: for a workflow handling ePHI, this supports HIPAA risk-based approval, safeguard validation, evidence, and reassessment.
G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.
Related handbook guidance
Was this helpful?