> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix.md).

# 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

{% hint style="info" %}
Use this matrix to select controls by deployment model before opening a vendor settings page. The cells define a moderate baseline. Raise the posture for regulated data, sensitive systems, write access, and production autonomy.
{% endhint %}

*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

1. Map the workflow to every deployment model it uses. A desktop agent that launches a hosted task belongs in two columns.
2. Apply the baseline cells for those columns.
3. Raise controls for regulated data, sensitive connected systems, write-capable actions, public publishing, and production autonomy.
4. Record status, owner, evidence, last-tested date, and any exception with an expiry date in [7.3 The security team checklist](/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist.md).
5. Revisit the mapping after incidents, material vendor changes, architecture changes, or new execution paths.

### Control matrix

#### Minimum posture: interactive surfaces

| Control domain                 | Workforce chat                                                                                                            | Coding agent                                                                                                                              | Browser or desktop agent                                                                                           |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| 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

| Control domain                 | Hosted agent                                                                                                                            | API application                                                                                            | Low-code agent builder                                                                                             |
| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| 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

| Control domain       | Typical owner                        | Minimum evidence                                                                                                         | Handbook |
| -------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | -------- |
| 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:

| Anthropic surface                     | Primary deployment model                               | Additional model or consideration                                                                              |
| ------------------------------------- | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------- |
| 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

* [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans)
* [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claudes-capabilities)
* [Claude Code settings](https://code.claude.com/docs/en/settings)
* [Claude Code permissions](https://code.claude.com/docs/en/permissions)
* [Claude Code security](https://code.claude.com/docs/en/security)
* [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview)
* [Monitor Claude Cowork activity with OpenTelemetry](https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry)
* [Work across Microsoft 365 apps with Claude](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps)
* [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview)
* [Skills for enterprise](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/enterprise)
* [Claude Tag agent identity](https://claude.com/docs/claude-tag/concepts/agent-identity)
* [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data)
* [Review what Claude Tag has done](https://claude.com/docs/claude-tag/admins/audit)

#### Applicable Harmonic guide

* [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide)

### OpenAI mapping

Use these mappings when applying the matrix:

| OpenAI surface                 | Primary deployment model                  | Additional model or consideration                                                                   |
| ------------------------------ | ----------------------------------------- | --------------------------------------------------------------------------------------------------- |
| 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

* [RBAC](https://help.openai.com/en/articles/11750701-rbac)
* [Admin controls, security, and compliance in apps](https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-in-apps-enterprise-edu-and-business)
* [Moving to the new ChatGPT desktop app](https://help.openai.com/en/articles/20001276)
* [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275)
* [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq)
* [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256)
* [Sites in ChatGPT](https://help.openai.com/en/articles/20001339)
* [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing)
* [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security)
* [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration)
* [Codex governance](https://developers.openai.com/codex/enterprise/governance)
* [Agents SDK](https://developers.openai.com/api/docs/guides/agents)
* [Agent Builder](https://developers.openai.com/api/docs/guides/agent-builder)
* [Workspace Agents](https://developers.openai.com/workspace-agents)

#### Applicable Harmonic guides

* [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide)
* [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice)

### 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

| Governance page                                     | Relationship to this article                                                                                                          |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| 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

* [7. Rollout & Operations](/handbook/7.-rollout-and-operations.md)
* [7.3 The security team checklist](/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist.md)
* [G.1 Map your controls to NIST AI RMF and CSF 2.0](/reference/governance-and-frameworks/g.1-map-your-controls-to-nist-ai-rmf-and-csf-2.0.md)
* [G.5 SANS Critical AI Security Guidelines mapping](/reference/governance-and-frameworks/g.5-sans-critical-ai-security-guidelines-mapping.md)
* [1.2 RBAC across AI platforms](/handbook/1.-identity-and-access/1.2-rbac-across-ai-platforms.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://handbook.harmonic.security/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.