# 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 This site has an agentic ask interface you may use to query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://handbook.harmonic.security/index.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. --- # AI Security Handbook Harmonic Security’s practical AI security handbook for governing AI tools, agents, MCP, data protection, runtime controls, and incident response. *Last reviewed: August 18, 2026* Published and maintained by [Harmonic Security](https://www.harmonic.security/), this handbook gives security teams practical, source-backed guidance for governing AI tools, agents, MCP servers, data, and runtime controls. ## Most popular articles and tools

:box:

What is an AI sandboxInternal handbook article on what sandboxes control, where they stop, and how to test the boundary.3.1 What Even is an AI Sandbox?

:route:

Navigating OTelInternal handbook article on AI runtime visibility, telemetry pipelines, redaction, and investigations.6.2 OpenTelemetry for AI runtime visibility

:code-branch:

Navigating HooksInternal handbook article on lifecycle hooks, control points, logging, and supply-chain risk.2.6 AI hooks: inference controls and lifecycle automation

:arrow-up-right-from-square:

Auditing your ClaudeExternal resource: open-source tool for inspecting Claude Desktop usage and local configuration risk.https://github.com/HarmonicSecurity/claudit-sec

:arrow-up-right-from-square:

Securing ChatGPT WorkExternal resource: practitioner guide for managed rollout, data controls, sandboxing, and evidence.https://www.harmonic.security/resources/securing-chatgpt-work-a-practitioners-guide

:arrow-up-right-from-square:

Securing CoworkExternal resource: practitioner guide to Claude Cowork controls, OTel, prompts, connectors, and rollout.https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide
## Maintained vendor coverage The product profiles currently maintained in this handbook cover Anthropic and OpenAI. Other vendors should remain outside the published navigation until their profiles contain current, source-backed security configuration guidance. ## Related handbook guidance * [What is AI Security?](/start-here/what-is-ai-security) * [How to Use This Handbook](/start-here/how-to-use-this-handbook) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) * [Glossary](/start-here/glossary) # What is AI Security? A plain-language scope for AI security in this handbook: helping security practitioners roll out AI tools, agents, connectors, and data access safely across the business. *Last reviewed: August 18, 2026* {% hint style="info" %} This handbook is about securely rolling out AI to the enterprise. It is written for security practitioners who need to help the business use AI tools, agents, connectors, and data safely. {% endhint %} ## Scope of this handbook AI security, in this handbook, means the controls and operating practices needed when employees and business teams use AI at work. The goal is practical: help a security practitioner decide which AI products can be used, by whom, with what data, through which tools, under what approvals, and with what evidence left behind. That includes workforce chat, coding agents, browser and desktop agents, hosted agents, API applications, low-code agent builders, connectors, MCP servers, plugins, skills, hooks, local files, generated artifacts, scheduled tasks, and downstream SaaS actions. It does not mean a general guide to building foundation models, training models, or red-teaming your own model architecture. Those disciplines matter, but they are not the main problem this handbook is solving. ## In scope and out of scope | Area | In scope for this handbook | Out of scope for this handbook | | --------------------- | -------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | Enterprise AI rollout | How to approve, configure, monitor, and govern AI tools used by employees and teams. | Broad AI strategy, productivity coaching, or vendor marketing comparisons. | | Workforce AI tools | ChatGPT Work, ChatGPT Codex, Claude Cowork, Claude Code, Claude Tag, connectors, apps, and agent workflows. | Consumer-only guidance with no enterprise controls or evidence path. | | Data protection | What data can enter AI tools, where it can go, how it is retained, and how to prove controls work. | General privacy theory without a deployment decision attached. | | Runtime control | Sandboxes, browser and desktop access, filesystem boundaries, approvals, egress, autonomy, and scheduled work. | Low-level model internals or accelerator security. | | Extensibility | MCP servers, plugins, skills, hooks, connectors, agent builders, and other ways users extend AI systems. | Generic software supply-chain guidance that never touches AI execution paths. | | Threats and testing | Prompt injection, tool poisoning, exfiltration, confused-deputy paths, and abuse-case testing of deployed workflows. | Red-teaming a frontier model itself, model eval research, or adversarial ML research as a standalone discipline. | | Evidence | Audit logs, OTel, endpoint telemetry, source-system logs, SIEM routing, and investigation paths. | Logging theory that cannot answer what a user or agent actually did. | ## The practitioner question A security team should be able to answer this before expanding access: > Can this group use this AI capability for this business workflow without exposing unacceptable data, granting uncontrolled action authority, or losing the evidence needed to investigate what happened? If the answer is not clear, narrow the rollout. Reduce the data class, remove write actions, disable high-risk connectors, tighten sandboxing, require approvals, or run a smaller pilot until the evidence is good enough. ## Why AI security is different from SaaS security Traditional SaaS security starts with accounts, roles, app permissions, and logs. Those controls still matter. AI adds new paths through prompts, retrieved context, model outputs, tool calls, generated files, browser sessions, local code execution, MCP servers, scheduled tasks, and agent actions. A normal SaaS review might ask whether a user can access a file. An AI security review also asks whether an agent can read that file, summarize it into another system, call a tool with its contents, write a derived artifact, publish a link, or continue the task later without the user watching. That is why the handbook focuses on the full chain: * **Identity:** who is using the product, and which human or non-human identity is taking the action. * **Data:** what the AI can read, retrieve, store, transform, and share. * **Tools:** which connectors, MCP servers, apps, plugins, skills, hooks, and APIs can be called. * **Runtime:** where the work runs, what it can execute, which files it can touch, and where network traffic can go. * **Authority:** what requires approval, what can happen automatically, and what can be reversed. * **Evidence:** which records prove what happened, and where the gaps are. ## How to assess a workflow Assess the workflow, not only the product name. One business task can start in chat, move into a desktop app, touch local files, call a connector, launch a hosted task, and write to a SaaS system. Use this order: 1. **Name the business workflow.** Example: employee research, sales account prep, code changes, finance analysis, support drafting, contract review, or incident triage. 2. **Map the surface.** Identify whether it uses workforce chat, a coding agent, browser or desktop control, hosted agents, API applications, or low-code builders. 3. **Classify the data.** Record whether the workflow can touch public, internal, confidential, regulated, customer, employee, source code, or secrets data. 4. **List the actions.** Separate read-only work from writes, sends, publishes, deletes, purchases, production changes, and unattended tasks. 5. **Review extensions.** Inventory connectors, MCP servers, plugins, skills, hooks, apps, tools, memory, and knowledge sources. 6. **Set the boundary.** Configure identity, roles, sandboxing, egress, approvals, DLP, retention, and connector scope for the actual risk. 7. **Prove the evidence.** Run a canary test and confirm the activity appears in provider logs, OTel where available, endpoint logs, source-system logs, and the SIEM path. ## Where to start For a new enterprise rollout, start with a small set of business use cases and a controlled user group. Do not enable every AI capability at once. A crisp starting baseline is: * Managed identity and lifecycle controls for every approved AI product. * Separate groups for normal users, builders, admins, coding-agent users, connector exceptions, and high-risk pilots. * Approved data classes by product and workflow. * Default-deny or tightly scoped connector and MCP access. * Sandbox and approval controls for local code, file, browser, desktop, and agent execution. * A retention and training-data decision before sensitive data is allowed. * OTel, audit, endpoint, and source-system evidence tested before expansion. * An incident path that can revoke users, tasks, connectors, agent identities, credentials, and published artifacts. The useful output is not a policy document alone. It is a working control plan with owners, settings, tests, exceptions, evidence, and a review date. ## How this handbook is organized * **Identity & Access:** managed sign-in, provisioning, roles, tenant restrictions, agent identities, credentials, and approval authority. * **Supply Chain & Extensibility:** connectors, MCP servers, plugins, skills, hooks, tools, dependencies, and agent-builder inputs. * **Runtime, Sandbox & Autonomy:** isolation, filesystem access, browser and desktop control, egress, approvals, scheduled tasks, and hosted execution. * **Data Protection & Residency:** data classes, DLP, retention, training use, derived data, cross-app flows, secrets, and residency. * **Threats & Adversarial:** prompt injection, exfiltration, tool poisoning, supply-chain attacks, abuse-case testing, threat modeling, and incident response for deployed workflows. * **Observability, Audit & Evidence:** audit gaps, compliance APIs, OpenTelemetry, SIEM routing, usage analytics, investigations, and control review. * **Rollout & Operations:** pilots, readiness gates, security checklists, vendor-neutral control mapping, exceptions, and ongoing governance. ## Frequently asked questions ### Is this handbook for model builders? Not primarily. Model builders may find useful control ideas here, especially around tools, data, telemetry, and incident response. The core audience is the security team responsible for enterprise use of AI tools and agents. ### Does this cover AI red teaming? Only where testing supports a deployed enterprise workflow. The handbook covers prompt-injection tests, exfiltration tests, abuse cases, and control validation for products employees use. It does not try to be a full guide to red-teaming a foundation model. ### What is the first question a practitioner should ask? Ask what the AI can access and what it can do. If the workflow can reach sensitive data or take meaningful action, raise the control posture before expanding access. ### What does a good rollout decision look like? A good decision names the approved users, allowed data, enabled tools, action limits, required approvals, evidence sources, owner, review date, and rollback path. If any of those are missing, the rollout is still a pilot. ## Related handbook guidance * [AI Security Handbook](/) * [How to Use This Handbook](/start-here/how-to-use-this-handbook) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) * [7.1 Roll out by risk: the phased plan](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan) * [Glossary](/start-here/glossary) # How to Use This Handbook A guide for security practitioners on navigating the AI Sec Handbook - how articles are structured, what the depth labels mean, and where to start based on your deployment model. *Last reviewed: August 18, 2026* {% hint style="info" %} Use this handbook in two ways: start with the security task in front of you, or open the relevant vendor page when you already know the product. From there, use the control matrix and checklist to turn guidance into owned, testable controls. {% endhint %} Use 7.4 The vendor-neutral control matrix as the source of truth for deployment models and control applicability. What is AI Security? explains the access, execution, autonomy, and evidence dimensions that change risk. ## 1. Start with the task in front of you | Situation | Start here | Then do this | | --------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Rolling out an AI product | 7. Rollout & Operations | Confirm identity, data protection, runtime boundaries, and evidence paths before widening access. | | Assessing an existing deployment | 7.4 The vendor-neutral control matrix and 7.3 The security team checklist | Use 6.1 The audit gap, to test whether the expected evidence actually exists. | | Approving a connector, MCP server, skill, or plugin | 2. Supply Chain & Extensibility | Apply 2.7 The supply-chain review workflow before enablement. | | Enabling a tool or workflow that can take actions | 3. Runtime, Sandbox & Autonomy | Complete 5.7 Threat modeling AI systems and article 5.1 prompt-injection testing in 5. Threats & Adversarial. | | Handling sensitive or regulated data | 4. Data Protection & Residency | Check the applicable obligations in [Governance & Frameworks](/reference/governance-and-frameworks). | | Investigating an AI security incident | 5. Threats & Adversarial | Start with 5.6 Incident response for AI systems, then use 6.6 Evidence by surface and investigation paths in 6. Observability, Audit & Evidence. | | Reviewing a specific AI product | Open **By AI Vendor** in the sidebar | Use the vendor page to find its relevant handbook controls and product-specific gaps. | ## 2. Turn guidance into evidence A control is not complete because a setting exists. Use the same workflow for each control: 1. **Identify** the applicable control in the control matrix. 2. **Assign** a named owner for implementation and review. 3. **Configure and test** the control using the relevant handbook article. 4. **Record evidence**, including the configuration, test result, log source, and any approved exception. 5. **Reassess** after a significant product update, a newly enabled capability, or an incident. ## 3. Use vendor pages for implementation detail The handbook articles define the required security outcome and explain why it matters. The **By AI Vendor** pages show where a vendor exposes the relevant settings, which products or plans they cover, and where gaps remain. Start with a vendor page when you already know the product, then return to the handbook articles for the cross-vendor control standard. ## Related handbook guidance * [AI Security Handbook](/) * [Security Team Checklist](/start-here/security-team-checklist) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) * [Governance & Frameworks](/reference/governance-and-frameworks) * [Glossary](/start-here/glossary) # Security Team Checklist A practical checklist for security teams deploying AI tools across identity, data, runtime, supply chain, observability, and rollout. ## Security Team Checklist *Last reviewed: August 18, 2026* {% hint style="info" %} Work through this checklist before widening an AI rollout. Each item links to the handbook article with implementation guidance. Record the owner, evidence, last test 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). {% endhint %} ### Identity * [ ] Managed user surfaces use SSO where the provider supports it; unsupported surfaces and login exceptions are documented. ([1.1](/handbook/1.-identity-and-access/1.1-sso-and-scim-for-ai-platforms)) * [ ] MFA, conditional access, session lifetime, reauthentication, revocation, device-loss, and emergency-access behavior are defined and tested for every authentication path. ([1.1](/handbook/1.-identity-and-access/1.1-sso-and-scim-for-ai-platforms)) * [ ] SCIM or a documented joiner, mover, and leaver process covers every approved AI surface. ([1.1](/handbook/1.-identity-and-access/1.1-sso-and-scim-for-ai-platforms)) * [ ] Roles and groups restrict high-risk capabilities, not only access to the platform. ([1.2](/handbook/1.-identity-and-access/1.2-rbac-across-ai-platforms)) * [ ] Personal-account use is blocked where tenant restrictions are supported; other surfaces have a tested detection and remediation path. ([1.3](/handbook/1.-identity-and-access/1.3-tenant-restrictions-blocking-personal-accounts)) * [ ] Shadow accounts, unmanaged organizations, and accounts on verified domains are discovered and remediated. ([1.4](/handbook/1.-identity-and-access/1.4-domain-claiming-bringing-shadow-accounts-into-enterprise)) * [ ] Agents and other non-human identities have dedicated credentials, named owners, and revocation paths. ([1.5](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity)) * [ ] API keys and service accounts are inventoried, scoped, stored, and rotated. ([1.6](/handbook/1.-identity-and-access/1.6-api-keys-and-service-accounts-governance)) * [ ] Human approval is required before autonomous systems take actions beyond the approved baseline. ([1.7](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies)) ### Supply Chain & Extensibility * [ ] Connectors and apps are reviewed, approved, and scoped to the minimum permissions. ([2.1](/handbook/2.-supply-chain-and-extensibility/2.1-connectors-and-apps-the-integration-backbone)) * [ ] Local and remote MCP servers are inventoried, authenticated where applicable, and assessed before use. ([2.2](/handbook/2.-supply-chain-and-extensibility/2.2-mcp-servers-securing-the-protocol)) * [ ] An MCP gateway or equivalent managed restrictions enforce the approved server and tool policy. ([2.3](/handbook/2.-supply-chain-and-extensibility/2.3-mcp-gateways-and-allowlisting)) * [ ] Skills and instruction bundles are reviewed; creation and sharing are restricted by role. ([2.4](/handbook/2.-supply-chain-and-extensibility/2.4-analyzing-skills-for-risk)) * [ ] Plugins, marketplaces, and extensions are reviewed at intake and after material updates. ([2.5](/handbook/2.-supply-chain-and-extensibility/2.5-plugins-and-marketplaces)) * [ ] Hooks and lifecycle scripts are inventoried; untrusted or unowned scripts are blocked. ([2.6](/handbook/2.-supply-chain-and-extensibility/2.6-ai-hooks-inference-controls-and-lifecycle-automation)) * [ ] The agent bill of materials records every model, SDK, connector, MCP server, skill, plugin, hook, package, image, template, knowledge source, and tool with its owner, source, version, permissions, and review trigger. ([2.7](/handbook/2.-supply-chain-and-extensibility/2.7-the-supply-chain-review-workflow)) * [ ] The extension review record names the owner, version, scopes, data classes, evidence, and next review date. ([2.7](/handbook/2.-supply-chain-and-extensibility/2.7-the-supply-chain-review-workflow)) * [ ] Signed packages, trusted distribution paths, version pinning, and update behavior are verified where supported. ([2.8](/handbook/2.-supply-chain-and-extensibility/2.8-signing-and-packaging)) * [ ] SaaS agent builders are treated as supply chain, including templates, connections, publishing, and sharing. ([2.9](/handbook/2.-supply-chain-and-extensibility/2.9-saas-agent-building-supply-chain)) * [ ] Hosted-agent frameworks, SDKs, tools, models, and other dependencies have owners and an update-review process. ([2.10](/handbook/2.-supply-chain-and-extensibility/2.10-hosted-agent-framework-dependencies)) ### Runtime, Sandbox & Autonomy * [ ] Each execution surface has a documented isolation model and centrally enforced baseline where supported. ([3.1](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox)) * [ ] Approval policies default to the least privilege needed and protect destructive or high-impact actions. ([3.2](/handbook/3.-runtime-sandbox-and-autonomy/3.2-approval-policies-and-least-privilege-autonomy)) * [ ] Agent network egress is restricted and tested; allowed destinations are owned and reviewed. ([3.3](/handbook/3.-runtime-sandbox-and-autonomy/3.3-network-egress-control)) * [ ] Browser and internet access are restricted by cohort and sensitive internal sites are protected. ([3.4](/handbook/3.-runtime-sandbox-and-autonomy/3.4-internet-access-and-browser-automation)) * [ ] Computer-use and desktop-control capabilities are disabled unless required and explicitly approved. ([3.5](/handbook/3.-runtime-sandbox-and-autonomy/3.5-computer-use-desktop-control-risks)) * [ ] Scheduled and background tasks use minimum permissions, bounded runtime, and defined stop conditions. ([3.6](/handbook/3.-runtime-sandbox-and-autonomy/3.6-scheduled-and-background-tasks)) * [ ] Remote dispatch, mobile triggers, remote sessions, and SSH paths are authenticated, attributable, and revocable. ([3.7](/handbook/3.-runtime-sandbox-and-autonomy/3.7-remote-access-dispatch-and-ssh)) * [ ] File access is limited to approved roots; home directories, secrets, and cloud-synced folders are excluded unless needed. ([3.8](/handbook/3.-runtime-sandbox-and-autonomy/3.8-file-and-filesystem-access-controls)) * [ ] Hosted triggers are authenticated and replay-resistant; control-plane policy cannot be changed by the agent runtime. ([3.9](/handbook/3.-runtime-sandbox-and-autonomy/3.9-central-hosted-agent-runtime-hardening)) * [ ] Hosted agents use task-scoped credentials, tenant and task isolation, egress controls, spend and rate limits, action limits, and tested stop and recovery controls. ([3.9](/handbook/3.-runtime-sandbox-and-autonomy/3.9-central-hosted-agent-runtime-hardening)) ([3.9](/handbook/3.-runtime-sandbox-and-autonomy/3.9-central-hosted-agent-runtime-hardening)) ### Data Protection & Residency * [ ] Every approved AI surface has a tested DLP enforcement or evidence path; unsupported paths and gaps are documented. ([4.1](/handbook/4.-data-protection-and-residency/4.1-dlp-for-genai)) * [ ] Data classes are mapped to allowed tools, actions, connectors, and deployment models. ([4.2](/handbook/4.-data-protection-and-residency/4.2-data-classification-for-ai-prompts-and-outputs)) * [ ] Processing, storage, support, log, and subprocessor regions are verified for each surface. ([4.3](/handbook/4.-data-protection-and-residency/4.3-data-residency-and-regional-inference)) * [ ] Retention is configured and tested; Zero Data Retention limitations are understood before regulated use. ([4.4](/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention)) * [ ] Training and data-use terms are confirmed for each product, plan, and authentication path. ([4.5](/handbook/4.-data-protection-and-residency/4.5-training-opt-out-and-data-usage)) * [ ] Knowledge bases, embeddings, vector stores, memory, fine-tuning and evaluation data, caches, backups, traces, and exports have owners, retention, deletion, access, and regional controls. ([4.4](/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention)) * [ ] Cross-app flows, generated artifacts, publishing, and sharing are included in the data-flow review. ([4.6](/handbook/4.-data-protection-and-residency/4.6-cross-app-data-flow-and-live-artifacts)) * [ ] Secrets and credentials are excluded from prompts, tool parameters, logs, and agent configuration. ([4.7](/handbook/4.-data-protection-and-residency/4.7-secrets-and-credential-hygiene-in-prompts-and-tools)) ### Threats & Incident Response * [ ] Prompt-injection controls are tested against untrusted content and connected tools. ([5.1](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk)) * [ ] Exfiltration paths through tools, connectors, files, URLs, and generated artifacts have been tested. ([5.2](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors)) * [ ] Vulnerabilities and supply-chain advisories for enabled AI components are tracked and remediated. ([5.3](/handbook/5.-threats-and-adversarial/5.3-supply-chain-attacks-and-notable-cves)) * [ ] Tool and memory poisoning, spoofed results, identity confusion, confused deputy, SSRF, cross-tenant access, replay, approval races, and denial-of-wallet are covered in design and testing. ([5.4](/handbook/5.-threats-and-adversarial/5.4-agent-specific-threats-tool-poisoning-and-confused-deputy)) ([5.4](/handbook/5.-threats-and-adversarial/5.4-agent-specific-threats-tool-poisoning-and-confused-deputy)) * [ ] High-risk workflows are red-teamed before expansion and after material changes. ([5.5](/handbook/5.-threats-and-adversarial/5.5-red-teaming-ai-systems)) * [ ] The incident runbook covers revoking sessions, connectors, credentials, tasks, and published artifacts, and has been exercised. ([5.6](/handbook/5.-threats-and-adversarial/5.6-incident-response-for-ai-system)) * [ ] Each material AI workflow has a current threat model covering data, identity, tools, runtime, and trust boundaries. ([5.7](/handbook/5.-threats-and-adversarial/5.7-threat-modeling-ai-systems)) ### Observability, Audit & Evidence * [ ] Known audit gaps are documented per product, authentication path, and execution surface. ([6.1](/handbook/6.-observability-audit-and-evidence/6.1-the-audit-gap-what-you-can-and-cant-see)) * [ ] Agent telemetry uses a versioned schema and captures identity, surface, runtime, model, policy, tool, approval, target, result, error, cost, and correlation fields. ([6.2](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility)) * [ ] Delivery latency, completeness, source health, clock drift, schema drift, sampling, and retention are measured and reconciled. ([6.2](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility)) * [ ] All available compliance and audit sources are collected; coverage and exclusions are tested and recorded. ([6.3](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform)) * [ ] Usage and spend analytics are reviewed for adoption shifts, anomalies, and unowned activity. ([6.4](/handbook/6.-observability-audit-and-evidence/6.4-analytics-and-usage-apis)) * [ ] SIEM detections are selected from the approved threat scenarios, tested, and linked to response runbooks. ([6.5](/handbook/6.-observability-audit-and-evidence/6.5-routing-ai-telemetry-to-your-siem)) * [ ] Every enabled surface has a tested evidence path for the investigation questions it must answer. ([6.6](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths)) * [ ] Controls are recertified at least quarterly and after incidents, major vendor changes, new data classes, or ownership changes. ([6.7](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence)) ### Rollout & Operations * [ ] The rollout plan defines the approved scope, risk tier, owner, pilot cohort, training, support, and expansion gates. ([7.1](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan)) * [ ] A tested exit plan covers stopping work, revoking access, ownership transfer, exports, deletion, artifacts, schedules, and billing. ([7.1](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan)) ([7.1](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan)) * [ ] Pilot success metrics include security-control tests and clear go, hold, and stop criteria. ([7.2](/handbook/7.-rollout-and-operations/7.2-pilot-design-and-success-metrics)) * [ ] Every checklist decision has evidence, a named owner, a last-tested date, and a time-bounded exception where needed. ([7.3](/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist)) * [ ] Required controls are selected by deployment model, data class, and risk posture. ([7.4](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix)) ## Related handbook guidance * [AI Security Handbook](/) * [7.3 The security team checklist](/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) * [7.2 Pilot design and success metrics](/handbook/7.-rollout-and-operations/7.2-pilot-design-and-success-metrics) * [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence) # Glossary Plain-language definitions of every technical term used across the AI Sec Handbook, from AI agent and MCP to vibe coding and Zero Data Retention. ## Glossary *Last reviewed: August 18, 2026* **In short:** Plain-language definitions of every technical term used across the AI Sec Handbook, from AI agent and MCP to vibe coding and Zero Data Retention. #### AI acceptable use policy (AUP) An AI acceptable use policy defines which AI tools employees may use, what data is allowed into them, and how personal accounts, connectors, and agents are handled. #### AI agent / Agentic AI An AI agent is a system that plans and takes actions through tools with varying autonomy, rather than only returning text. Agentic AI is the broader category of these tool-using systems. #### AI data security AI data security is the practice of detecting and controlling sensitive data as it moves into, through, and out of AI tools, prompts, and agent actions, where traditional data controls have no visibility. #### AI gateway An AI gateway is a control point that proxies model traffic to apply policy, logging, rate and spend limits, and routing. #### AI governance AI governance is the set of policies, controls, and monitoring an organisation uses to decide which AI tools and data uses are allowed, and to enforce those decisions across every AI surface. #### AI surface An AI surface is any point where a person or agent sends data to an AI model, including web chat, desktop apps, IDE extensions, browser agents, and inference APIs. #### Agentic AI security Agentic AI security is the discipline of governing AI agents that take autonomous actions — covering identity, tool access, approval policies, sandbox containment, and audit — rather than only governing prompt-level data exposure. #### Agent bill of materials An agent bill of materials is a structured inventory of every tool, connector, MCP server, skill, and data source an AI agent can access, used to assess and govern its attack surface before deployment. #### App An app is a packaged capability or integration surfaced inside an AI platform, often built on connectors. #### Artifact (live) A live artifact is a persistent, interactive output that makes authenticated connector calls each time it is opened. #### Browser agent A browser agent is an AI that operates inside a user's signed-in browser session, able to read page content and take actions — making every visited page a potential prompt injection source. #### Claude Code Claude Code is Anthropic's agentic coding tool that reads and writes files, runs commands, and connects to MCP servers, giving it developer-level access to the local environment rather than only answering questions. #### Coding agent A coding agent is an AI system that generates, edits, and executes code autonomously inside an IDE, terminal, or CI pipeline, with direct access to files, credentials, and system resources. #### Compliance API A compliance API is a vendor API that exposes audit logs, chat content, and file activity for investigations and retention requirements. #### Computer Use Computer Use is a mode where an AI controls the desktop directly through screenshots, clicks, and typing, often outside the sandbox and without per-action user approval. #### Confused deputy A confused deputy is an over-privileged agent that is tricked into misusing its legitimate access on an attacker's behalf. #### Connector A connector is a pre-built integration that gives an AI tool authenticated access to an external service such as Slack, Google Drive, or Salesforce. #### Data loss prevention (DLP), AI era Data loss prevention is the set of controls that stop sensitive data from leaving an organisation. In the AI era, the exit point is a prompt or tool call rather than email or USB, which classic DLP does not inspect. #### Destructive action (AI) A destructive action is an agent-initiated operation that cannot be undone — including file deletion, credential exposure, sending messages, making purchases, or modifying production systems — executed without explicit per-step user approval. #### Dispatch Dispatch is a mobile-to-desktop bridge that triggers agent tasks on a user's desktop from their phone, creating a remote execution surface that inherits the desktop's full tool and file access. #### Domain claiming Domain claiming is the process of migrating personal accounts on a verified domain into a managed enterprise workspace, bringing shadow accounts under governance. #### Hook A hook is a script that runs automatically at defined points in an AI session, before the user sees a trust dialog, making it a code execution and prompt injection surface. #### IDE extension An IDE extension is a plugin that runs inside a code editor such as VS Code or JetBrains, operating outside the browser and invisible to network-based and browser-based AI governance controls. #### Indirect prompt injection Indirect prompt injection is an attack where hidden instructions embedded in content the AI reads — a web page, document, MCP response, or tool output — hijack the model's behaviour without the user's knowledge. #### MCP (Model Context Protocol) MCP is an open protocol that standardizes how AI clients connect to tools and data through MCP servers, running locally over stdio or remotely over HTTP/SSE. #### MCP gateway An MCP gateway is a broker that centralizes, allowlists, and mediates an organization's access to MCP servers, preventing users from adding unauthorized servers. #### MCP read vs write permissions MCP read permissions allow an AI agent to retrieve data from a connected system. Write permissions allow the agent to create, modify, or delete data. Write-enabled MCP connections carry significantly higher risk because agent actions become irreversible. #### OpenTelemetry (OTel) OpenTelemetry is an open standard for emitting traces, metrics, and logs, used to route AI runtime events including prompt activity, tool calls, and errors into a SIEM or observability platform. #### Personal AI account A personal AI account is an account created by an employee using their personal email on an AI platform such as Claude.ai or ChatGPT, outside enterprise governance and invisible to security teams without browser or endpoint controls. #### Plugin A plugin is a bundle that can contain skills, connectors, sub-agents, and hooks, distributed through a marketplace or repository and reviewed like a software dependency. #### Prompt injection Prompt injection is an attack where hidden instructions in content or tool output hijack a model's behavior, either directly through user input or indirectly through retrieved content. #### Prompt-level DLP Prompt-level DLP is data loss prevention applied at the moment a user or agent submits a prompt to an AI model, inspecting the content before it leaves the organization rather than monitoring network traffic after the fact. #### RBAC (role-based access control) RBAC is a model that assigns capability permissions to roles or groups rather than to individuals, used across AI platforms to control who can access which tools, connectors, and administrative functions. #### Remote MCP server A remote MCP server is an MCP server accessed over HTTP or SSE rather than locally via stdio, typically requiring OAuth or token-based authentication and carrying network-level attack surface in addition to the tool access it grants. #### Sandbox A sandbox is an isolated execution environment, often a virtual machine, that constrains what code or agents can touch — limiting filesystem access, network egress, and system calls. #### SCIM SCIM is a standard for automated user and group provisioning from an identity provider, used to keep AI platform access in sync with joiners, movers, and leavers without manual deprovisioning. #### Shadow AI Shadow AI is AI tools or accounts used by employees outside a security team's visibility and controls, typically personal accounts on managed devices or AI features embedded in approved SaaS tools. #### Skill A skill is an instruction file, such as SKILL.md, that an agent loads on demand when a task matches its description. It may bundle scripts and resources, making it executable trust rather than passive documentation. #### Small language model (SLM) A small language model is a compact model that can run locally or in-tenant for detection and classification tasks — such as identifying sensitive data in prompts — without sending data to a third-party model provider. #### Stdio (Local) MCP server A stdio MCP server is an MCP server that runs locally on the user's machine over standard input and output, with full access to the local filesystem and environment by default and no network boundary between it and the endpoint. #### Supply chain attack (AI) A supply chain attack targeting AI systems uses malicious MCP configurations, skill files, plugin packages, or repository content to execute code or inject instructions when the artefact is opened or loaded — often without any user interaction beyond opening a project. #### Tenant restriction A tenant restriction is a network control, such as an org-id HTTP header injected by a proxy, that blocks use of non-managed accounts on corporate networks or managed devices. #### Tool poisoning Tool poisoning is the use of malicious tool metadata or descriptions in an MCP server or plugin to manipulate an agent into unsafe tool use, privilege escalation, or data exfiltration. #### Vibe coding Vibe coding is the practice of building software by describing intent to an AI coding tool and accepting its generated output, often with limited review of what the code actually does or what data it accesses. #### Workload identity federation Workload identity federation is a method of granting AI agents and automated workloads scoped, short-lived credentials from an identity provider rather than static API keys, reducing the blast radius of a compromised agent. #### API application An API application is software that calls a model or agent API under application-controlled identity, authorization, logging, and runtime policy. The application owner is responsible for the full loop, including tools, data, approvals, and downstream actions. #### Browser or desktop agent A browser or desktop agent can read or act through a browser session, local application, clipboard, filesystem, or operating-system interface. Its risk depends on the signed-in user, local permissions, protected sites, and the evidence available from the endpoint and target systems. #### Data poisoning Data poisoning is the deliberate or accidental introduction of misleading, malicious, or policy-breaking content into training, fine-tuning, evaluation, retrieval, memory, or knowledge-base data so later model or agent behavior is altered. #### Denial of wallet Denial of wallet is an attack or failure mode that causes excessive model, tool, infrastructure, or third-party usage costs through repeated, recursive, or unusually expensive work. #### Derived AI data Derived AI data is information created from source content, including embeddings, summaries, indexes, caches, traces, labels, evaluations, and generated artifacts. It may remain sensitive even when it does not reproduce the original record verbatim. #### Hosted agent A hosted agent is an agent that executes in a vendor-managed or centrally managed runtime, often asynchronously. Security review must cover session state, isolation, credentials, egress, limits, termination, retention, and hosted evidence. #### Low-code agent builder A low-code agent builder is a managed platform that lets users assemble and publish agents from templates, instructions, knowledge sources, connectors, and actions. Governance must cover who can build, connect, collaborate, publish, transfer, and delete agents. #### Memory poisoning Memory poisoning is the insertion of malicious or misleading information into persistent agent memory so it influences later tasks, users, or automated runs after the original interaction ends. #### Retrieval-augmented generation (RAG) Retrieval-augmented generation is a pattern where an AI system retrieves documents or records from a knowledge source and supplies them to a model as context. The retrieval index, permissions, source freshness, and retrieved content are part of the security boundary. #### Telemetry completeness objective A telemetry completeness objective defines which expected AI events must arrive, how quickly they must arrive, and how the team proves that events were not silently dropped. It turns logging from a configuration claim into a measured control. #### Tool-result spoofing Tool-result spoofing is the manipulation or fabrication of content returned by a tool, connector, browser, agent, or model so the receiving agent makes an unsafe decision or action. #### Vector store A vector store holds embeddings and metadata used for semantic search and RAG. It can expose sensitive relationships, preserve deleted content indirectly, and bypass source-system permissions if access and deletion are not synchronized. #### Workforce chat Workforce chat is an employee-facing AI conversation surface used for research, drafting, analysis, and questions. Connectors, files, memory, browser access, and action capabilities can raise it beyond a read-only chat risk profile. #### Zero Data Retention (ZDR) Zero Data Retention is a contractual mode in which a provider does not retain prompt or response data beyond the duration of the API call, used to satisfy data residency and confidentiality requirements. ## Related handbook guidance * [AI Security Handbook](/) * [What is AI Security?](/start-here/what-is-ai-security) * [1. Identity & Access](/handbook/1.-identity-and-access) * [2. Supply Chain & Extensibility](/handbook/2.-supply-chain-and-extensibility) * [5. Threats & Adversarial](/handbook/5.-threats-and-adversarial) # Anthropic Security configuration, governance controls, and risk guidance for Claude Cowork, Claude Code, and Claude Tag. {% hint style="info" %} This section focuses on the Anthropic products that create the clearest workforce and agent security decisions: Claude Cowork, Claude Code, and Claude Tag. {% endhint %} ## Products covered in this handbook

:briefcase:

Claude CoworkFocus first on RBAC, OTel, prompt injection, browser scope, plugins, MCP, scheduled tasks, and the local VM boundary. Related: OTel and sandboxing.Claude Cowork

:code:

Claude CodeFocus first on repository scope, shell and filesystem access, MCP allowlists, managed settings, hooks, approvals, and sandbox mode. Related: hooks and sandboxing.Claude Code

:hashtag:

Claude TagFocus first on Slack scope, service accounts, Access bundles, retained memory, channel permissions, Agent Proxy credentials, and downstream evidence.Claude Tag
## Security considerations specific to Anthropic **Cowork is not a chatbot.** Treat it as an agentic work surface that can read and write files, run code, browse with user context, invoke MCP and plugins, and continue unattended work. Approve local, remote, browser, MCP, plugin, and Computer Use paths separately. **OTel is the practical Cowork evidence path today.** Cowork activity is not currently covered by Anthropic audit logs, the Compliance API, or data exports. Route OpenTelemetry to a protected collector and SIEM, then test whether the fields needed for investigations arrive with the right redaction. **Claude Code needs code-review-grade governance.** Repository instructions, hooks, MCP servers, shell commands, local credentials, and generated changes can all influence outcomes. Keep unmanaged hooks and broad filesystem access out of ordinary use. **Claude Tag is a Slack agent with its own identity and memory model.** Scope workspace, channel, repository, service-account, credential, and spend access. Preserve Slack threads, Agent Proxy evidence, downstream system logs, and revocation paths before broad rollout. ## Current provider documentation * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [Claude Code overview](https://code.claude.com/docs/en/overview) * [What is Claude Tag?](https://support.claude.com/en/articles/15594475-what-is-claude-tag) * [Monitor Cowork with OpenTelemetry](https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry) *Last reviewed: August 18, 2026* ## Applicable Harmonic guidance * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## Related handbook guidance * [AI Security Handbook](/) * [Claude Cowork](/by-ai-vendor/anthropic/claude-cowork) * [Claude Code](/by-ai-vendor/anthropic/claude-code) * [Claude Tag](/by-ai-vendor/anthropic/claude-tag) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) # Claude Cowork Security guidance for Claude Cowork, including workspace access, connectors, browser use, approvals, data handling, and agent activity evidence. {% hint style="warning" %} **In short:** Claude Cowork is an agentic work environment that can read and write files, run code, use connected tools, browse, and continue long-running tasks. Its local VM is an important boundary, but browser control and Computer Use can act outside that VM. Cowork activity is not currently covered by Anthropic audit logs, the Compliance API, or data exports. {% endhint %} ## What to focus on first

:user-shield:

Control who can use CoworkTreat the org-wide Cowork toggle, RBAC, group assignment, remote sessions, and trusted-device rules as the rollout gate.1.2 RBAC across AI platforms

:box:

Test the sandbox boundaryThe local VM limits ordinary file and code operations, but browser control, Computer Use, MCP servers, plugins, and remote sessions can expand the real boundary.3.1 What Even is an AI Sandbox?

:plug:

Limit tools before rolloutCowork can use connectors, MCP, extensions, skills, hooks, browser bridges, and shared credentials. Review each one like a supply-chain dependency.2.1 Connectors and apps: the integration backbone

:triangle-exclamation:

Assume prompt injectionFiles, web pages, email, tool output, tickets, and docs can all carry instructions that try to steer the agent toward unsafe actions.5.1 Prompt injection: the connective risk

:route:

Collect OTel with cautionOpenTelemetry is the best current Cowork visibility, but it is not a complete compliance audit trail. Correlate it with source-system logs.6.2 OpenTelemetry for AI runtime visibility

:clock:

Constrain unattended workScheduled tasks and persistent approvals need stricter folder, network, tool, and external-write boundaries than supervised sessions.3.6 Scheduled and background tasks
## What is Claude Cowork? Claude Cowork lets users delegate multi-step knowledge-work tasks to Claude. It can create documents and analyses, work across local folders, run shell commands and code, use plugins and MCP tools, browse the web, and schedule or remotely continue work. Cowork is available through Claude Desktop, with remote sessions accessible from web and mobile. A remote session does not automatically reach the user's computer. Local file or browser access is bridged through an online Claude Desktop host and is limited to what that host exposes. ## Where Claude Cowork runs and what it can access Cowork has two main execution paths: * **Local sessions:** The agent loop runs on the endpoint. Code executes in a local Linux VM with mounted-folder, syscall, session, and network controls. File access is limited to folders the user shares. * **Remote sessions:** Work runs in an isolated, temporary Anthropic-hosted environment. It cannot reach private networks or the user's device by default. Access to local folders or a browser is mediated by Claude Desktop while that device is online. Connectors use separately stored tokens. Anthropic states that connector tokens are not placed inside the Cowork sandbox. Local MCP servers, extensions, and browser bridges can still expand the reachable systems substantially. ## Claude Cowork security boundary The VM protects the host from ordinary file and code operations, but it is not a complete boundary for every tool. * Claude in Chrome can read pages, click, type, download, and use authenticated browser sessions. * Computer Use interacts with the real desktop and applications, outside the VM. * MCP servers and plugins can expose external systems, credentials, scripts, and hooks. * Documents, web pages, email, and tool output can contain prompt injection. * Endpoint detection tools cannot inspect activity inside the local VM, and cannot inspect remote sessions running on Anthropic infrastructure. Cowork is not generally Zero Data Retention eligible. Confirm the exact data terms for the deployment path, including any third-party inference provider. ## How to configure Claude Cowork securely ### Control availability * Use the organization-wide Cowork toggle as the main enablement switch. * On Enterprise, use custom roles and groups to limit Cowork to approved users. * Control remote sessions separately from local desktop Cowork. * Require trusted-device enrollment and recent sign-in for remote sessions where supported. * Disable the ability to act without asking when the workflow does not justify persistent approval. ### Limit files, tools, and network access * Use **allowedWorkspaceFolders** to restrict folders that can be mounted. * Disable local MCP with **isLocalDevMcpEnabled** when it is not needed. * Disable desktop extensions with **isDesktopExtensionEnabled** or use the extension allowlist. * Apply a restrictive network-access policy and allow only required destinations. * Keep Claude in Chrome disabled or on a short site allowlist during pilot rollout. * Treat plugins as executable supply-chain dependencies. Review their skills, connectors, agents, and hooks. * Do not grant broad shared credentials to tools that every Cowork user can invoke. ### Approvals and monitoring * Require approval for deletion, external writes, sharing, credential use, and other high-impact actions. * Configure Cowork OpenTelemetry for Team or Enterprise deployments that require operational visibility. * Route telemetry to an approved collector and SIEM. * Redact prompt text, email addresses, file paths, shell commands, tool parameters, and other sensitive fields before long-term storage. * Do not treat OpenTelemetry as a compliance-grade audit trail. Cowork is not currently represented in audit logs, the Compliance API, or data exports. ## Claude Cowork security review checklist * A named owner has approved the local, remote, browser, MCP, plugin, and Computer Use surfaces separately. * Only dedicated, low-privilege folders are mounted. * Network egress is deny-by-default or limited to approved destinations. * Browser access is disabled or site-allowlisted. * MCP servers and plugins have source review, credential scoping, and an update process. * Persistent approvals are disabled for high-impact tools. * OTel data is collected, redacted, protected, and correlated to identities. * Regulated workflows do not depend on audit evidence Cowork cannot produce. * Users understand prompt injection and review every external side effect. ## Claude Cowork provider documentation * [Get started with Claude Cowork](https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork) * [Claude Cowork architecture](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Use Cowork safely](https://support.claude.com/en/articles/13364135-use-claude-cowork-safely) * [Use Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [Monitor Cowork with OpenTelemetry](https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry) * [Computer Use in Cowork](https://support.claude.com/en/articles/14128542-let-claude-use-your-computer-in-cowork) * [Enterprise configuration for Claude Desktop](https://support.claude.com/en/articles/12622667-enterprise-configuration-for-claude-desktop) ## Applicable Harmonic guidance * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) *Last reviewed: August 18, 2026* ## Related handbook guidance * [Anthropic](/by-ai-vendor/anthropic) * [2.1 Connectors and apps: the integration backbone](/handbook/2.-supply-chain-and-extensibility/2.1-connectors-and-apps-the-integration-backbone) * [3.1 What Even is an AI Sandbox?](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility) # Claude Code Security guidance for Claude Code, including identity, MCP servers, hooks, filesystem access, sandboxing, approvals, telemetry, and incident response. {% hint style="warning" %} **In short:** Claude Code is Anthropic's coding agent across the terminal, IDEs, Claude Desktop, hosted web sessions, mobile or browser remote control, and automated workflows. The product name is the same across these surfaces, but the code, credentials, network traffic, and approval path may live on a developer endpoint, a remote host, Anthropic infrastructure, or a CI runner. {% endhint %} ## What is Claude Code? Claude Code can inspect repositories, edit files, run commands and tests, use Git, operate development tools, and call connectors or MCP servers. It uses the same underlying agent engine across several clients. The Claude Agent SDK exposes the agent loop for applications and automated services. This handbook covers the SDK under **Anthropic API & Agent Platform** because the application owner chooses the runtime, identity, credentials, and surrounding controls. ## Surfaces and their security considerations | Surface | Where work runs | Main security considerations | | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Terminal CLI** | On the user's workstation, a development server, or another shell host. | The session inherits the operating-system user's files, environment variables, credentials, network reach, and installed tools. Enforce workspace trust, sandboxing, permission rules, managed settings, secret-path denies, and narrow network access. | | **VS Code and JetBrains** | Usually on the local or remote IDE host. | IDE trust, extension deployment, unsaved editor context, integrated terminals, remote-development credentials, and repository settings become part of the boundary. Apply the same managed Claude Code policy used for the CLI and control which IDE extensions may run. | | **Claude Desktop Code section** | Local machine, an SSH host, or an Anthropic-hosted cloud environment selected per session. | Do not treat Desktop as one runtime. Local sessions inherit endpoint authority. SSH sessions inherit the remote account. Cloud sessions use separate repository and environment controls. Review worktrees, preview browser, Computer Use, connectors, scheduled tasks, and bypass-mode settings. | | **Claude Code on the web** | An isolated Anthropic-managed cloud virtual machine. | Scope the GitHub App or synced GitHub credential to required repositories. Configure environment network access as None, Trusted, or a narrow Custom list instead of Full. Treat setup scripts and environment variables as privileged configuration. Sessions can continue after the user disconnects. Organizations with Zero Data Retention cannot use cloud-session features. | | **Mobile and Remote Control** | Cloud sessions run at Anthropic. Remote Control is only a client into a CLI or VS Code session that continues to run on the user's machine. | Protect the mobile account and device, require admin enablement, and review pairings. Remote Control does not move execution into a safer mobile sandbox; it exposes the local session's filesystem, tools, MCP servers, and approvals through another device. | | **Slack, GitHub, scheduled tasks, and CI/CD** | Anthropic cloud, a repository workflow runner, or another configured automation host. | Use service identities, least-privilege repository grants, isolated runners, constrained network access, spend controls, and human review. Unattended jobs should not use broad bypass modes or production credentials. | ## Core security model Claude Code uses permissions and sandboxing together: * **Permission rules** decide whether a tool action is allowed, denied, or requires confirmation. * **Sandboxing** limits what an allowed process can read, write, or reach. * **Managed settings** can impose organization requirements over user and project configuration. * **Workspace trust** marks whether Claude Code should load project configuration from a repository. * **Repository content** can influence the agent through instructions, hooks, plugins, MCP configuration, build scripts, tests, and tool output. An approval prompt is not proof that a command is safe. Review the command, working directory, affected paths, network destination, and credentials the process can inherit. ## How to configure Claude Code securely ### Identity and access * Prefer managed Team or Enterprise sign-in for interactive use. * Use **forceLoginMethod**, organization controls, and managed settings to prevent unapproved authentication paths where supported. * Scope access through organization roles and groups. * Use separate service identities for CI, scheduled work, code review, and other automation. * Do not reuse an interactive developer token as a production automation credential. * Recertify GitHub, GitLab, cloud-provider, connector, and MCP access independently. ### Local CLI and IDE sessions * Deploy server-managed or device-managed settings so project and user files cannot weaken required controls. * Keep sandboxing enabled and restrict writes to approved repository roots. * Deny reads from credential stores, SSH material, environment files, production configuration, browser profiles, and unrelated home directories. * Use explicit allow, ask, and deny rules for shell commands, files, network actions, plugins, and MCP tools. * Keep outbound network access off or behind a corporate proxy unless the task needs it. * Open unfamiliar repositories in a disposable environment. Review **CLAUDE.md**, settings, hooks, plugins, MCP configuration, and build scripts before granting trust. * On Windows, avoid WebDAV paths and broad UNC patterns that may cause network requests outside the expected permission boundary. * For remote IDE sessions, apply the policy to the remote extension host as well as the local editor. ### Desktop Code sessions * Use the Desktop admin controls for **Code in Desktop**, **Code on the web**, **Remote Control**, and **Disable Bypass permissions mode**. * Apply Claude Code managed settings to local and SSH sessions launched by Desktop. * Test the deployed client because remotely uploaded settings may cover CLI and IDE paths before every Desktop path. * Restrict which SSH destinations and remote accounts users may select. * Treat the preview browser as an authenticated browser surface when cookies or local storage persist. * Keep Computer Use off unless needed. It acts on the actual desktop, outside the Bash sandbox. * Use isolated worktrees for parallel sessions and still require diff review before merge. * Give scheduled tasks narrower permissions and credentials than attended sessions. ### Web and cloud sessions * Grant the Anthropic GitHub App access only to approved repositories. Review whether **/web-setup** copies a local GitHub CLI credential into the account configuration. * Create separate cloud environments for different trust levels and repository groups. * Prefer **None** or **Custom** network access. Use **Trusted** only when its documented default domains are acceptable, and avoid **Full** for routine work. * Keep secrets out of ordinary environment variables when they would be visible to environment editors. Use supported secret handling where available and limit who can edit the environment. * Review setup scripts as production code. Pin dependencies and avoid downloading unverified installers. * Remember that Git operations use a dedicated proxy and outbound web traffic uses a security proxy; validate audit coverage rather than assuming it matches endpoint logs. * Do not use cloud sessions where the organization's Zero Data Retention requirement makes them ineligible. ### Remote Control and mobile * Keep Remote Control disabled unless remote steering is an approved use case. Team and Enterprise organizations should require the admin toggle. * Require managed devices, strong account authentication, screen lock, and timely lost-device revocation. * Use short session names that do not expose sensitive repository or customer names in notifications. * Prefer worktree spawning for concurrent remote sessions so edits do not collide. * Keep sandboxing enabled for Remote Control server mode and set a reasonable session capacity. * Review local prompts from the remote device as carefully as prompts entered at the workstation. ### Automation and CI/CD * Run noninteractive jobs in disposable, isolated runners. * Use a dedicated identity with repository and API permissions limited to the job. * Pin workflow actions and dependencies. * Deny production deployment, secret rotation, security-policy changes, and destructive infrastructure actions unless a separate approved control performs them. * Require branch protection, tests, review, and deployment gates after Claude creates a change. * Set budget, concurrency, and timeout limits. ## Monitoring and data * Use OpenTelemetry where a managed deployment needs usage, approval, tool, and error signals. * Redact prompts, command bodies, file contents, and tool results unless the organization has an approved need to collect them. * Test telemetry separately for CLI, IDE, Desktop, cloud, Remote Control, and CI. Coverage can differ. * Confirm current data retention and Zero Data Retention eligibility for the exact authentication and execution path. * Keep an inventory of plugins, MCP servers, connectors, hooks, cloud environments, scheduled tasks, Git integrations, and Remote Control usage. * Be able to revoke Claude sessions, long-lived tokens, API keys, Git provider grants, cloud environments, connectors, and MCP credentials. ## Claude Code security review checklist * Each approved surface has a named owner and a documented execution location. * Managed settings cannot be weakened by user or repository configuration. * Sensitive paths and production credentials are explicitly denied for local sessions. * Network access matches the surface: host policy for local work, environment policy for cloud work, and runner policy for automation. * Desktop local, SSH, and cloud sessions have been tested separately. * Git provider grants are repository-scoped and periodically recertified. * Remote Control cannot be enabled outside policy and lost devices can be removed quickly. * CI and scheduled tasks use service identities and isolated runners. * Human review remains required before merge, deploy, destructive changes, or changes to security controls. ## Claude Code provider documentation * [Claude Code overview](https://code.claude.com/docs/en/overview) * [Platforms and integrations](https://code.claude.com/docs/en/platforms) * [Security](https://code.claude.com/docs/en/security) * [Permissions](https://code.claude.com/docs/en/permissions) * [Sandboxing](https://code.claude.com/docs/en/sandboxing) * [Settings and managed configuration](https://code.claude.com/docs/en/settings) * [Use Claude Code Desktop](https://code.claude.com/docs/en/desktop) * [Claude Code on the web](https://code.claude.com/docs/en/claude-code-on-the-web) * [Remote Control](https://code.claude.com/docs/en/remote-control) * [Enterprise network configuration](https://code.claude.com/docs/en/corporate-proxy) * [Monitoring with OpenTelemetry](https://code.claude.com/docs/en/monitoring-usage) * [Data usage](https://code.claude.com/docs/en/data-usage) *Last reviewed: August 18, 2026* ## Applicable handbook articles These handbook articles cover the controls most directly relevant to this product. | Handbook area | Applicable articles | Why they apply | | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1. Identity & access |

1.1 SSO & SCIM for AI platforms
1.2 RBAC across AI platforms
1.3 Tenant restrictions: blocking personal accounts
1.5 Agent and non-human identity
1.6 API keys and service accounts governance
1.7 Human-in-the-loop and approval policies

| Managed authentication, roles, tenant enforcement, automation identities, service credentials, and command approvals all apply. | | 2. Connectors, extensions & supply chain |

2.1 Connectors and apps: the integration backbone
2.2 MCP servers: securing the protocol
2.3 MCP gateways and allowlisting
2.4 Analyzing skills for risk
2.5 Plugins and marketplaces
2.6 Hooks and lifecycle scripts
2.7 The supply-chain review workflow
2.8 Signing and packaging

| Repositories can supply MCP configuration, skills, plugins, hooks, packages, and agent instructions; connectors and extensions add further dependencies. | | 3. Runtime, sandboxing & autonomy |

3.1 Sandbox and isolation models
3.2 Approval policies and least-privilege autonomy
3.3 Network egress control
3.4 Internet access and browser automation
3.5 Computer Use / desktop control risks
3.6 Scheduled and background tasks
3.7 Remote access, dispatch and SSH
3.8 File and filesystem access controls

| Claude Code spans local, IDE, SSH, cloud, browser, remote-control, scheduled, CI, filesystem, and egress boundaries. | | 4. Data protection |

4.1 DLP for GenAI
4.2 Data classification for AI prompts and outputs
4.3 Data residency and regional inference
4.4 Retention and Zero Data Retention
4.5 Training opt-out and data usage
4.6 Cross-app data flow and live artifacts
4.7 Secrets and credential hygiene in prompts and tools

| Source code, environment variables, repository secrets, connected data, cloud sessions, and telemetry engage the full data-control set. | | 5. Threats & adversarial testing |

5.1 Prompt injection: the connective risk
5.2 Data exfiltration via tools and connectors
5.3 Supply chain attacks and notable CVEs
5.4 Agent-specific threats: tool poisoning and confused deputy
5.5 Red-teaming AI systems
5.6 Incident response for AI systems
5.7 Threat modeling AI systems

| Repository instructions, build scripts, tools, plugins, MCP, remote execution, and unattended automation expose every covered threat family. | | 6. Observability, audit & evidence |

6.1 The audit gap: what you can and can't see
6.2 OpenTelemetry for AI runtime
6.3 Compliance APIs by platform
6.4 Analytics and usage APIs
6.5 Routing AI telemetry to your SIEM
6.6 Evidence by surface and investigation paths
6.7 Continuous review cadence

| CLI, IDE, Desktop, cloud, Remote Control, and CI have distinct analytics, telemetry, compliance, SIEM, and investigation paths. | | 7. Rollout & operations |

7.1 Roll out by risk: the phased plan
7.2 Pilot design and success metrics
7.3 The security team checklist
7.4 The vendor-neutral control matrix

| Each execution surface needs risk-tiered access, a representative pilot, checklist evidence, and a vendor-neutral baseline. | ## Applicable Harmonic guide * [Securing Claude Products](https://www.harmonic.security/resources/guide-securing-claude-products) ## Related handbook guidance * [Anthropic](/by-ai-vendor/anthropic) * [2.2 MCP servers: securing the protocol](/handbook/2.-supply-chain-and-extensibility/2.2-mcp-servers-securing-the-protocol) * [2.6 AI hooks: inference controls and lifecycle automation](/handbook/2.-supply-chain-and-extensibility/2.6-ai-hooks-inference-controls-and-lifecycle-automation) * [3.1 What Even is an AI Sandbox?](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility) # Claude Tag Security guidance for Claude Tag, including identity, deployment scope, data handling, integrations, user access, monitoring, and evidence collection. {% hint style="warning" %} **In short:** Claude Tag is Anthropic's Slack-native shared agent for Team and Enterprise. In channels it acts under organization-provisioned service accounts, not the identity of the person who mentioned it. Everyone in an authorized channel can invoke the same shared access, so channel membership becomes a security boundary. {% endhint %} ## What is Claude Tag? Claude Tag lets Slack users mention Claude in channels or direct messages, run one-time and scheduled tasks, use channel memory, and connect the agent to repositories, data systems, and other services. Channel and direct-message behavior differ: * In a channel, Claude acts under its own agent identity and shared service accounts. * In a direct message, the session uses the individual's Claude account and personal connectors. Actions are attributed to that user. This distinction should be part of rollout training and incident response. ## Where Claude Tag runs and what it can access Each Slack thread runs in an Anthropic-hosted sandbox. The sandbox holds no long-lived credentials. Outbound HTTP or HTTPS requests pass through Anthropic's Agent Proxy, which checks the destination and injects a credential only at the boundary when a configured rule matches. Access is assembled from: * Slack channels and channel membership. * Access bundles attached to a channel scope. * Dedicated service accounts and the Claude GitHub App. * Allowed websites and bundle domains. * The network-access setting of the Anthropic environment. * The user's personal connectors for direct messages only. The default network posture blocks destinations that match no allow layer. New environments can still include Anthropic's Trusted set of package registries and developer hosts, so “default deny” does not necessarily mean no outbound access. ## Claude Tag security boundary Anyone in a channel covered by an Access bundle can ask Claude to use that bundle's credentials. The connected service account therefore needs permissions safe for the least-trusted member of every covered channel. Claude Tag retains channel memory and session transcripts and is not available to organizations with Zero Data Retention enabled. Published artifacts remain available to members who can access the source Slack channel. Scheduled routines can run without a fresh human prompt. Treat them as persistent automation with their own owner, scope, credential, and review requirements. ## How to configure Claude Tag securely ### Restrict who and where * Enable the restriction that limits invocation to approved Claude organization members. On Enterprise, grant the Claude Tag capability only through approved roles. * Review Slack workspace membership, guests, shared channels, and channel privacy before attaching access. * Scope Access bundles to the smallest set of channels. * Disable direct messages organization-wide if personal connectors and user-attributed actions are outside policy. * Do not use a broad public channel for access to sensitive systems. ### Provision agent identity safely * Create a dedicated service account for each connected service. * Never connect an administrator's personal account. * Grant the service account only the minimum read or write permissions required. * Restrict credentials to named hosts, path prefixes, and read-only methods where possible. * Keep production write access in a separate bundle and channel from general read access. * Use the connected system's audit logs to monitor actions attributed to the agent account. ### Control network and automation * Set the execution environment to the narrowest network level that supports the workflow. * Review Anthropic's Trusted default and remove destinations that are not required. * Avoid the allow-all wildcard. * Review every scheduled or recurring task, owner, trigger, destination, and credential. * Use the Claude Tag Audit view to inspect scheduled and one-time tasks and Agent Identity network calls. * Retain Slack and connected-system logs according to the organization's investigation requirements. ## Claude Tag security review checklist * The Slack app was approved by the Slack administrator and installed in the intended workspace. * Invocation is restricted to managed users where required. * Channel membership is reviewed before any Access bundle is attached. * Each connection uses a dedicated, least-privilege service account. * DM behavior and personal connectors match policy. * Network access is narrower than the default Trusted environment where possible. * Scheduled tasks have owners, expiration dates, and periodic reviews. * The organization accepts transcript and memory retention and the lack of ZDR. * Audit records from Claude Tag, Slack, and connected services can be correlated. ## Claude Tag provider documentation * [What is Claude Tag?](https://support.claude.com/en/articles/15594475-what-is-claude-tag) * [Security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) * [How agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) * [Audit Claude Tag activity](https://claude.com/docs/claude-tag/admins/audit) * [Set up routines](https://claude.com/docs/claude-tag/users/proactivity) *Last reviewed: August 18, 2026* ## Applicable handbook articles These handbook articles cover the controls most directly relevant to this product. | Handbook area | Applicable articles | Why they apply | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1. Identity & access |

1.2 RBAC across AI platforms
1.3 Tenant restrictions: blocking personal accounts
1.5 Agent and non-human identity
1.6 API keys and service accounts governance
1.7 Human-in-the-loop and approval policies

| Channel work uses shared agent identities and service accounts, while direct messages use individual identities and connectors. | | 2. Connectors, extensions & supply chain |

2.1 Connectors and apps: the integration backbone
2.3 MCP gateways and allowlisting
2.4 Analyzing skills for risk
2.5 Plugins and marketplaces
2.7 The supply-chain review workflow
2.9 SaaS agent-building supply-chain

| Access bundles, Agent Proxy rules, skills, plugins, instructions, repositories, and services must be reviewed as one release. | | 3. Runtime, sandboxing & autonomy |

3.1 Sandbox and isolation models
3.2 Approval policies and least-privilege autonomy
3.3 Network egress control
3.4 Internet access and browser automation
3.6 Scheduled and background tasks
3.8 File and filesystem access controls
3.9 Central hosted-agent runtime hardening

| Each thread runs in a hosted sandbox, egress crosses Agent Proxy, and scheduled routines can act without a fresh prompt. | | 4. Data protection |

4.1 DLP for GenAI
4.2 Data classification for AI prompts and outputs
4.4 Retention and Zero Data Retention
4.5 Training opt-out and data usage
4.6 Cross-app data flow and live artifacts
4.7 Secrets and credential hygiene in prompts and tools

| Slack scope, memory, transcripts, service credentials, repositories, outbound services, and published artifacts form the data boundary. | | 5. Threats & adversarial testing |

5.1 Prompt injection: the connective risk
5.2 Data exfiltration via tools and connectors
5.3 Supply chain attacks and notable CVEs
5.4 Agent-specific threats: tool poisoning and confused deputy
5.5 Red-teaming AI systems
5.6 Incident response for AI systems
5.7 Threat modeling AI systems

| Shared channel authority, extensions, and unattended routines expose the full injection, exfiltration, supply-chain, agent, testing, response, and modeling set. | | 6. Observability, audit & evidence |

6.1 The audit gap: what you can and can't see
6.2 OpenTelemetry for AI runtime
6.3 Compliance APIs by platform
6.4 Analytics and usage APIs
6.5 Routing AI telemetry to your SIEM
6.6 Evidence by surface and investigation paths
6.7 Continuous review cadence

| Evidence is split across Slack, Tag's audit view and network export, service-account logs, connected systems, and usage controls. | | 7. Rollout & operations |

7.1 Roll out by risk: the phased plan
7.2 Pilot design and success metrics
7.3 The security team checklist
7.4 The vendor-neutral control matrix

| Shared agents, access bundles, routines, and Slack deployment need separate pilot gates, evidence checks, and baseline controls. | ## Applicable Harmonic guide * [Securing Claude Products](https://www.harmonic.security/resources/guide-securing-claude-products) ## Related handbook guidance * [Anthropic](/by-ai-vendor/anthropic) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity) * [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies) * [4.6 Cross-app data flow and live artifacts](/handbook/4.-data-protection-and-residency/4.6-cross-app-data-flow-and-live-artifacts) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) # OpenAI Security configuration, governance controls, and risk guidance for ChatGPT Work and ChatGPT Codex. {% hint style="info" %} This section focuses on the two OpenAI workforce products that need the clearest security ownership: ChatGPT Work for general business tasks and ChatGPT Codex for software-development work. {% endhint %} ## Products covered in this handbook

:briefcase:

ChatGPT WorkFocus first on managed workspace use, connector and plugin scope, browser and Computer Use policy, scheduled work, artifact sharing, and evidence gaps. Related: sandboxing.ChatGPT Work

:code:

ChatGPT CodexFocus first on local and cloud boundaries, managed requirements, sandbox mode, approvals, hooks, MCP, network access, and runtime telemetry. Related: sandboxing, hooks, and OTel.ChatGPT Codex
## Security considerations specific to OpenAI **Unmanaged usage is the first risk.** ChatGPT Work and Codex are available through the unified desktop app and can appear on corporate devices through personal accounts. Find unmanaged use, claim accounts into the managed workspace, and assign access by group and use case before tuning fine-grained controls. **Work and Codex share technology, but not one policy surface.** Work is for research, analysis, documents, spreadsheets, presentations, Sites, and business workflows. Codex is for codebases, terminals, repositories, cloud tasks, and development automation. Review them separately even when they run in one desktop app. **Connectors, plugins, browser access, and Computer Use need explicit decisions.** Source-system permissions still apply, but Work and Codex can combine data and actions across systems. Separate read, write, send, delete, publish, and share permissions. **Evidence is split across systems.** Compliance exports are useful for supported messages and responses, but they do not prove every file, action, approval, or tool call. Pair platform evidence with endpoint, browser, source-system, repository, SIEM, and OpenTelemetry records where applicable. ## Current provider documentation * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275/) * [ChatGPT desktop app](https://learn.chatgpt.com/docs/app) * [Codex overview](https://developers.openai.com/codex/overview) * [Codex agent approvals and security](https://learn.chatgpt.com/docs/agent-approvals-security) * [Managed configuration](https://learn.chatgpt.com/docs/enterprise/managed-configuration) * [Governance and observability](https://learn.chatgpt.com/docs/enterprise/governance) *Last reviewed: August 18, 2026* ## Applicable Harmonic guidance * [Securing ChatGPT Work: A Practitioner's Guide](https://www.harmonic.security/resources/securing-chatgpt-work-a-practitioners-guide) * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Related handbook guidance * [AI Security Handbook](/) * [ChatGPT Work](/by-ai-vendor/openai/chatgpt-work) * [ChatGPT Codex](/by-ai-vendor/openai/chatgpt-codex) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) * [1.3 Tenant restrictions: blocking personal accounts](/handbook/1.-identity-and-access/1.3-tenant-restrictions-blocking-personal-accounts) # ChatGPT Work Security guidance for ChatGPT Work, including managed workspace use, connectors, browser and Computer Use policy, scheduled work, artifacts, sandbox boundaries, and evidence gaps. {% hint style="warning" %} **In short:** ChatGPT Work turns ChatGPT into a general business agent for research, analysis, documents, spreadsheets, presentations, Sites, connected apps, browser tasks, and recurring work. Treat it as a workforce agent surface, not ordinary chat. {% endhint %} ## What to focus on first

:user-shield:

Bring usage under managementFind desktop and web usage, force managed sign-in where available, enforce SSO and MFA, and assign Work by group and use case.1.1 SSO & SCIM for AI platforms

:plug:

Review connectors and pluginsSeparate read access from write, send, delete, publish, and share actions. Source-system permissions still apply, but Work makes them easier to combine.2.1 Connectors and apps: the integration backbone

:box:

Do not overclaim sandbox coverageDesktop Work can use local permission controls, while hosted Work runs under ChatGPT workspace controls. Match the control to the execution path.3.1 What Even is an AI Sandbox?

:globe:

Gate browser and Computer UseSigned-in browser state, screen contents, clipboard data, and desktop apps can become agent-visible. Disable or scope these surfaces for baseline users.3.5 Computer Use / desktop control risks

:clock:

Constrain scheduled work and artifactsScheduled tasks, generated files, Sites, and shared artifacts need owners, destinations, expiry or review dates, and DLP coverage.3.6 Scheduled and background tasks

:magnifying-glass-chart:

Build the evidence trailCompliance logs help, but they do not capture every file, action, approval, or tool call. Join platform records with endpoint and source-system logs.6.6 Evidence by surface and investigation paths
## What is ChatGPT Work? ChatGPT Work is OpenAI's general-purpose agentic workspace for business tasks. Use it for research, analysis, documents, spreadsheets, presentations, Sites, and workflows that need context from conversations, files, workspace resources, or connected systems. Work is distinct from **ChatGPT Codex**, which is the software-development agent for repositories, terminals, code review, cloud tasks, and developer automation. Approve Work and Codex separately, even when both appear in the same ChatGPT desktop app. ## Security boundary Work can run in hosted ChatGPT contexts and, through the desktop app, on a local computer with selected local permissions. Those paths do not share one security boundary. For every rollout, record: * whether the task is web, mobile, desktop, local, remote, or hosted; * which connected apps, plugins, files, folders, browser sessions, and artifacts it can reach; * which actions require approval before write, send, delete, publish, share, purchase, or external transfer; * whether generated files and Sites are covered by DLP, retention, and sharing policy; and * which evidence sources can reconstruct prompts, responses, files, tool calls, approvals, and downstream actions. ## Security review checklist * Work usage is discovered across managed and personal accounts. * SSO, MFA, SCIM, workspace membership, and group-based access are enforced. * Connectors and plugins have reviewed owners, scopes, actions, and revocation paths. * Browser, Chrome, Computer Use, Appshots, Remote Control, and scheduled work are disabled or scoped for the baseline role. * Sensitive app categories such as admin, finance, HR, legal, security, customer systems, and production systems require approval or are blocked. * Sites, generated files, and artifacts have sharing, retention, and DLP controls. * Compliance exports are paired with endpoint, browser, source-system, repository, and SIEM evidence. * Prompt injection, exfiltration, destructive action, connector abuse, and public sharing tests are run before broad rollout. ## Provider documentation * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275/) * [ChatGPT desktop app](https://learn.chatgpt.com/docs/app) * [Admin controls for apps and connectors](https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-in-apps-enterprise-edu-and-business) * [Built-in browser](https://help.openai.com/en/articles/20001277-using-the-built-in-browser-in-the-chatgpt-desktop-app) ## Applicable Harmonic guidance * [Securing ChatGPT Work: A Practitioner's Guide](https://www.harmonic.security/resources/securing-chatgpt-work-a-practitioners-guide) *Last reviewed: August 18, 2026* ## Related handbook guidance * [OpenAI](/by-ai-vendor/openai) * [2.1 Connectors and apps: the integration backbone](/handbook/2.-supply-chain-and-extensibility/2.1-connectors-and-apps-the-integration-backbone) * [3.5 Computer Use / desktop control risks](/handbook/3.-runtime-sandbox-and-autonomy/3.5-computer-use-desktop-control-risks) * [4.6 Cross-app data flow and live artifacts](/handbook/4.-data-protection-and-residency/4.6-cross-app-data-flow-and-live-artifacts) * [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform) # ChatGPT Codex Security guidance for ChatGPT Codex across desktop, CLI, IDE, cloud, SDK, and automation workflows, including sandboxing, hooks, OpenTelemetry, approvals, network access, and evidence. {% hint style="warning" %} **In short:** ChatGPT Codex is OpenAI's coding agent across the command line, IDE extension, ChatGPT Desktop, Codex web and cloud tasks, the Codex SDK, noninteractive automation, and supported remote clients. The product can look similar across these surfaces while executing with very different filesystem, credential, network, and audit boundaries. {% endhint %} ## What to focus on first

:diagram-project:

Separate each execution surfaceThe same Codex label can mean local shell access, a remote host, a cloud container, a desktop task, or CI automation. Each surface needs its own owner and approval path.3.9 Central hosted-agent runtime hardening

:box:

Make the sandbox explicitCodex can inspect files, run commands, install dependencies, open browsers, and write code. Keep defaults least-privilege and test what each profile really contains.3.1 What Even is an AI Sandbox?

:code-branch:

Govern hooks and repo instructionsHooks, setup scripts, AGENTS.md files, MCP config, tests, and command output can change what the agent sees and does. Review them before broad rollout.2.6 AI hooks: inference controls and lifecycle automation

:plug:

Constrain MCP, plugins, and networkTool access can turn a coding assistant into an actor across SaaS, secrets, browsers, CI, and internal services. Allowlist by need, identity, and destination.2.3 MCP gateways and allowlisting

:route:

Collect runtime evidence earlyCodex evidence varies by local versus cloud execution and by ChatGPT versus API authentication. Route OpenTelemetry and correlate it with Git, endpoint, CI, proxy, and cloud logs.6.2 OpenTelemetry for AI runtime visibility

:check-double:

Keep human review in the pathNoninteractive jobs, scheduled tasks, and cloud agents can continue after the user leaves. Require review before merge, deploy, deletion, secret changes, or policy changes.1.7 Human-in-the-loop and approval policies
## What is ChatGPT Codex? Codex can inspect and modify repositories, run commands and tests, review diffs, use Git, create pull requests, operate browsers and development tools, and call plugins or MCP servers. Codex Local and Codex Cloud are separate administrative capabilities in managed ChatGPT workspaces. Security teams should decide which user groups may use each one and then configure each execution surface. ## Surfaces and their security considerations | Surface | Where work runs | Main security considerations | | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Codex CLI** | On the user's workstation, development server, or shell host. | Inherits the operating-system user's files, environment variables, credentials, tools, and network reach, subject to the Codex permission profile and approval policy. | | **Codex IDE extension** | In the local or remote VS Code extension host. Other IDEs can run the CLI in their terminal. | IDE workspace trust, extension deployment, remote-development hosts, open files, integrated terminals, and repository instructions are part of the boundary. | | **ChatGPT Desktop, Codex section** | Local machine, supported remote or SSH environment, or an OpenAI cloud environment selected for the task. | Treat local, remote-host, and cloud sessions separately. Desktop can add parallel agents, worktrees, visual diff review, previews, browser tools, Computer Use, Remote Control, plugins, skills, and scheduled work. | | **Codex web and delegated cloud tasks** | An isolated OpenAI-managed container linked to an approved repository and environment. | Scope GitHub access, environment membership, setup scripts, secrets, and network policy. Setup runs may have network access before the agent phase. | | **Codex SDK and app server** | In an application or service environment chosen by the developer. | The application owner controls the host, identity, sandbox, approvals, persistence, and exposed tools. Use read-only or workspace-scoped sandboxes by default. | | **codex exec, CI, and other automation** | In a local process, CI runner, scheduled job, or another automation host. | Noninteractive execution can remove the human approval step. Use disposable runners, service identities, deterministic policy, and review before merge or deploy. | | **Mobile Remote and other remote clients** | The task continues on the paired desktop, another Codex host, or in Codex cloud. | A phone is a control surface, not the execution boundary. Require workspace permission, device controls, pairing review, and rapid revocation. | | **GitHub, Slack, code review, and scheduled integrations** | Usually in OpenAI cloud or the configured workflow environment. | Scope repository and workspace grants, limit automated triggers, separate service identities, constrain network and tools, and require branch protection. | ## Core security model Local Codex uses two complementary control layers: * **Permission profiles** define filesystem and network access. * **Approvals and command rules** decide whether an action runs, is denied, or requires review. * **Managed requirements** constrain which profiles, MCP servers, plugins, and related settings users may select. * **Repository instructions and tools** can influence agent behavior through AGENTS.md files, skills, hooks, MCP configuration, build scripts, tests, and command output. The built-in local profiles include read-only, workspace, and danger-full-access. Full access removes normal local sandbox restrictions and should not be available in a routine enterprise deployment. ## How to configure Codex securely ### Workspace access * Use ChatGPT workspace roles and groups to scope Codex access. * Configure **Codex Local** and **Codex Cloud** separately. * Require approved ChatGPT workspace authentication on managed endpoints where supported. * Prevent personal API-key use when it falls outside policy. * Treat ChatGPT workspace administration and API Platform organization administration as separate control planes. * Use distinct service identities for CI, scheduled automation, code review, and other unattended work. ### CLI and IDE Use managed **requirements.toml** through the supported cloud assignment, system policy, MDM, or equivalent management path. * Allow only reviewed permission profiles and set a least-privilege default. * Omit **danger-full-access** so users cannot select it. * Deny reads from environment files, keychains, cloud credentials, SSH material, browser profiles, production configuration, and unrelated directories. * Restrict writes to approved repositories and output folders. * Keep network off by default or allow only task-required domains. * Use command rules to block or prompt for dangerous shell tools and entry points. * Allowlist MCP servers by both name and identity. * Restrict plugin sources, hooks, web-search behavior, and feature flags. * Test mixed client versions before relying on a newly introduced managed control. * Apply the policy to remote IDE extension hosts, not only the user's laptop. ### ChatGPT Desktop Codex sessions * Confirm that Desktop receives the same Codex Local requirements as the CLI and IDE. * Treat local, SSH or remote-host, and cloud sessions as different policy targets. * Review workspace roots before a session starts. * Use isolated worktrees for parallel agents and still require human diff review. * Keep Computer Use, browser access, full Chrome DevTools access, and Remote Control off unless there is an approved need. * Review plugins, skills, MCP servers, Appshots, local memories, and scheduled work as separate sources of context or authority. * Restrict which devices may be discovered and controlled remotely. * Apply the shared desktop controls described in **ChatGPT Work**. ### Codex cloud * Grant repository access only to required organizations and repositories. * Create separate environments for different repository or data trust levels. * Review setup and maintenance scripts as code. Pin dependencies and avoid unverified installers. * Store secrets in the supported secret field instead of ordinary environment variables where possible. * Remember that environment variables may be available throughout the task and that environment caches may be visible to other users who can access the same environment. * Leave agent internet access off unless the task needs it. When enabled, use a domain allowlist. * Account for the fact that outbound traffic passes through OpenAI's HTTP and HTTPS proxy. * Require branch protection, CI, code review, and deployment gates after Codex produces changes. ### SDK and noninteractive automation * Start the SDK and app server in read-only or workspace-scoped mode. * Authenticate callers and map them to narrow task authority. * Do not allow untrusted prompts to choose sandbox mode, approval policy, workspace roots, MCP servers, or credentials. * For **codex exec**, keep the default read-only sandbox unless the job must write. * Use workspace-write only in an isolated repository copy or disposable runner. * Reserve danger-full-access for a separately isolated environment with no valuable credentials or network reach. * Fail closed when required MCP servers or policy files are unavailable. * Set time, spend, concurrency, and output limits. * Require review before automation can merge, deploy, rotate secrets, alter security policy, or make destructive infrastructure changes. ### Remote and integration surfaces * Enable Remote Control only for approved roles and managed devices. * Require the desktop or host to opt into discovery and control. * Revoke pairings and sessions promptly after device loss or role change. * Limit Slack and GitHub triggers to approved channels, repositories, actors, and action types. * Use branch protections and a separate deployment identity after Codex creates or reviews code. ## Monitoring and incident response * Use workspace and Codex analytics for adoption and product activity. * Use the Compliance API for supported audit records, and test the current coverage of local clients, cloud tasks, prompts, actions, and content needed by the organization. * Use local OpenTelemetry only with an approved endpoint, redaction, access, and retention plan. * Correlate Codex activity with endpoint, source-control, CI, proxy, secret-manager, and cloud audit logs. * Keep an inventory of local clients, cloud environments, repository grants, plugins, MCP servers, skills, hooks, Remote Control pairings, scheduled tasks, and integrations. * Be able to revoke ChatGPT sessions, API keys, repository grants, plugin and MCP credentials, remote pairings, and cloud environments. ## Codex security review checklist * Every approved surface has a named owner and a documented execution location. * Codex Local and Codex Cloud are separately assigned. * Managed requirements reach the CLI, IDE, and Desktop clients in use. * Full access is unavailable and sensitive paths are explicitly denied. * Local, remote-host, and cloud sessions have been tested separately. * Cloud setup scripts, environment variables, secrets, caches, and network allowlists are reviewed. * Noninteractive jobs use service identities and disposable runners. * Mobile Remote cannot bypass local permissions or the approval policy. * Audit coverage has been tested for each surface instead of inferred from another one. * Human review remains required before merge, deployment, destructive changes, or changes to security controls. ## ChatGPT Codex provider documentation * [Using Codex with your ChatGPT plan](https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan) * [Codex quickstart](https://learn.chatgpt.com/docs/quickstart) * [Enterprise admin rollout](https://learn.chatgpt.com/docs/enterprise/admin-setup) * [Agent approvals and security](https://learn.chatgpt.com/docs/agent-approvals-security) * [Permission profiles](https://learn.chatgpt.com/docs/permissions) * [Managed configuration](https://learn.chatgpt.com/docs/enterprise/managed-configuration) * [Codex cloud environments](https://developers.openai.com/codex/cloud/environments) * [Codex cloud internet access](https://learn.chatgpt.com/docs/cloud/internet-access) * [Codex CLI noninteractive mode](https://developers.openai.com/codex/noninteractive) * [Codex SDK](https://developers.openai.com/codex/sdk) * [Governance and observability](https://learn.chatgpt.com/docs/enterprise/governance) * [Compliance API](https://learn.chatgpt.com/docs/enterprise/compliance-api) ## Applicable Harmonic guidance * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) *Last reviewed: August 18, 2026* ## Related handbook guidance * [OpenAI](/by-ai-vendor/openai) * [2.2 MCP servers: securing the protocol](/handbook/2.-supply-chain-and-extensibility/2.2-mcp-servers-securing-the-protocol) * [2.6 AI hooks: inference controls and lifecycle automation](/handbook/2.-supply-chain-and-extensibility/2.6-ai-hooks-inference-controls-and-lifecycle-automation) * [3.1 What Even is an AI Sandbox?](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility) # 1. Identity & Access How to manage human and non-human identity across AI platforms, including SSO, SCIM, RBAC, tenant restrictions, domain claiming, and agent service accounts. *Last reviewed: August 18, 2026* {% hint style="info" %} Identity is the first control. If you cannot enforce managed login and govern who has access to which AI platforms, every other control is built on sand. {% endhint %} ## Articles in this section 1. [1.1 SSO & SCIM for AI platforms](/handbook/1.-identity-and-access/1.1-sso-and-scim-for-ai-platforms) 2. [1.2 RBAC across AI platforms](/handbook/1.-identity-and-access/1.2-rbac-across-ai-platforms) 3. [1.3 Tenant restrictions: blocking personal accounts](/handbook/1.-identity-and-access/1.3-tenant-restrictions-blocking-personal-accounts) 4. [1.4 Domain claiming: bringing shadow accounts into enterprise](/handbook/1.-identity-and-access/1.4-domain-claiming-bringing-shadow-accounts-into-enterprise) 5. [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity) 6. [1.6 API keys and service accounts governance](/handbook/1.-identity-and-access/1.6-api-keys-and-service-accounts-governance) 7. [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies) ## Frequently asked questions **Is SSO enough to secure an AI platform?**\ No. SSO controls the managed sign-in path. It does not automatically govern personal accounts, API keys, local credentials, workload identities, connector grants, or every hosted execution path. Pair SSO with lifecycle provisioning, tenant restrictions, capability-based roles, credential governance, and tested revocation. **How should agent identity differ from user identity?**\ Use a dedicated, attributable workload identity for unattended or shared work. Give it narrow scopes, short-lived credentials where possible, a named owner, and a separate revocation path. Preserve the initiating user when a person launches the task. ## Related handbook guidance * [AI Security Handbook](/) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) * [Security Team Checklist](/start-here/security-team-checklist) * [Glossary](/start-here/glossary) # 1.1 SSO & SCIM for AI platforms Force managed login and automate lifecycle provisioning so AI platform access follows your joiners, movers, and leavers process. *Last reviewed: August 18, 2026* {% hint style="info" %} AI platform access should follow your identity provider. SSO handles sign-in. SCIM handles lifecycle. Without both, users can keep access after role changes, team moves, contract endings, or account cleanup. {% endhint %} ## What security teams need to know about SSO & SCIM for AI platforms AI tools have moved from chat windows into code editors, browsers, office files, mobile apps, and direct APIs. That makes identity the first control. If a user can reach an AI platform with a personal account or a stale invitation, most downstream policies become softer than they look in the admin console. Single sign-on gives the organization a controlled login path. It lets security teams enforce MFA, conditional access, device posture, location rules, and joiner or leaver workflows through the identity provider. SCIM (System for Cross-domain Identity Management) adds lifecycle management. It provisions users and groups into the AI platform, updates membership as people move teams, and removes access when the IdP says a person should no longer have it. SCIM matters because AI access is often group-shaped. The group may decide who can use a coding agent, who can connect Slack, who can publish a custom assistant or skill, who can reach web search, or who can use admin tooling. Manual invites do not keep up with those decisions. The clean pattern is simple: make the IdP the source of truth, sync groups into the AI platform, assign platform roles to those groups, and remove manual exceptions on a schedule. ## Common SSO & SCIM for AI platforms security failures * SSO is enabled, but users are still invited manually and never become SCIM-managed. * A user is removed inside the AI platform, then reappears on the next directory sync because the IdP assignment was never changed. * Chat, coding, API, and admin surfaces are managed separately, with different owners and different offboarding behavior. * SCIM groups are synced, but workspace roles are still assigned directly to individual users. * The default role or default seat gives more access than a newly provisioned user should receive. * The organization treats SSO as account consolidation. SSO controls sign-in, but it does not automatically migrate or clean up every personal account. ## SSO & SCIM for AI platforms security controls checklist * Require SSO for managed workspaces and enterprise accounts. * Enforce phishing-resistant MFA, conditional access, and managed-device requirements through the identity provider where supported. * Enable SCIM for every supported workspace or organization, including separate chat and API organizations where the provider splits them. * Sync groups by use case, data sensitivity, and job function rather than broad department alone. * Assign roles to groups, not individuals, except for time-limited break-glass access. * Review default role, default seat, and default capabilities before automated provisioning. * Define session lifetime, reauthentication, token revocation, and device-loss procedures for each surface. * Test whether deprovisioning ends active web, desktop, mobile, CLI, IDE, API, remote, and connector sessions. * Keep emergency administrator accounts separate, monitored, time-limited, and tested. * Remove SCIM-managed users through the IdP, not directly in the platform. * Review pending invitations, manually added users, unsupported login paths, and personal accounts each month. * Record the IdP group, platform role, product surface, authentication method, business owner, and review cadence for each access path. ## Session assurance SSO proves how a managed session begins. Security also needs to know how it ends. Record the maximum session age, refresh-token behavior, reauthentication triggers, local credential cache, device binding, and revocation path for every surface. Test a disabled user, a lost device, a removed connector grant, and an administrator role change. If a desktop, CLI, IDE, mobile, or remote session continues after the expected cutoff, treat that as a control gap rather than an implementation detail. ## Anthropic ### Overview Anthropic supports both just-in-time (JIT) and SCIM provisioning for Claude Enterprise organizations, and documents how SCIM sync applies identity-provider changes to the organization. Claude Enterprise includes Claude on web, desktop, and mobile, plus Claude Code and Cowork, so the identity design should cover the whole organization rather than a single client. Claude Console roles are separate from Claude app custom roles, so treat chat, Cowork, Claude Code, Console, and API access as related but distinct access paths, and assign Enterprise custom roles to SCIM-synced groups rather than individuals. One ordering detail matters before enablement: Anthropic documents that saving a SCIM configuration before users are assigned in the identity provider can deprovision existing users. Complete the IdP assignment first, then save the SCIM configuration, and test with a pilot group before rolling sync out to the whole organization. For Claude Code, the authentication model can include Claude.ai accounts, Console credentials, cloud provider credentials, and gateway-issued tokens. That flexibility is useful for engineering teams, but it also means identity review needs to include local CLI and CI usage. A developer with an API key in an environment variable may not be following the same lifecycle path as a user who signs in through the Claude app. ### Anthropic documentation * [Set up JIT or SCIM provisioning](https://support.claude.com/en/articles/13133195-set-up-jit-or-scim-provisioning) * [How SCIM sync works for Enterprise organizations](https://support.claude.com/en/articles/14499648-how-scim-sync-works-for-enterprise-organizations) * [Important considerations before enabling SSO and JIT/SCIM provisioning](https://support.claude.com/en/articles/10276682-important-considerations-before-enabling-single-sign-on-sso-and-jit-scim-provisioning) * [Set up single sign-on (SSO)](https://support.claude.com/en/articles/13132885-set-up-single-sign-on-sso) * [What is the Enterprise plan?](https://support.claude.com/en/articles/9797531-what-is-the-enterprise-plan) * [Claude Code authentication](https://code.claude.com/docs/en/team) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI documents SCIM for both ChatGPT workspaces and API Platform organizations, but says SCIM is not shared across those surfaces. That is an important operational detail. A clean ChatGPT offboarding flow does not automatically prove the API organization is clean. OpenAI's SCIM FAQ also warns against enabling Automatic Account Creation and SCIM together because only SCIM-managed users can be automatically deactivated through IdP group changes. ChatGPT Enterprise also has seat types as well as roles. Seat type controls which product surface the user can reach, while role controls workspace administration. ### OpenAI documentation * [SCIM Integration FAQ](https://help.openai.com/en/articles/10011769-scim-integration-faq) * [Managing members, seat types, roles and access in ChatGPT Enterprise](https://help.openai.com/en/articles/8266401-managing-members-seat-types-roles-and-access-in-chatgpt-enterprise) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about SSO & SCIM for AI platforms ### Is SSO enough for AI platform access? No. SSO controls authentication, but it does not keep group membership, feature access, seat type, or deprovisioning in sync by itself. SCIM closes much of that lifecycle gap. ### Should we create one IdP group for all AI access? Use one group only for a small pilot. In production, split groups by surface and risk, such as chat-only users, coding-agent users, API developers, admins, and regulated-data users. ### What should security review first? Start with non-SCIM users, manually invited admins, default roles, pending invitations, and users with access to code, connectors, or API keys. ### What is the difference between SSO and SCIM for AI tools? SSO controls how users authenticate. SCIM controls provisioning, group sync, and deprovisioning. Most enterprise AI rollouts need both. ### Why do ChatGPT and API access need separate identity checks? OpenAI documents ChatGPT workspace SCIM and API Platform SCIM as separate configurations. Review both surfaces before treating a user as fully provisioned or fully removed. ## 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 identity and access control. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Access Controls 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA identity, authentication, least privilege, and workforce access. | *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 * [1. Identity & Access](/handbook/1.-identity-and-access) * [1.2 RBAC across AI platforms](/handbook/1.-identity-and-access/1.2-rbac-across-ai-platforms) * [1.3 Tenant restrictions: blocking personal accounts](/handbook/1.-identity-and-access/1.3-tenant-restrictions-blocking-personal-accounts) * [1.4 Domain claiming: bringing shadow accounts into enterprise](/handbook/1.-identity-and-access/1.4-domain-claiming-bringing-shadow-accounts-into-enterprise) * [6.1 The audit gap: what you can and can't see](/handbook/6.-observability-audit-and-evidence/6.1-the-audit-gap-what-you-can-and-cant-see) # 1.2 RBAC across AI platforms How each vendor exposes roles and permissions, and how to design access models that grant the right capabilities without over-granting. *Last reviewed: August 18, 2026* {% hint style="info" %} AI RBAC should control capabilities as well as admin pages. A useful role design decides who can use agents, connectors, web access, skills, code execution, publishing, and audit exports. {% endhint %} **Primer** Traditional SaaS RBAC often starts with admin, editor, and viewer. AI platforms need a finer model because many end-user features carry security meaning. A user who can run a coding agent, install a connector, publish a skill, browse the web, or enable code execution can change the risk profile of a workspace without touching an admin page. Good AI RBAC starts with job function, but it is tested against capability. Ask what the user can cause the tool to do. Can it read files, write to a connected system, send messages, run code, access the internet, remember information, publish assets to other users, or create reusable instructions? Those are the permissions that matter. Group-based assignment is the safer pattern. Users enter groups through the identity provider, groups receive roles in the AI platform, and exceptions expire. This gives security teams a reviewable access map and keeps user moves from turning into quiet privilege drift. **Common failure modes** * Admin roles are separated, but high-risk end-user capabilities are enabled for everyone. * Multiple group roles are additive, and one broad group silently grants a capability the security team meant to restrict. * Workspace defaults remain permissive after custom roles are created. * Connector access is controlled in the AI platform, but the connected SaaS app still grants broad read or write permissions. * Role names describe departments rather than permitted actions. * A role grants identity administration to people who can also edit their own role or group path. **Controls checklist** * Build roles from capabilities first, then map them to departments. * Separate workspace administration from high-risk end-user actions. * Review additive-permission behavior before assigning multiple roles to the same group. * Keep default roles narrow, then grant higher-risk capabilities by group. * Split roles for chat, web access, coding agents, connector use, connector write actions, skill or plugin publishing, API administration, and audit access. * Require separate approval for roles that can change identity settings, groups, provisioning, domains, or role definitions. * Test a pilot user after every role change. The UI should match the intended effective access. * Review effective permissions quarterly, and after major vendor feature releases. **Anthropic** **Overview** Anthropic documents two relevant RBAC areas. Claude Console has roles such as User, Claude Code User, Limited Developer, Developer, Billing, and Admin. These govern Console and API-oriented administration, including API keys, billing, usage, and workspace-level permissions. Claude Enterprise custom roles cover product capabilities such as chat, code execution, memory, web search, public projects, skills, Claude Code, Cowork, Claude for Chrome, connectors, models, and admin areas. Anthropic states that custom roles are assigned to groups and that permissions are additive across roles. If any assigned role grants a capability, the member has it. The practical control is to avoid using one broad baseline role for everyone. Keep the baseline small, then create purpose-built roles for developers, connector users, skill authors, auditors, and admins. **Anthropic documentation** * [Claude Console roles and permissions](https://support.claude.com/en/articles/10186004-claude-console-roles-and-permissions) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) **OpenAI** **Overview** OpenAI separates workspace roles from product and runtime access. Built-in workspace roles include Owner, Admin, Member, and Analytics Viewer, while access to ChatGPT, Work, Codex developer tools, Codex cloud, and the Platform API is governed through additional workspace, group, runtime, and organization controls. Review role and capability assignments together; neither one proves that every execution path is governed. OpenAI's custom roles control end-user capabilities, while managed Codex requirements constrain security-sensitive local behavior across supported desktop, CLI, and IDE surfaces. Codex cloud eligibility and Platform API organization access remain separate boundaries. Users can inherit multiple custom roles through groups, so review effective access rather than one role assignment in isolation. For OpenAI, review three things together: seat type, workspace role, and custom-role permissions. A narrow custom role will not help if a broader seat or default workspace setting still grants access. **OpenAI documentation** * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [Managing members, seat types, roles and access in ChatGPT Enterprise](https://help.openai.com/en/articles/8266401-managing-members-seat-types-roles-and-access-in-chatgpt-enterprise) **Applicable Harmonic guides for OpenAI** * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) **Practitioner FAQs** **Who should own AI RBAC?** Identity teams should own the group lifecycle. Product or platform owners should own feature intent. Security should own the control standard and review exceptions. No single team sees the whole picture alone. **Should admins also be power users?** Keep the roles separate where the platform allows it. Admins need configuration authority. Power users need product capabilities. Combining both makes audits harder and gives one compromised account a wider blast radius. **How often should AI roles be reviewed?** Review high-risk roles at least quarterly. Review identity administration, connector write access, skill publishing, API key administration, and agent automation access after every material vendor release. **What AI permissions should never be granted by default?** Keep connector write actions, code execution, skill publishing, API key administration, broad agent access, and identity administration out of default roles. Grant them through reviewed groups. **Why do additive AI roles create risk?** Additive roles make the broadest grant win. A user in several groups may receive a capability from a role that no one thinks of as their primary access path. ## 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 identity and access control. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Access Controls 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA identity, authentication, least privilege, and workforce access. | *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 * [1. Identity & Access](/handbook/1.-identity-and-access) * [1.1 SSO & SCIM for AI platforms](/handbook/1.-identity-and-access/1.1-sso-and-scim-for-ai-platforms) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity) * [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) # 1.3 Tenant restrictions: blocking personal accounts How to block personal AI accounts using tenant restrictions, organization headers, proxies, browser controls, detection, and exception handling. *Last reviewed: August 18, 2026* {% hint style="info" %} Personal accounts can bypass the controls you configured for the enterprise workspace. Tenant restriction is the control family that keeps corporate users on managed accounts when they use AI tools on corporate devices, browsers, and networks. {% endhint %} ## Tenant restrictions: what security teams need to know Most AI governance programs start inside the managed workspace. That is necessary, but it leaves a simple escape path. A user can open the same AI service in a browser, desktop app, mobile app, CLI, or third-party wrapper and sign in with a personal account. Once that happens, enterprise SSO, SCIM, RBAC, retention, audit, and DLP may no longer apply. Tenant restriction is the set of controls that closes that escape path. It can include network policy, browser policy, endpoint controls, domain capture, managed app deployment, device posture, proxy inspection, and user education. The goal is to make the managed tenant the normal path and the personal tenant the blocked or detected path. Vendors implement tenant restriction differently. Some platforms expose formal tenant restriction headers or proxy controls. Others provide domain capture, SSO, workspace switching, app control, or role-level restrictions but do not provide a direct network-level tenant lock in public documentation. Confirm which category your vendor falls into before promising a hard block. ## Common tenant restrictions security failures * Browser access is controlled, but desktop and mobile apps are left unmanaged. * The managed workspace has SSO, but personal accounts on the same corporate email domain still exist. * Endpoint agents and secure web gateways classify the domain as allowed without checking whether the account is managed. * Developers use API keys, local CLIs, or IDE extensions outside the enterprise identity path. * The security team assumes vendor controls exist because similar controls exist in other SaaS platforms. * A block applies only on the corporate network, while remote users or mobile users route around it. ## Tenant restrictions security controls checklist * Inventory every access surface: web, desktop, mobile, CLI, IDE, browser extension, API, and third-party embedded AI. * Require managed app deployment where desktop or mobile apps are approved. * Enforce managed configuration on developer surfaces, such as Claude Code managed settings and Codex managed configuration, so local CLI and IDE installs follow organization policy rather than personal defaults. * Use SSO and SCIM to make the managed account path easy and reliable. * Use domain capture or account consolidation where the vendor supports it. * Configure secure web gateway, browser extension, and endpoint controls to detect personal-account use where direct blocking is not available. * Treat personal-account uploads of regulated or confidential data as a policy event. * Document which controls are hard blocks, which are detections, and which are user-process controls. * Test from a managed laptop, unmanaged browser profile, mobile device, and developer CLI. ## Anthropic ### Overview Anthropic documents Tenant Restrictions for Enterprise and Console customers. A corporate proxy injects an `anthropic-allowed-org-ids` header, and Anthropic blocks authentication to organizations outside the allowed list. The control covers Claude web, desktop and app access, API-key authentication, and OAuth-token authentication. It requires TLS inspection and only applies on networks where the proxy injects the header, so unmanaged networks and devices still need identity, endpoint, and egress controls. Claude Tag needs a separate Slack boundary. Its member restriction is off by default, and the Enterprise RBAC capability does nothing until an owner enables the restriction. Claude Tag is disabled by default in channels containing guests and does not operate in Slack Connect channels, but admins should still restrict which workspaces, channels, DMs, connections, and repositories it can use. ### Anthropic documentation * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [Enforce network-level access control with Tenant Restrictions](https://support.claude.com/en/articles/13198485-enforce-network-level-access-control-with-tenant-restrictions) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI documents that ChatGPT Enterprise users can move between enterprise workspaces and personal workspaces through the workspace switcher, and that personal workspaces under company email addresses may be subject to deletion or merge into the enterprise workspace. OpenAI also documents Lockdown Mode, but Lockdown Mode limits web and external-service access. It is not a tenant-restriction control for blocking personal account sign-in. The OpenAI documentation reviewed for this guide does not describe a tenant-restriction header equivalent, so treat OpenAI personal-account control as a mix of workspace management, account-consolidation behavior, RBAC, SCIM, endpoint and browser governance, and detection. For Codex on developer machines, managed configuration lets organizations set approval policy, sandbox behavior, and MCP-related settings centrally, which keeps local installs inside organization policy rather than personal defaults. ### OpenAI documentation * [Managing members, seat types, roles and access in ChatGPT Enterprise](https://help.openai.com/en/articles/8266401-managing-members-seat-types-roles-and-access-in-chatgpt-enterprise) * [Lockdown Mode](https://help.openai.com/en/articles/20001061) * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about tenant restrictions ### Is blocking the AI domain enough? Only if the organization has decided no one should use the service. If the service is approved, the harder problem is allowing the managed tenant while blocking or detecting personal accounts. ### Should this live in identity, network, or endpoint? All three usually have work to do. Identity owns managed sign-in and lifecycle. Network and browser controls handle web paths. Endpoint controls cover desktop apps, local agents, CLIs, and unmanaged browser profiles. ### Can we force employees onto the enterprise ChatGPT or Claude workspace? Anthropic documents a network-level Tenant Restrictions header for Enterprise and Console organizations, but it only applies where a managed proxy injects the header. OpenAI documents account consolidation behavior but not an equivalent tenant-restriction header in the sources used here. Pair the vendor controls with endpoint, browser, and secure web gateway detection for unmanaged paths. ### How can teams detect personal AI account use? Use browser, endpoint, secure web gateway, and identity logs to compare approved AI domains with managed-account signals. Treat unmatched usage as a review event, especially when corporate data appears in prompts or uploads. ### Does Lockdown Mode block personal ChatGPT accounts? No. OpenAI documents Lockdown Mode as a role-level security configuration that limits outbound web and external-service access to reduce prompt-injection data exfiltration. It governs what a managed account can do inside the workspace, not which account a user signs in with. ## 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 identity and access control. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Access Controls 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA identity, authentication, least privilege, and workforce access. | *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 * [1. Identity & Access](/handbook/1.-identity-and-access) * [1.1 SSO & SCIM for AI platforms](/handbook/1.-identity-and-access/1.1-sso-and-scim-for-ai-platforms) * [1.4 Domain claiming: bringing shadow accounts into enterprise](/handbook/1.-identity-and-access/1.4-domain-claiming-bringing-shadow-accounts-into-enterprise) * [G.6 Write an AI Acceptable Use Policy that holds up](/reference/governance-and-frameworks/g.6-write-an-ai-acceptable-use-policy-that-holds-up) * [7.1 Roll out by risk: the phased plan](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan) # 1.4 Domain claiming: bringing shadow accounts into enterprise How to identify and migrate accounts using your verified corporate domain into a managed enterprise workspace. *Last reviewed: August 18, 2026* {% hint style="info" %} Employees often try AI tools before the enterprise buys them. Once the tool becomes approved, the security task is to bring work accounts, personal workspaces, and old content under a managed governance path where the vendor supports it. {% endhint %} ## Domain claiming: what security teams need to know Shadow AI is often account sprawl. A company may have personal accounts created with corporate email addresses, team accounts owned by a department, API organizations created by developers, and a formal enterprise workspace created later by IT. All of them may sit under the same company domain, but they do not have the same controls. Managed-account consolidation is the cleanup work. It starts with finding accounts tied to company identities, deciding which accounts should be migrated or closed, and moving future access into the enterprise tenant. The mechanics vary by vendor. Some use domain verification and domain capture. Some merge or delete personal workspaces under a company domain. Some only support invitation, SSO, and SCIM, leaving cleanup to process and support requests. The main policy decision is what happens to existing user content. Users may have legitimate work in personal accounts. They may also have sensitive data in a place where the company has weak visibility. Treat cleanup as a migration and evidence project, with identity settings as one part of the work. ## Common domain claiming security failures * The enterprise workspace launches, but existing personal accounts stay active. * Employees keep using old personal workspaces because their chat history, files, or custom tools are there. * The organization sends a generic migration email without explaining what will happen to content. * API organizations created before central governance remain outside the admin inventory. * Users are consolidated into a managed workspace, but mobile and desktop sessions remain signed into old accounts. * Security teams cannot prove which accounts were captured, merged, deleted, or left alone. ## Domain claiming security controls checklist * Verify company domains in the AI platform where supported. * Restrict organization creation where the platform supports it, so new shadow workspaces cannot appear under managed identities without review. * Inventory accounts, workspaces, and API organizations tied to corporate domains. * Decide the cleanup action for each account class: migrate, merge, close, leave as exception, or escalate to vendor support. * Communicate the migration date, content impact, support path, and prohibited account patterns. * Pair account consolidation with SSO and SCIM so new shadow accounts are less likely to appear. * Require users to sign out of personal accounts on managed devices after migration. * Review access logs, workspace membership, and pending invitations after the migration window closes. * Keep an evidence record with domain verification, user counts, exception owners, and post-cleanup findings. ## Anthropic ### Overview Anthropic Enterprise adds domain capture, SSO, JIT or SCIM provisioning, role-based permissions, and managed policy settings across Claude web, desktop, mobile, Cowork, and Claude Code. Anthropic's member-management documentation adds two consolidation levers: invitations to Team and Enterprise organizations must use one of the organization's allowed email domains, and organization discovery lets colleagues with a matching email domain find and request to join the organization at signup, with admins choosing automatic or approval-based joining. Anthropic does not document a forced capture of existing personal accounts, so plan consolidation as communication, invitation, and provisioning work rather than a switch you flip. The Identity & Access admin area also includes verified domains, domain memberships, and a restrict-organization-creation setting, which limits how easily new shadow organizations appear under your domain. Verify current support guidance for user notice, content handling, timing, and rollback before running a migration. ### Anthropic documentation * [What is the Enterprise plan?](https://support.claude.com/en/articles/9797531-what-is-the-enterprise-plan) * [Set up single sign-on (SSO)](https://support.claude.com/en/articles/13132885-set-up-single-sign-on-sso) * [Set up JIT or SCIM provisioning](https://support.claude.com/en/articles/13133195-set-up-jit-or-scim-provisioning) * [Manage members on Team and Enterprise plans](https://support.claude.com/en/articles/13133750-manage-members-on-team-and-enterprise-plans) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI's ChatGPT Enterprise membership documentation says personal workspaces under company email addresses may be subject to deletion or merge into the enterprise workspace when users join the enterprise workspace. That supports the concept of managed-account consolidation, but it does not replace a migration plan. OpenAI also separates ChatGPT workspace access and API Platform organization access in important ways. Treat API organizations and ChatGPT workspaces as separate cleanup surfaces until an admin can prove they are governed together. ### OpenAI documentation * [Managing members, seat types, roles and access in ChatGPT Enterprise](https://help.openai.com/en/articles/8266401-managing-members-seat-types-roles-and-access-in-chatgpt-enterprise) * [SCIM Integration FAQ](https://help.openai.com/en/articles/10011769-scim-integration-faq) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about domain claiming ### Is domain claiming the same as SSO? No. SSO controls future sign-in. Domain claiming or account consolidation addresses existing accounts tied to a domain. A rollout often needs both. ### Should users be allowed to keep personal AI accounts? That is a policy decision. For corporate devices and corporate data, the safer default is to require the managed workspace. Personal accounts may still exist for private use, but the policy should separate personal use from corporate data handling. ### What evidence should we keep? Keep the verified domains, migration communications, account counts before and after cleanup, exceptions, support tickets, and the date SCIM became the lifecycle source. ### What should happen to old AI chat history during consolidation? Decide before migration. The policy should say whether content is migrated, retained under enterprise policy, exported, deleted, or left behind in an exception account. ### How do API organizations fit into shadow account cleanup? Treat API organizations as their own inventory. Chat workspace cleanup does not prove that API keys, projects, service accounts, or developer-created organizations are governed. ## 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 identity and access control. | | 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.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 * [1. Identity & Access](/handbook/1.-identity-and-access) * [1.3 Tenant restrictions: blocking personal accounts](/handbook/1.-identity-and-access/1.3-tenant-restrictions-blocking-personal-accounts) * [1.1 SSO & SCIM for AI platforms](/handbook/1.-identity-and-access/1.1-sso-and-scim-for-ai-platforms) * [1.2 RBAC across AI platforms](/handbook/1.-identity-and-access/1.2-rbac-across-ai-platforms) * [7.1 Roll out by risk: the phased plan](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan) # 1.5 Agent and non-human identity How to give AI agents scoped, attributable identities instead of borrowed human credentials. *Last reviewed: August 18, 2026* {% hint style="info" %} Agents need attributable identities. A task that reads files, calls tools, writes tickets, opens pull requests, or uses an API should leave a record of the human sponsor, the agent or workload identity, and the system it acted through. {% endhint %} ## Agent and non-human identity: what security teams need to know AI agents blur a line that security teams usually rely on. A person starts the work, but the agent may plan steps, call tools, run code, read files, write to services, and continue after the first prompt. If every action is recorded only as the human user, investigations become guesswork. If the agent uses a shared API key, they become harder. Non-human identity gives the agent or workload its own scoped identity. That identity might be a service account, an access token minted through workload identity federation, a gateway-issued token, a CI identity, or an internal service principal. The format matters less than the control goal: the identity should be scoped, attributable, revocable, logged, and separate from a person's normal interactive account. The best design keeps two facts together. First, who initiated or approved the run. Second, which non-human identity executed each action. When those facts split apart, access reviews and incident response get thin. ## Common agent and non-human identity security failures * Agents use a developer's personal API key in CI or production. * Several agents share the same service account, making activity attribution weak. * A service account can access every project because it was created once and reused. * Logs show an API key or bot user, but not the human sponsor, approval, or business owner. * Agent-owned connections persist after the agent is retired. * Tool calls inherit a human user's broad SaaS permissions when a narrower delegated identity would be safer. ## Agent and non-human identity security controls checklist * Assign each production agent or workload a named owner. * Use per-agent or per-workload identities where the platform supports them. * Separate production, staging, and test identities. * Scope each identity to the minimum projects, models, tools, connectors, and data classes it needs. * Prefer short-lived credentials issued through workload identity federation or a gateway for automated workloads. * Log the initiating user, approving user where applicable, workload identity, tool call, target system, and outcome. * Review service accounts, token mappings, and connected app grants on a fixed cadence. * Revoke or disable identities when an agent is retired, paused, or moved to a new owner. ## Anthropic ### Overview Claude Code supports several authentication paths, including Claude.ai credentials, Claude Console credentials, cloud provider credentials, gateway-issued tokens, API keys, bearer tokens, dynamic credential helper scripts, and OAuth tokens for non-browser contexts. The credential precedence matters because an environment variable can override the expected interactive account path once approved. Anthropic's Claude Code security documentation also describes scoped credentials in cloud execution and audit logging for cloud sessions. For local and CI usage, organizations should decide whether credentials come from a user login, an API key, a gateway, a cloud provider identity, or a dynamic helper that pulls short-lived credentials. Claude Managed Agents extend the picture to hosted, long-running agents. Managed Agents support vault-based authentication for credentials, and scheduled deployments run recurring agent work without a person present, so treat each deployment as an unattended identity with an owner, scoped credentials, logging, and a review cadence. Managed Agents is in beta, and sessions persist state server-side and are not currently eligible for zero data retention or HIPAA BAA coverage, so decide which identities and data classes are allowed to use it. Cowork scheduled tasks remain user-owned, but they can keep acting after the initiating conversation. Remote tasks use connected services in the user's workspace context; tasks that need local folders or applications depend on the desktop session. Inventory the human sponsor, schedule, connected identities, local device dependency, and revocation path even when the product does not issue a separate agent identity. Claude Tag has two identity modes that must not be collapsed. In Slack channels it acts through organization-provisioned service accounts and channel-scoped Access bundles, so every channel member can use the same connected authority. In a direct message it uses the requester's Claude account and personal connectors. Inventory those paths separately and correlate channel actions with the Slack thread and the dedicated account shown in the target system. ### Anthropic documentation * [Claude Code authentication](https://code.claude.com/docs/en/team) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Console roles and permissions](https://support.claude.com/en/articles/10186004-claude-console-roles-and-permissions) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Scheduled deployments](https://platform.claude.com/docs/en/managed-agents/scheduled-deployments) * [Schedule recurring tasks in Claude Cowork](https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork) * [How Claude Tag agent identity works](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) ## OpenAI ### Overview OpenAI documents workload identity federation for API workloads. Trusted workloads can exchange external OIDC identity tokens for short-lived OpenAI access tokens, and service account mappings can bind specific external token attributes to an OpenAI service account in a project. OpenAI also recommends dedicated service accounts, environment separation, exact claim matching, minimum permissions, regular mapping review, and monitoring token exchange failures or unexpected access patterns. Those recommendations map cleanly to agent identity design. OpenAI Workspace Agents add another non-human credential class. External systems trigger published workspace agents using access tokens that are distinct from platform API keys and Compliance API credentials, so inventory those tokens separately with their own owner, scope, and rotation records. For Codex, OpenAI's governance documentation distinguishes ChatGPT-authenticated Codex activity from API-key-authenticated Codex usage. That distinction matters for audit planning. ChatGPT Work and scheduled tasks are usually delegated user activity rather than standalone service identities. Record the user sponsor, schedule or trigger, plugins and connected apps, local project or cloud execution path, and stop or revoke procedure. Do not let the absence of a new API key keep an unattended task out of the non-human identity inventory. ### OpenAI documentation * [Workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation) * [Workspace Agents](https://developers.openai.com/workspace-agents) * [Codex Governance](https://developers.openai.com/codex/enterprise/governance) * [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275) * [Scheduled tasks](https://learn.chatgpt.com/docs/automations) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about agent and non-human identity ### Should an agent act as the user who launched it? Sometimes, especially for a short interactive task where user consent and user permissions are central. For production or scheduled work, a scoped workload identity is usually easier to review and revoke. ### What is the minimum audit trail? Capture the human sponsor, agent or workload identity, credential source, tool called, target system, timestamp, and result. For write actions, capture the approval path and the external object changed. Keeping the sponsor and the executing identity connected in the same record is what lets an investigator see who started the work and which identity acted. ### When is a shared service account acceptable? Use one only for low-risk experiments or tightly bounded internal tools. For production work, shared identities make cleanup and investigations harder. ### What is non-human identity in AI security? Non-human identity is the account, token, service account, workload identity, or gateway-issued credential an agent or automated system uses when it acts without a person typing each step. ### What should happen when an agent is retired? Revoke or disable its identity, tokens, and service-account mappings, and remove agent-owned connections in downstream systems. Reassign or close out the owner record, then confirm in logs that the identity stops appearing after the retirement date. Scheduled or recurring deployments deserve special attention because they keep running until someone turns them off. ## 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 identity and access control. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Access Controls 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA identity, authentication, least privilege, and workforce access. | *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 * [1. Identity & Access](/handbook/1.-identity-and-access) * [1.6 API keys and service accounts governance](/handbook/1.-identity-and-access/1.6-api-keys-and-service-accounts-governance) * [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies) * [5.4 Agent-specific threats: tool poisoning and confused deputy](/handbook/5.-threats-and-adversarial/5.4-agent-specific-threats-tool-poisoning-and-confused-deputy) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) # 1.6 API keys and service accounts governance How to keep personal keys out of automation and scope, rotate, monitor, and attribute machine access properly. *Last reviewed: August 18, 2026* {% hint style="info" %} API keys are production credentials, even when they start as developer convenience. Treat them like secrets with owners, scope, rotation, monitoring, and a retirement path. {% endhint %} ## API keys and service accounts governance: what security teams need to know AI API keys often appear before a formal platform team exists. A developer builds a proof of concept, stores a key in a local environment file, pushes a prototype into CI, and then the prototype becomes useful. That path is common, but it creates a hard cleanup problem once the application handles company data. API access needs the same governance as other machine access. Keys should be tied to a project, service account, workload, or owner. They should be stored in a secret manager, kept out of source control and prompts, rotated on a schedule, and monitored for usage that does not match the application. Service accounts improve this when they are scoped correctly. A service account for one workload in one environment is easier to review than a personal key shared across several systems. Workload identity federation improves it further by replacing long-lived secrets with short-lived tokens based on an external identity. ## Common API keys and service accounts governance security failures * A personal API key runs production traffic. * One key is reused across development, staging, production, CI, and local scripts. * Keys are stored in code, notebooks, ticket comments, prompt history, shell history, or analytics logs. * A key remains active after the developer leaves or the proof of concept is retired. * Usage monitoring is enabled, but no one reviews it. * API organization settings and ChatGPT workspace settings are reviewed by different teams. ## API keys and service accounts governance security controls checklist * Create separate projects for production, staging, test, and experimentation. * Use service accounts or workload identity mappings for automation where supported. * Keep personal keys out of shared services, CI, scheduled jobs, and production systems. * Store keys in a managed secret store and inject them at runtime. * Rotate long-lived keys and tokens on a documented schedule. * Record owner, system, environment, data class, key scope, creation date, rotation date, and review date. * Monitor usage by key, project, model, and environment where the platform exposes it. * Revoke keys when owners leave, systems retire, scope changes, or suspicious usage appears. * Add secret scanning to repositories, CI logs, and prompt/tool telemetry where feasible. ## Anthropic ### Overview Anthropic's Claude Console role documentation separates several access levels. Both the Limited Developer and Developer roles can manage API keys and webhook endpoints, with Developer additionally able to view session traces and download files, while User and Claude Code User roles have narrower access. That makes API key administration part of role design as well as developer workflow. Console workspaces add a scoping layer: workspace roles can grant additional permissions over organization-level baselines, so record which workspace each key belongs to and verify exact key-scoping behavior against current Console documentation. Claude Code can authenticate through environment variables such as `ANTHROPIC_API_KEY`, bearer tokens, dynamic helper scripts, OAuth tokens, and cloud provider credentials. The documentation says `apiKeyHelper` can return dynamic or rotating credentials, which gives teams a path to vault-backed or short-lived credential patterns. For local developer machines, include environment variables and helper scripts in reviews. A managed web account does not prove the CLI is using the intended credential. Claude Tag channel sessions use service accounts provisioned by an owner. Credentials live in a separate store and Agent Proxy injects them only when a request matches an approved host or path; the model and sandbox do not receive the stored secret. Use a dedicated account per connected service, scope each credential to the smallest channel set, host set, path prefix, and HTTP methods, and keep direct-message activity separate because it runs under the user's own account. ### Anthropic documentation * [Claude Console roles and permissions](https://support.claude.com/en/articles/10186004-claude-console-roles-and-permissions) * [Claude Code authentication](https://code.claude.com/docs/en/team) * [Claude Code security](https://code.claude.com/docs/en/security) * [How Claude Tag agent identity works](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) ## OpenAI ### Overview OpenAI's production guidance says API keys authenticate API requests and should not be exposed in code or public repositories. It recommends environment variables or a secret management service. It also notes that API key usage can be monitored when tracking is enabled. OpenAI also documents workload identity federation. A trusted workload can exchange an external identity token for a short-lived OpenAI access token. Service account mappings can restrict which external identity can mint a token for a specific OpenAI service account, and mappings can further narrow permissions. For Codex, the Compliance API covers ChatGPT-authenticated Codex activity only. API-key-authenticated Codex runs follow API organization settings and do not appear in Compliance API exports. Include that difference in audit and investigation planning. ### OpenAI documentation * [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) * [Workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation) * [Codex Governance](https://developers.openai.com/codex/enterprise/governance) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about API keys and service accounts governance ### Should developers be allowed to create API keys? Yes for approved experimentation, but not without boundaries. Require separate projects, spend limits, owner records, and a path to move production traffic to service accounts or workload identity. ### How often should keys be rotated? Set a baseline rotation period, then rotate immediately when an owner leaves, a repository leak is suspected, an application changes hands, or usage looks wrong. Short-lived tokens reduce the need for manual rotation. ### What should a key inventory include? Include key or token type, owner, service, environment, project, allowed data class, storage location, creation date, last rotation date, last seen date, and decommission date. ### Are API keys safe to use in AI agent workflows? They can be safe when scoped, stored in a secret manager, monitored, and tied to a clear owner. Long-lived personal keys are a poor fit for production agents. ### When should workload identity replace API keys? Use workload identity for production automation when the platform supports it and the workload already has a trusted external identity, such as cloud infrastructure, CI, or Kubernetes. ## 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 identity and access control. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Access Controls 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA identity, authentication, least privilege, and workforce access. | *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 * [1. Identity & Access](/handbook/1.-identity-and-access) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity) * [4.7 Secrets and credential hygiene in prompts and tools](/handbook/4.-data-protection-and-residency/4.7-secrets-and-credential-hygiene-in-prompts-and-tools) * [2.1 Connectors and apps: the integration backbone](/handbook/2.-supply-chain-and-extensibility/2.1-connectors-and-apps-the-integration-backbone) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) # 1.7 Human-in-the-loop and approval policies Where to require human approval in agentic workflows and how approvals can fail under prompt injection, fatigue, or unsafe defaults. *Last reviewed: August 18, 2026* {% hint style="info" %} Approval prompts are authorization controls, but they are weak when users are tired, rushed, or misled by injected instructions. Use approvals for meaningful decisions, and pair them with hard limits on tools, network access, files, and write actions. {% endhint %} ## Human-in-the-loop and approval policies: what security teams need to know AI agents often ask before they act. That approval step can be useful. It gives a person a chance to stop a risky command, a connector write, a file edit, a network request, or a privilege escalation. It also creates a record that a human accepted a boundary change. Approval is not a full security model. A user may not understand the tool call. A prompt injection can frame a malicious action as routine. A long session can create approval fatigue. A vague prompt such as "continue" can hide a meaningful change in access or side effects. Use approval policies to slow down actions that matter. Use RBAC, sandboxing, connector policy, network controls, and file controls to prevent actions that should not be available in the first place. ## Common human-in-the-loop and approval policies security failures * The platform asks for approval too often, so users accept without reading. * The approval text describes a command, but not the data it can expose or the system it can change. * A user approves a connector write action without understanding who can see the result. * An admin enables high-autonomy mode for convenience and leaves it on. * Prompt injection convinces an agent to request an action that looks normal in context. * Approval logs exist, but they are not tied to the business owner, ticket, or incident trail. ## Human-in-the-loop and approval policies security controls checklist * Define action classes: read-only, local write, external read, external write, network access, credential access, destructive action, and privilege escalation. * Require approval for external write actions, broad file writes, network access, command execution, credential access, and new tool or connector grants. * Block actions that the role should never perform, rather than asking users to reject them. * Use stricter approval rules for regulated data, source code, production systems, and customer-facing channels. * Keep approval prompts specific. The user should see the tool, target, data class, and side effect. * Monitor repeated approvals, denied approvals, and escalations from read-only to write modes. * Train users to stop when the prompt asks for an action unrelated to the original task. * Review high-autonomy configurations after incidents, vendor releases, and role changes. ## Anthropic ### Overview Claude Code documentation says the tool uses read-only permissions by default and prompts when additional actions are needed, including file edits and commands. It also describes controls for network-request approval, new MCP server trust, command injection detection, fail-closed matching, and organization managed settings. Command injection detection means suspicious bash commands require manual approval even if a matching rule was previously allowlisted, and fail-closed matching means unmatched commands default to requiring manual approval. Permission rules add the hard-limit layer: rules can allow, ask, or deny specific tool use, deny rules take precedence over ask and allow rules, and managed settings can enforce those rules organization-wide. Anthropic's Enterprise custom roles can also cap connector behavior. Connector or tool access can be always allowed, require approval, or be blocked. The organization-wide tool policy acts as a ceiling: role grants can narrow access inside that ceiling but cannot widen past it, and enforcement fails closed toward denial. Cowork and Claude Tag need surface-specific review. Cowork supports ask-before-acting for sensitive work. Claude Tag channel work uses shared, admin-provisioned service accounts and can run routines without a new prompt, so human review must be enforced in the connected system or workflow when an action is high impact. Limit who can invoke Claude Tag, narrow each Access bundle, disable DMs if personal connectors are out of scope, and keep standing work visible to channel owners. The practical pattern is to keep sensitive users on narrower roles, block tools that have no business need, and reserve always-allow settings for well-understood internal tools. ### Anthropic documentation * [Claude Code security](https://code.claude.com/docs/en/security) * [Configure permissions](https://code.claude.com/docs/en/permissions) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [Use Claude Cowork safely](https://support.claude.com/en/articles/13364135-use-claude-cowork-safely) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI's Codex approval documentation describes approval policies including read-only, workspace-write with on-request approvals, never, untrusted command approval, and granular policies that separately control sandbox approvals, MCP prompts, request-permission prompts, and skill approvals. Auto-review is a routing capability rather than a policy: it can send eligible approval requests through a reviewer agent instead of interrupting the user. Dangerous full access sits apart from all of these; it removes sandboxing and approvals and is not recommended. Codex managed configuration adds the enforcement layer, letting organizations set approval policy, sandbox behavior, and MCP-related settings centrally rather than leaving each developer to pick their own floor. OpenAI also documents Lockdown Mode for ChatGPT as a way to reduce prompt-injection data exfiltration risk by limiting outbound web and external-service access. In managed workspaces, Lockdown Mode is assigned through RBAC roles. OpenAI states that Lockdown Mode does not affect Codex network access, so Codex needs its own approval and sandbox policy. ChatGPT Work can draft, write, share, schedule, and execute through approved tools. OpenAI's Work admin guidance says higher-impact actions should combine human review with narrow roles, credentials, scopes, app action controls, and supported approvals; desktop Work follows the local Codex permission plane. ### OpenAI documentation * [Agent approvals & security](https://developers.openai.com/codex/agent-approvals-security) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Lockdown Mode](https://help.openai.com/en/articles/20001061) * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about human-in-the-loop and approval policies ### Which actions should always ask? Ask for external writes, broad file edits, command execution, network access from code, new connector grants, credential access, and any action that changes permissions or public visibility. ### When should an action be blocked instead of approved? Block it when the user has no legitimate business need for that action. Approval is useful for context-dependent risk. It is a poor substitute for role design. ### How do prompt injections affect approvals? Prompt injection can make a risky action look like part of the task. Approvals should show concrete side effects and should be backed by hard limits on tools, network paths, and write access. ### What is human-in-the-loop approval for AI agents? Human-in-the-loop approval is a control that asks a person to approve selected agent actions before they run. It works best for clear, high-impact actions with specific side effects. ### Should approval prompts be logged? Yes. Log the requested action, user decision, policy mode, tool, target system, timestamp, and final result. Approval history is useful during access reviews and incident response. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports competent, authorized human oversight. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports identity and access control. | | G.4 Colorado AI Act and the US state patchwork | Conditional: for covered Colorado ADMT, this supports meaningful human review by a person able to approve, modify, or override an outcome. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Access Controls 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 organizational oversight, approval authority, and documented exceptions. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA identity, authentication, least privilege, and workforce access. | *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 * [1. Identity & Access](/handbook/1.-identity-and-access) * [3.2 Approval policies and least-privilege autonomy](/handbook/3.-runtime-sandbox-and-autonomy/3.2-approval-policies-and-least-privilege-autonomy) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) * [2.6 AI hooks: inference controls and lifecycle automation](/handbook/2.-supply-chain-and-extensibility/2.6-ai-hooks-inference-controls-and-lifecycle-automation) # 2. Supply Chain & Extensibility How to govern connectors, MCP servers, plugins, skills, extensions, hooks, and agent frameworks as a software supply chain with real attack surface. *Last reviewed: August 18, 2026* {% hint style="info" %} Every connector, MCP server, plugin, skill, and hook is a software dependency with real attack surface. Treat the AI extension ecosystem the same way you treat third-party code — with intake, review, allowlisting, and owner accountability. {% endhint %} ## Articles in this section 1. [2.1 Connectors and apps: the integration backbone](/handbook/2.-supply-chain-and-extensibility/2.1-connectors-and-apps-the-integration-backbone) 2. [2.2 MCP servers: securing the protocol](/handbook/2.-supply-chain-and-extensibility/2.2-mcp-servers-securing-the-protocol) 3. [2.3 MCP gateways and allowlisting](/handbook/2.-supply-chain-and-extensibility/2.3-mcp-gateways-and-allowlisting) 4. [2.4 Analyzing skills for risk](/handbook/2.-supply-chain-and-extensibility/2.4-analyzing-skills-for-risk) 5. [2.5 Plugins and marketplaces](/handbook/2.-supply-chain-and-extensibility/2.5-plugins-and-marketplaces) 6. [2.6 AI hooks: inference controls and lifecycle automation](/handbook/2.-supply-chain-and-extensibility/2.6-ai-hooks-inference-controls-and-lifecycle-automation) 7. [2.7 The supply-chain review workflow](/handbook/2.-supply-chain-and-extensibility/2.7-the-supply-chain-review-workflow) 8. [2.8 Signing and packaging](/handbook/2.-supply-chain-and-extensibility/2.8-signing-and-packaging) 9. [2.9 SaaS agent-building supply-chain](/handbook/2.-supply-chain-and-extensibility/2.9-saas-agent-building-supply-chain) 10. [2.10 Hosted-agent framework dependencies](/handbook/2.-supply-chain-and-extensibility/2.10-hosted-agent-framework-dependencies) ## Frequently asked questions **What belongs in the AI supply-chain register?**\ Record every connector, MCP server, skill, plugin, hook, model, SDK, container, template, and agent framework with its owner, source, version, permissions, data reach, review date, and update trigger. Include components supplied through marketplaces and repositories. **When must an extension be reviewed again?**\ Review after a material permission, owner, source, version, signing, tool, dependency, or update-channel change. Re-run the review after incidents and when a component begins handling a new data class or production action. ## Related handbook guidance * [AI Security Handbook](/) * [5.3 Supply chain attacks and notable CVEs](/handbook/5.-threats-and-adversarial/5.3-supply-chain-attacks-and-notable-cves) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) * [Security Team Checklist](/start-here/security-team-checklist) # 2.1 Connectors and apps: the integration backbone Every connector is standing authenticated access to a real system — how to approve, scope, monitor, and review them. *Last reviewed: August 18, 2026* {% hint style="info" %} Connectors turn an AI tool into an authenticated user of other systems. Approve them like standing access, scope them like privileged integrations, and review them like SaaS apps. {% endhint %} ## Connectors and apps: what security teams need to know A connector is an access path, not a convenience toggle. Once connected, the AI tool can read from or act inside another system under a user, bot, or service account identity. The risk depends on the connected system, the granted scopes, the action types, and the way prompts or tool results can influence the agent. Read-only calendar access and the ability to send messages to a customer channel are different control decisions. Use "connector" as the security umbrella when writing controls. Vendor terms change, but the control questions stay stable: what system is connected, who authorized it, what data can it reach, what actions can it take, and where is the evidence? Review the integration by access path, not by product label alone. A built-in app, OAuth connector, MCP server, plugin, desktop extension, or custom integration can create the same governance problem if it gives an AI tool standing access to another system. ## Common connectors and apps security failures * A connector is approved because the brand is trusted, while the OAuth scopes are never reviewed. * Read and write actions are bundled into the same approval path. * A user can connect a personal app account to a managed AI workspace. * Connector grants survive team moves or vendor pilots. * Security reviews the AI platform but not the connected SaaS logs. ## Connectors and apps security controls checklist * Create an intake record for every connector, including owner, data class, scopes, action types, and review date. * Default to read-only where the workflow allows it. * Separate approval for write actions such as sending messages, creating tickets, changing records, or publishing files. * Block connectors that have no business owner or no revocation path. * Review OAuth grants and connected app logs alongside AI platform logs. ## Anthropic ### Overview Anthropic-specific implementation starts with Claude connectors across web, desktop, mobile, Cowork, and Claude Code. Review whether each connector is remote or local, who can add it, what it can read or write, and whether Team or Enterprise policy requires approval or blocks specific tools. Cowork remote sessions can use remote connectors on any supported surface, but local connectors still run through the Claude Desktop app and require that device to be online. For Claude Code, translate connector governance into MCP and extension governance: managed settings, permission rules, MCP configuration, hooks, plugins, skills, data handling, and monitoring. Use both the Claude connector docs and the Claude Code docs to verify which controls exist for the product surface in scope. Claude Tag introduces a shared connector model inside Slack. Channel sessions use organization-provisioned service accounts and Access bundles, while direct messages use the individual's Claude account and personal connectors. A channel connection is shared authority for everyone in the covered scope, so review it as an agent service account rather than a collection of user grants. ### Naming and access by surface * Claude web, Claude Desktop, Claude Mobile, and Claude Cowork call the user-facing integrations connectors. Users browse and manage them through the Connectors Directory or connector settings. * Remote connectors are the default for cloud services and work across Claude web, mobile, Cowork, Desktop, Claude Code, and the API via the MCP Connector. * Desktop extensions package local MCP servers and are specific to Claude Desktop and Claude Code. They are the right path for local files, localhost services, desktop apps, or OS-level access. * Claude Code usually exposes the same category of risk through MCP servers, managed settings, plugins, skills, and hooks. Organization connector permissions can apply to Claude Code, but locally run MCP servers still need Claude Code managed-settings control. ### 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-claude-s-capabilities) * [When to use desktop and web connectors](https://support.claude.com/en/articles/11725091-when-to-use-desktop-and-web-connectors) * [Getting Started with Local MCP Servers on Claude Desktop](https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop) * [Build custom connectors via remote MCP servers](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp) * [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 Code MCP](https://code.claude.com/docs/en/mcp) * [Claude Code hooks](https://code.claude.com/docs/en/hooks) * [Claude Code plugins](https://code.claude.com/docs/en/plugins) * [Claude Code skills](https://code.claude.com/docs/en/skills) * [Claude Code data usage](https://code.claude.com/docs/en/data-usage) * [API and data retention](https://platform.claude.com/docs/en/manage-claude/api-and-data-retention) * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [How Claude Tag agent identity works](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) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI-specific implementation starts with apps, the integrations that connect ChatGPT to external data and actions. Since July 9, 2026, users discover workflow packages through the Plugin Directory; admins still govern the underlying integrations through app access, RBAC, action controls, approvals, sync controls, custom MCP app review, and source-system permissions. Plugins now span ChatGPT Work and Codex. They can package skills, apps, app templates, and MCP-backed capabilities; a visible or installed plugin does not grant data access unless the underlying app is enabled and the user has source-system permission. Also review Codex-specific sandboxing, MCP configuration, managed configuration, approvals, governance exports, API data controls, and workload identity when the workflow enters Codex. ### Naming and access by surface * ChatGPT now calls connectors apps. OpenAI renamed connectors to apps on December 17, 2025; the term includes interactive apps, search/file-search apps, deep research apps, synced apps, and apps with write actions. * Apps are governed through ChatGPT workspace settings and RBAC. Work can use approved plugins and apps on web, mobile, and desktop, subject to plan and workspace settings. * Custom ChatGPT apps are the successor to custom connectors. They are built on MCP, and OpenAI documents the full MCP developer-mode path for ChatGPT web on Business, Enterprise, and Edu. * The Plugin Directory is the discovery layer for Work and Codex. A plugin can include skills, apps, app templates, and MCP servers. If it depends on an app, the app's workspace settings still control access, actions, sync, domain restrictions, and approval behavior. * The ChatGPT desktop app combines Chat, Work, and Codex. Codex mode, CLI, and IDE workflows can also use direct MCP server configuration, so distinguish direct MCP configuration from app-backed plugins. ### OpenAI documentation * [Apps in ChatGPT](https://help.openai.com/en/articles/11487775-apps-in-chatgpt) * [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) * [Developer mode and MCP apps in ChatGPT](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275) * [ChatGPT desktop app](https://learn.chatgpt.com/docs/app) * [Apps SDK MCP](https://developers.openai.com/apps-sdk/concepts/mcp-server) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [Codex MCP](https://developers.openai.com/codex/mcp) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) * [Data controls in the OpenAI platform](https://developers.openai.com/api/docs/guides/your-data) * [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) * [Workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about connectors and apps ### What makes AI connectors risky? A connector gives an AI tool such as Claude or ChatGPT standing, authenticated access to another system, so the risk is no longer limited to what a user types into a chat. Exposure depends on the OAuth scopes granted, whether the connector can take write actions like sending messages or changing records, the sensitivity of reachable data, and whether prompt injection can steer the tool into unintended calls. Treat each connector as a standing integration, not a chat feature. ### Should connector access be approved by security or the app owner? Both. The app owner understands what the data means and how the integration is used day to day; security owns the access standard, the risk classification, and the exception process. A workable split: the app owner sponsors and validates business need, security approves scopes and write actions, and both names go in the intake record. ### Are read-only connectors safe? Read-only is meaningfully safer than write-enabled access, but not safe by default. A read-only connector can still pull sensitive records into prompts, model outputs, logs, and shared artifacts, where the source system's access controls no longer apply. Classify read-only connectors by the data they can reach, and review them like any other data export path. ### How often should connector grants be reviewed? Review high-risk connectors, meaning anything with write actions or regulated data, quarterly and after major vendor changes such as OpenAI's December 2025 rename of ChatGPT connectors to apps, which moved where the settings live. Review low-risk read-only connectors at least twice a year. Re-review immediately when scopes change, the owner leaves, or the vendor adds new action types. ### What evidence should auditors expect for AI connectors? For each connector, an auditor should be able to see the named owner, granted scopes, approval date and approver, the users or groups with access, the data classification, the last review date, and the documented revocation path. Where the platform exposes connector or app activity in admin logs, sample it against the approval record to confirm reality matches the register. ## 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 ICT asset, dependency, and third-party risk management. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies, Inference Security, 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA approved vendors, business-associate review, data paths, and tool authorization. | *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 * [2. Supply Chain & Extensibility](/handbook/2.-supply-chain-and-extensibility) * [2.2 MCP servers: securing the protocol](/handbook/2.-supply-chain-and-extensibility/2.2-mcp-servers-securing-the-protocol) * [2.3 MCP gateways and allowlisting](/handbook/2.-supply-chain-and-extensibility/2.3-mcp-gateways-and-allowlisting) * [1.6 API keys and service accounts governance](/handbook/1.-identity-and-access/1.6-api-keys-and-service-accounts-governance) * [5.2 Data exfiltration via tools and connectors](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors) # 2.2 MCP servers: securing the protocol Local and remote MCP servers are both attack surfaces — treat every server like a software dependency with permissions and update risk. *Last reviewed: August 18, 2026* {% hint style="info" %} MCP standardizes how AI tools reach external systems. Treat every MCP server as a software dependency, an access grant, and a prompt-injection surface. {% endhint %} ## MCP servers: what security teams need to know MCP lets AI clients connect to tools, resources, prompts, and workflows exposed by servers. That standardization is useful because teams can reuse integrations across clients. It also makes MCP a supply-chain boundary. Local MCP servers can run with the user's local privileges. Remote MCP servers shift the risk to authorization, token handling, network exposure, and server ownership. In both cases, tool metadata and tool results become part of the agent's decision context. ## Common MCP servers security failures * A developer adds a local MCP server from a repository without reviewing what it executes. * A remote MCP server receives broad OAuth scopes and has no owner. * Tool descriptions are trusted even though MCP guidance treats them as untrusted unless the server is trusted. * MCP servers are allowed by name but not by version, source, or scope. * Logs show the agent called a tool, but not what external system was reached. ## MCP servers security controls checklist * Maintain an MCP allowlist with owner, source, version, transport, scopes, and review date. * Prefer remote servers with explicit authorization and narrow tokens when local process access is not required. * Review server source, package provenance, and update behavior before approval. * Restrict tool calls by server and tool name, rather than relying on whether MCP is enabled. * Log tool name, server, input parameters, target system, and result status. ## Anthropic ### Overview For MCP protocol review, Anthropic-specific implementation depends on where the MCP server is reached from. Claude web, Claude Desktop, Claude Mobile, Cowork, Claude Code, and the Claude API do not all use the same MCP path. Remote connectors are the default for cloud services and can work across Claude surfaces. Claude Desktop extensions and local MCP run locally and are specific to Claude Desktop and Claude Code. The Claude API MCP connector reaches remote HTTP MCP servers from the Messages API and supports toolset-level enablement, allowlisting, denylisting, per-tool configuration, and OAuth bearer tokens. Treat those as separate review paths, because local STDIO access, remote OAuth access, and API-hosted tool calls have different logs and enforcement points. ### Anthropic documentation * [Tool use with Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview) * [MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector) * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [When to use desktop and web connectors](https://support.claude.com/en/articles/11725091-when-to-use-desktop-and-web-connectors) * [Getting Started with Local MCP Servers on Claude Desktop](https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop) * [Claude Code MCP](https://code.claude.com/docs/en/mcp) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Code permissions](https://code.claude.com/docs/en/permissions) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI-specific MCP review spans ChatGPT apps, custom MCP apps, the Apps SDK, Codex, and direct API tool use. ChatGPT exposes user-facing integrations as apps. Custom ChatGPT apps are MCP-backed, while Apps SDK apps expose tools and optional UI components through an MCP server. Codex can use MCP through plugins or direct MCP configuration shared across Codex in the ChatGPT desktop app, the CLI, and the IDE extension. The OpenAI API also exposes remote MCP servers and other tools through the `tools` parameter. Review should separate ChatGPT app governance, plugin packaging, Codex MCP governance, and API tool governance because each surface has different enablement, authentication, sandboxing, and audit paths. ### OpenAI documentation * [Apps in ChatGPT](https://help.openai.com/en/articles/11487775-apps-in-chatgpt) * [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) * [Developer mode and MCP apps in ChatGPT](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt) * [Apps SDK MCP](https://developers.openai.com/apps-sdk/concepts/mcp-server) * [Using tools](https://developers.openai.com/api/docs/guides/tools) * [Codex MCP](https://developers.openai.com/codex/mcp) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about MCP servers ### What is an MCP server? An MCP server exposes tools, resources, and prompts to AI clients through the Model Context Protocol, the open standard used by Claude, ChatGPT, Codex, and many other AI tools. Because one server can be reused across clients, it acts as a shared integration layer, which also makes it a shared supply-chain and access boundary. Treat each server as a software dependency, an access grant, and a prompt-injection surface at the same time. ### Are local MCP servers more dangerous than remote MCP servers? They carry different risks rather than strictly more or less. A local server runs on the user's machine and can inherit local file, process, and network access, so a malicious package compromises the endpoint. A remote server shifts the risk to authorization: OAuth scopes, token handling, server ownership, and network exposure. Review local servers like installed software and remote servers like SaaS integrations. ### Can MCP tool descriptions be trusted? Only when the server itself is trusted. The MCP specification treats tool descriptions and annotations as untrusted unless they come from a trusted server, because a malicious server can embed instructions in the metadata the model reads. Pin tool definitions at review time and alert when they change. ### What should an MCP security review include? At minimum: the server's owner, source repository, version, transport (local STDIO or remote HTTP), requested scopes and secrets, logging behavior, update path, and the exact tools it exposes, including which ones write or execute code. The review should end with an allowlist entry, not just an approval email. ### What tools help with MCP server review? Static analysis, dependency and package-provenance scanning, Semgrep rules, and MCP-specific scanners can surface obvious problems such as credential harvesting or dangerous shell calls. They are a floor, not a substitute: ownership, scope, and update review still decide whether a server belongs on the allowlist. ## 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 ICT asset, dependency, and third-party risk management. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies, Inference Security, 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.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 * [2. Supply Chain & Extensibility](/handbook/2.-supply-chain-and-extensibility) * [2.3 MCP gateways and allowlisting](/handbook/2.-supply-chain-and-extensibility/2.3-mcp-gateways-and-allowlisting) * [2.1 Connectors and apps: the integration backbone](/handbook/2.-supply-chain-and-extensibility/2.1-connectors-and-apps-the-integration-backbone) * [5.4 Agent-specific threats: tool poisoning and confused deputy](/handbook/5.-threats-and-adversarial/5.4-agent-specific-threats-tool-poisoning-and-confused-deputy) * [5.3 Supply chain attacks and notable CVEs](/handbook/5.-threats-and-adversarial/5.3-supply-chain-attacks-and-notable-cves) # 2.3 MCP gateways and allowlisting How to centralize which MCP servers exist and who can reach them so users cannot freely add unreviewed tools. *Last reviewed: August 18, 2026* {% hint style="info" %} An MCP gateway gives security teams one place to decide which servers exist, which tools are exposed, and which users or agents can reach them. {% endhint %} ## MCP gateways and allowlisting: what security teams need to know MCP adoption often starts locally. A developer adds one server for GitHub, another for tickets, and a third for an internal database. That works for experimentation, but it does not scale as a control model. A gateway or centrally managed allowlist moves MCP governance from individual configuration files into an owned service or policy layer. The goal is to make unmanaged MCP the exception, not the path of least resistance. ## Common MCP gateways and allowlisting security failures * Users can add any MCP server while security believes there is an allowlist. * The allowlist names a server but does not restrict the tools inside it. * Policy exists for laptops but not CI or remote agent runs. * A gateway brokers access but does not log tool inputs and outcomes. * Server updates change tool behavior without a new review. ## MCP gateways and allowlisting security controls checklist * Use managed settings or gateway policy to restrict MCP servers to an approved list. * Control tools inside each server, especially tools that write, execute code, or reach sensitive data. * Record server owner, version, scopes, authentication method, and review cadence. * Apply policy consistently to desktop, CLI, IDE, cloud, and CI agent runs. * Export MCP tool-call events to the audit pipeline. ## Anthropic ### Overview Anthropic allowlisting is enforced in a different place on each surface, so decide where policy lives before buying or building a gateway. For Claude web, Desktop, mobile, and Cowork, Team and Enterprise owners control which connectors are enabled, and Enterprise connector permissions can require approval for, block, or always allow specific connectors. Desktop extensions have their own controls: owners can enable or disable public extensions, upload custom extensions, and apply enterprise policy that overrides in-app allowlist and blocklist settings. For Claude Code, managed settings are the enforcement point. They can restrict MCP servers, plugins, hooks, and permission rules, and deny rules take precedence over ask and allow rules. For API-built agents, the MCP connector supports toolset-level enablement, tool allowlists and denylists, and per-tool configuration. A gateway complements these native controls by adding brokered access and centralized logging; it does not replace the review record behind each approval. Claude Tag channel sessions have another native gateway: every outbound HTTP or HTTPS request crosses Agent Proxy. The proxy injects a stored credential only when a request matches its rule, permits credential-free requests only to allowed hosts, and blocks unmatched destinations. Review the connection's allowed websites, the Access bundle's Domains list, and the session environment's network setting together. A fresh environment can inherit Anthropic's Trusted host set, so default-deny at the proxy does not mean that only organization-added domains are reachable. ### 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-claude-s-capabilities) * [When to use desktop and web connectors](https://support.claude.com/en/articles/11725091-when-to-use-desktop-and-web-connectors) * [Getting Started with Local MCP Servers on Claude Desktop](https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop) * [MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector) * [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 Code MCP](https://code.claude.com/docs/en/mcp) * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI allowlisting also splits by surface. In ChatGPT, workspace app controls decide which apps are available, action controls decide whether an app can read only, take actions, or use a custom set of actions, and custom roles gate app access by group. Custom MCP apps require workspace controls and review before their actions are exposed to users. For Codex, managed configuration is the allowlist mechanism: admin-enforced requirements can constrain approval policies, sandbox behavior, and MCP-related settings. Codex in the ChatGPT desktop app, the CLI, and the IDE extension share MCP settings, so one policy decision covers all three. The API Platform is a separate control plane with its own keys, service accounts, workload identity, and data controls. Wherever a gateway sits, route its allow, deny, and approval decisions into the same audit pipeline as Codex governance exports. ### OpenAI documentation * [Apps in ChatGPT](https://help.openai.com/en/articles/11487775-apps-in-chatgpt) * [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) * [Developer mode and MCP apps in ChatGPT](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [Codex MCP](https://developers.openai.com/codex/mcp) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) * [Data controls in the OpenAI platform](https://developers.openai.com/api/docs/guides/your-data) * [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) * [Workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about MCP gateways and allowlisting ### What is an MCP gateway? An MCP gateway is a broker that sits between AI clients and MCP servers, centralizing which servers exist, which tools inside them are exposed, and which users or agents can reach them. It turns per-laptop configuration files into an owned policy layer with one audit trail. Native controls such as Claude Code managed settings, the Claude API MCP connector's toolsets, and Codex managed configuration cover much of this without a gateway, so pick the enforcement point deliberately. ### Is an allowlist enough to govern MCP? A list of server names is not. The allowlist needs source, version, owner, transport, authentication method, scopes, and the specific exposed tools, because a server update can change tool behavior while the name stays the same. Pair the list with tool-call logging so you can prove what was actually reached. ### Should users be able to add their own MCP servers? Only in designated sandbox or research groups with no production data access. For production groups, restrict server addition through managed settings in Claude Code, managed configuration in Codex, or a gateway, and route new-server requests through the supply-chain intake instead. ### What should be logged for MCP tool calls? Log the server, tool name, user or agent identity, input classification, target system, result status, and whether the call was allowed, denied, or escalated for approval. Denied and escalated calls are the most valuable signal, because they show where policy and real usage disagree. ### How often should MCP allowlists be reviewed? Review high-risk servers quarterly, after every server update, and whenever scopes or tool behavior change. Treat a tool-description change as a review trigger in its own right, since MCP guidance treats tool metadata as untrusted unless the server is trusted. ## 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 ICT asset, dependency, and third-party risk management. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies, Inference Security, 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.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 * [2. Supply Chain & Extensibility](/handbook/2.-supply-chain-and-extensibility) * [2.2 MCP servers: securing the protocol](/handbook/2.-supply-chain-and-extensibility/2.2-mcp-servers-securing-the-protocol) * [1.2 RBAC across AI platforms](/handbook/1.-identity-and-access/1.2-rbac-across-ai-platforms) * [6.5 Routing AI telemetry to your SIEM](/handbook/6.-observability-audit-and-evidence/6.5-routing-ai-telemetry-to-your-siem) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) # 2.4 Analyzing skills for risk Skills and instruction bundles can encode trusted behavior — how to review the full package, dependencies, permissions, and sharing path before use. *Last reviewed: August 18, 2026* {% hint style="info" %} A skill is instruction that loads on demand. Review the instruction file, the supporting files, the scripts, and the sharing path before treating it as trusted. {% endhint %} ## Analyzing skills for risk: what security teams need to know Skills package repeatable instructions and resources so an agent can perform a task more reliably. That makes them useful for teams, but it also makes them a supply-chain object. The main risk is that a skill can shape the agent's behavior when the user is focused on the task, not the trust boundary. Supporting files and scripts raise the stakes because the risky content may not sit in the top-level instruction file. ## Common analyzing skills for risk security failures * A reviewer reads SKILL.md but misses scripts or templates in the same directory. * A broad skill description makes the skill activate during unrelated tasks. * A user-shared skill becomes an unreviewed team standard. * A plugin bundles a skill and a hook, but only the skill text is reviewed. * Skill authors can pre-approve tools without a security review. ## Analyzing skills for risk security controls checklist * Review the full skill directory, including scripts, examples, templates, and references. * Require owner, source, version, purpose, activation description, and review date. * Restrict who can publish skills to team or organization scopes. * Block or review pre-approved tool access inside skills. * Test skill activation with safe prompts and abuse prompts before approval. ## Anthropic ### Overview Anthropic's skill surface is Agent Skills. A skill is an organized folder of instructions, scripts, and resources; in Claude Code it is a SKILL.md file with frontmatter that can include supporting files, dynamic context, and pre-approved tools, scoped as personal, project, enterprise, or plugin-provided. Cowork can use skills and plugins across desktop, web, and mobile remote sessions, while local components still require the desktop app. On the API, skills execute through the code execution environment, can be pinned to specific versions, and require the relevant beta headers. Anthropic publishes enterprise guidance for exactly this review: check scripts, adversarial instructions, MCP references, network access, hardcoded credentials, filesystem scope, and tool invocations before deployment. Enterprise custom roles can control whether users have the skills capability at all, and pre-approved tool access inside a skill deserves the same scrutiny as a permission rule. Treat plugin-delivered skills as part of plugin review (see 2.5). Claude Tag channel behavior can include standing instructions and plugins in addition to channel memory. Review those instructions and plugin contents before attaching broad Access bundles, because everyone in the channel receives the same agent capabilities even when different people initiate the work. ### Anthropic documentation * [Skills for enterprise](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/enterprise) * [Using Agent Skills with the API](https://platform.claude.com/docs/en/build-with-claude/skills-guide) * [Claude Code skills](https://code.claude.com/docs/en/skills) * [Claude Code plugins](https://code.claude.com/docs/en/plugins) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [How Claude Tag agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI skills can run in ChatGPT Work and Codex. They are reusable instructions with optional references and helper scripts, often delivered inside plugins. The Plugin Directory spans Work on the web, Work or Codex in the ChatGPT desktop app, and supported Codex clients. Review a bundled skill with the plugin that carries it, and remember that skill files can point at scripts the top-level instructions never mention. Codex granular approval policies include skill approvals, so approval policy is part of the skill control set, and managed configuration can constrain what users are able to weaken. In ChatGPT managed workspaces, RBAC permissions include skills, so role design decides who can use them. Keep skill review separate from app review: an app grants access to a system, while a skill shapes agent behavior, and one plugin can carry both. ### OpenAI documentation * [Codex skills](https://developers.openai.com/codex/skills) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [Plugins](https://learn.chatgpt.com/docs/plugins) * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [RBAC](https://help.openai.com/en/articles/11750701-rbac) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about analyzing skills for risk ### What is an AI skill? A skill is a packaged set of instructions and optional supporting files that an AI agent loads when a task matches its description or when a user invokes it. Anthropic's Agent Skills use a SKILL.md file with frontmatter plus scripts and resources; Codex skills are reusable instructions with optional references and helper scripts, often distributed inside plugins. Either way, a skill is supply-chain content that shapes agent behavior on demand. ### Why are AI skills a security risk? A skill activates while the user is focused on the task, not the trust boundary, and it can carry more than instructions: bundled scripts, templates, references to MCP tools, and on some platforms pre-approved tool access. Review skills as both code and prompt material, because the risky content often sits in the supporting files rather than the top-level instruction text. ### What should a skill review include? The full skill directory: the instruction file, every script and template, tool permissions or pre-approvals, activation language, network access, hardcoded credentials, and filesystem scope, plus the owner, source, and sharing scope. Anthropic's enterprise skill guidance lists this same review surface, including adversarial instructions and MCP references. ### Who should be allowed to publish skills? Restrict team- and organization-wide publishing to a reviewed author group, and gate the capability itself where the platform allows it: Claude Enterprise custom roles can control skill creation and sharing, and ChatGPT RBAC includes a skills permission. Personal skills can stay open for low-risk experimentation as long as they cannot reach production groups unreviewed. ### How should skills be monitored? Track creation, updates, activation, tool use, and sharing events wherever the platform exposes them, and treat a skill update as a new skill for review purposes. For plugin-delivered skills, monitor the plugin version too: an update can swap a skill's contents without the name changing. ## 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 ICT asset, dependency, and third-party risk management. | | 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.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 * [2. Supply Chain & Extensibility](/handbook/2.-supply-chain-and-extensibility) * [2.5 Plugins and marketplaces](/handbook/2.-supply-chain-and-extensibility/2.5-plugins-and-marketplaces) * [2.7 The supply-chain review workflow](/handbook/2.-supply-chain-and-extensibility/2.7-the-supply-chain-review-workflow) * [5.3 Supply chain attacks and notable CVEs](/handbook/5.-threats-and-adversarial/5.3-supply-chain-attacks-and-notable-cves) * [4.7 Secrets and credential hygiene in prompts and tools](/handbook/4.-data-protection-and-residency/4.7-secrets-and-credential-hygiene-in-prompts-and-tools) # 2.5 Plugins and marketplaces Plugins and marketplaces bundle skills, connectors, agents, extensions, and actions — how to curate distribution and review updates like code. *Last reviewed: August 18, 2026* {% hint style="info" %} Plugins can bundle more than one kind of power. Review them as packages, not as labels in a marketplace. {% endhint %} ## Plugins and marketplaces: what security teams need to know Plugins make AI tools extensible. They can distribute skills, hooks, MCP servers, agents, commands, and other configuration. That packaging is useful because it gives teams a repeatable delivery path. The same packaging creates a supply-chain risk. A plugin update can change instructions, add a hook, alter an MCP server, or shift permissions. Marketplace trust should start the review, not end it. ## Common plugins and marketplaces security failures * A plugin is approved by name, then a later update adds new behavior. * Marketplace source and repository source are not compared. * Users can add unknown marketplaces. * A plugin bundles hooks or MCP servers that were not part of the original review. * No one owns plugin retirement when the business use ends. ## Plugins and marketplaces security controls checklist * Maintain an approved plugin list with owner, marketplace, source repository, version, and review date. * Use private or known marketplaces where the platform supports it. * Review bundled skills, hooks, MCP servers, agents, and commands as separate risk objects. * Require signed releases, protected branches, or comparable provenance controls for internal plugins. * Review plugin updates before rollout to production groups. ## Anthropic ### Overview Anthropic plugins can be used from Claude Code and Cowork. Packages can bundle skills, agents, hooks, MCP servers, commands, and other customization, while Cowork makes supported skills and plugins available across desktop, web, and mobile. Local MCP components still depend on Claude Desktop. Because one plugin can carry several kinds of power, review each component on its own terms. Enterprise managed settings can restrict which plugins and marketplaces are available, so production groups can be limited to a private or approved marketplace while sandbox groups experiment more freely. Record the marketplace source and the plugin's source repository separately: a marketplace listing is a distribution path, not provenance. Claude Tag can also use plugins as part of its channel-side configuration. That configuration is separate from the channel's service-account identity and Access bundles, so approve the plugin and the connected authority as two linked objects. A safe plugin with an over-broad bundle can still create an unsafe agent. ### Anthropic documentation * [Claude Code plugins](https://code.claude.com/docs/en/plugins) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Code skills](https://code.claude.com/docs/en/skills) * [Claude Code hooks](https://code.claude.com/docs/en/hooks) * [Claude Code MCP](https://code.claude.com/docs/en/mcp) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [How Claude Tag agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) ## OpenAI ### Overview The Plugin Directory is now the packaging and discovery layer across ChatGPT Work and Codex. Plugins bundle skills, apps, app templates, and MCP-backed capabilities into reusable workflows. Users can install them from Work on the web, Work or Codex in the ChatGPT desktop app, the Codex CLI browser, or the IDE extension. Teams can also publish through approved marketplace sources, which is where provenance and update review belong. A plugin does not grant data access by itself: bundled apps still follow ChatGPT workspace app settings and source-system permissions, and existing Codex approval settings apply to plugin workflows. Two review details matter in practice: plugins can prompt users to connect or sign in to apps at install time or on first use, and uninstalling a plugin leaves bundled apps installed in ChatGPT until they are removed there. ### OpenAI documentation * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [Plugins](https://learn.chatgpt.com/docs/plugins) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) * [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) * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about plugins and marketplaces ### What is an AI plugin? An AI plugin is an installable package that extends an AI client with several kinds of capability at once: skills, MCP servers, app integrations, agents, commands, or hooks. Claude Code plugins and Codex plugins both follow this model and are distributed through marketplaces. The security consequence is that one install can grant instructions, tools, and execution paths in a single step. ### Are marketplace plugins safe by default? No. A marketplace listing is a discovery and distribution path, not a security review, and even curated listings tell you who published, not what the current version does. Compare the marketplace source against the actual source repository, review each bundled component, and re-review on update. ### What should be reviewed inside a plugin? Every bundled component as its own risk object: skills (instructions and scripts), hooks (code execution at lifecycle events), MCP servers (standing tool access), agents, commands, requested permissions, install-time prompts such as app sign-ins, and update behavior. A plugin approval that only read the description has reviewed the label, not the package. ### Should companies run a private plugin marketplace? For production use, yes, where the platform supports it: Claude Code marketplaces can be restricted through managed settings, and Codex teams can publish through their own repo or team marketplace sources. Private distribution gives security a controlled approval path, version pinning, and a known rollback point. ### How often should plugins be reviewed? Review high-risk plugins before every version update reaches production groups, since an update can add hooks or MCP servers that were not in the original review. Lower-risk plugins can ride a fixed cadence, with immediate re-review when distribution, permissions, or bundled apps change. One gotcha worth building into offboarding: uninstalling a Codex plugin leaves its bundled apps installed in ChatGPT until they are removed there. ## 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 ICT asset, dependency, and third-party risk management. | | 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.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 * [2. Supply Chain & Extensibility](/handbook/2.-supply-chain-and-extensibility) * [2.4 Analyzing skills for risk](/handbook/2.-supply-chain-and-extensibility/2.4-analyzing-skills-for-risk) * [2.7 The supply-chain review workflow](/handbook/2.-supply-chain-and-extensibility/2.7-the-supply-chain-review-workflow) * [5.3 Supply chain attacks and notable CVEs](/handbook/5.-threats-and-adversarial/5.3-supply-chain-attacks-and-notable-cves) * [2.10 Hosted-agent framework dependencies](/handbook/2.-supply-chain-and-extensibility/2.10-hosted-agent-framework-dependencies) # 2.6 AI hooks: inference controls and lifecycle automation How AI hooks work, which products support them, how Anthropic's inference hooks differ from lifecycle hooks, and how to use hooks for narrow control and useful runtime evidence. *Last reviewed: August 18, 2026* {% hint style="info" %} Hooks can give you control and visibility, but only at the lifecycle points they actually cover. Treat every hook as code execution. {% endhint %} ## Two different things called "hooks" Anthropic uses the word "hooks" for two unrelated capabilities. They sit at different layers, are configured by different people, and solve different problems. Confusing them leads to wrong assumptions about what is covered. **Inference hooks** are an organization-level security control for Claude Enterprise. An admin configures a single HTTPS endpoint, and every governed prompt passes through it before it reaches the model, across Claude.ai, Cowork, and Claude Code. Anthropic sends the conversation transcript to your security endpoint, and you return an allow or deny verdict (default timeout: 5 seconds). A denied prompt never reaches the model; the user sees a policy-blocked message. Three modes: off, shadow (log only), and enforcing. Configuration requires `organization:manage` permission in Claude Platform Admin settings. This is the layer for DLP, compliance, and org-wide prompt governance. **Lifecycle hooks** are local automation inside Claude Code and the Agent SDK. They fire at specific agent-loop events such as PreToolUse, PostToolUse, SessionStart, and UserPromptSubmit, and run commands or callbacks that can block, modify, or log individual tool calls. They are configured in settings files, managed policy, plugins, or SDK callbacks. This is the layer for tool-level policy and runtime evidence. | | Inference hooks | Lifecycle hooks | | ----------------- | ------------------------------------------------- | ---------------------------------------------------------------- | | **Scope** | Whole organization, every governed Claude surface | Individual Claude Code / Agent SDK sessions | | **Fires** | Before inference, on each submitted prompt | At agent events: before/after tool calls, session start and stop | | **Decision** | Allow or deny the entire prompt | Block, modify, or log a specific tool call | | **Configured by** | Org admin in Claude Platform Admin settings | `settings.json`, managed settings, plugins, SDK callbacks | | **Best for** | DLP, compliance, org-wide prompt governance | Command-level policy, approvals, runtime telemetry | The simplest way to hold it: inference hooks gate the entire prompt at the org level before the model runs; lifecycle hooks control specific tool calls and events within a session. The rest of this page covers lifecycle hooks. Inference hooks are documented separately: see Anthropic's [Inference hooks overview](https://platform.claude.com/docs/en/manage-claude/inference-hooks) and the [configuration guide](https://platform.claude.com/docs/en/manage-claude/inference-hooks-configuration). ## The short version Lifecycle hooks are commands, HTTP calls, prompts, or tool calls that run automatically at defined moments in an AI session. Common trigger points include session start, user prompt submission, before a tool runs, when an approval is requested, after a tool runs, and when a turn stops. Hooks give you **control** when they run before an action and can block, deny, require approval, or change the context. Hooks give you **visibility** when they log events, enrich telemetry, send notifications, or record policy decisions after something happens. They are also a direct execution path. A hook stored in a repository, plugin, skill, or local config can run in the same sensitive moment as the agent. That makes hooks useful, but not casual. They belong in version control, code review, managed settings, and monitoring. ## What hooks give you | Use | Control or visibility | Examples | | ------------------ | --------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | Pre-action policy | Control | Block risky shell commands, force approval for production targets, stop writes to sensitive paths, deny unapproved network calls. | | Approval shaping | Control | Require a ticket, classify the action, or force a human prompt before a tool can run. | | Context injection | Control | Add approved policy context, project metadata, data classification, or environment hints at session start. | | Runtime logging | Visibility | Record tool name, target, working directory, command hash, rule ID, decision, and result. | | Notifications | Visibility | Send high-risk events to a queue, case system, Slack channel, or SIEM path. | | Post-action review | Visibility | Capture tool result metadata, failures, denials, and policy outcomes after the action completes. | The important limit: post-action hooks cannot prevent the action that already ran, and pre-action hooks only cover the tools and paths the product routes through that hook system. Use hooks with sandboxing, approvals, MCP governance, plugin review, and OTel. Do not use them as your only boundary. ## Product support | Product | Hook support | What security gets | Watch-outs | | ------------- | ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Claude Cowork | No Cowork-specific lifecycle hook surface in the reviewed docs. Org-level inference hooks do gate Cowork prompts (see above). | Use inference hooks for prompt-level governance, plus Cowork permissions, OTel, plugin review, MCP governance, browser controls, Computer Use policy, and scheduled-task governance. | If a Cowork workflow delegates into Claude Code or desktop extensibility, govern that underlying surface separately. | | Claude Code | Yes (lifecycle hooks). Also covered by org-level inference hooks. | Lifecycle hooks using commands, HTTP endpoints, MCP tools, prompts, agents, managed policy, plugin or skill locations, and project or local settings. Pre-tool and permission hooks can block or shape decisions. | Hooks can arrive through project config, plugins, skills, and user settings. Managed-only hooks are the safer enterprise stance. | | Claude Tag | No user-defined hook surface in the reviewed docs. | Use channel access, service-account scope, Agent Proxy allowlists, audit exports, Slack records, and connected-system logs. | Tag runs as a channel agent. Manage it through channel governance rather than hook policy. | | ChatGPT Codex | Yes, currently as an experimental hook system. | Session and tool lifecycle hooks, deterministic checks, logging, notifications, and narrow pre-tool controls. | Codex documents hooks as guardrails, not a complete enforcement boundary. Repo-local `.codex` config can carry hook behavior, and some specialized paths may not use the default hook route. | | ChatGPT Work | No native user-defined Work hook surface in the reviewed guides. | Use workspace access, app action controls, approvals, connector governance, scheduled-task controls, endpoint logs, Compliance Logs, and Codex OTel where applicable. | Do not assume Work inherits every Codex local hook behavior, especially for hosted Work tasks. | ## How to use hooks technically Use hooks for narrow, deterministic rules. A hook should make one decision clearly, log that decision, and fail in the safest direction for high-risk actions. A good first hook program covers: 1. **High-risk shell commands.** Require approval or deny commands that push code, change infrastructure, delete broadly, alter credentials, or call external upload endpoints. 2. **Sensitive paths.** Deny reads or writes involving secrets, home directories, cloud drives, credential stores, and unrelated projects. 3. **Network egress.** Alert or deny unexpected external calls, especially where the sandbox cannot enforce an allowlist. 4. **Production targets.** Require ticket context before actions against production, customer data, finance systems, identity systems, or public publishing. 5. **Telemetry enrichment.** Add rule IDs, data classification, project owner, policy version, and decision fields to OTel or another evidence path. A safe hook rule reads like this: ```yaml event: PreToolUse match: Bash detect: - broad_delete - external_upload - production_change - credential_access decision: deny_or_require_approval log: - user - product - workspace - command_hash - rule_id - decision - timestamp ``` That example is intentionally a pattern, not a product-specific file. Use the vendor syntax for Claude Code or Codex, then keep the intent and logging fields stable across products. For Claude Code, manage hooks through enterprise-managed settings where possible. Restrict unmanaged hooks, review project hooks before trusting a repository, and treat plugin and skill hooks as part of the plugin security review. Where the platform supports it, allow only managed hooks for normal users and keep user or project hooks for small expert groups. For Codex, remember that hook behavior can come from config layers, including repo-local `.codex` files. Keep the experimental feature disabled for broad groups until you have reviewed the source, tested the rules, and confirmed which tool paths are actually covered. ## How to use hooks as a practitioner A practitioner should start from risks, not from the excitement of having lifecycle automation. For ChatGPT Work and Claude Cowork programs, the top concerns are prompt injection, local file access, connectors, browser or Computer Use, scheduled work, plugins, MCP servers, and gaps in action-level evidence. Lifecycle hooks help only where the product routes actions through a hookable runtime. That usually means Claude Code and Codex first. For prompt-level governance across every Claude surface, inference hooks are the right tool. Use hooks when the rule is objective: * Block or ask before a risky command. * Require a ticket before production actions. * Prevent writes outside an approved workspace. * Alert when a repo carries hook configuration. * Add a policy version and data-classification label to runtime telemetry. * Send high-risk action metadata to the SIEM. Do not use hooks for broad judgment calls such as "is this prompt safe" or "is this code secure." Those belong in policy, approvals, review workflows, model-side safety checks, and downstream scanners. Hooks are strongest when the condition is concrete and the decision is quick. ## Governance checklist Before enabling hooks for a group, answer these questions: | Question | Good answer | | ------------------------- | --------------------------------------------------------------------------------- | | Who owns the hook? | A named team, with a code owner and escalation path. | | Where is the source? | A reviewed repository, not an unmanaged local script. | | Who can change it? | A small group with change review and history. | | Where can it send data? | Approved internal destinations only, with external URLs blocked or reviewed. | | What secrets can it read? | Ideally none. If needed, pass only scoped values through managed secret handling. | | Does it fail closed? | Yes for deny rules and high-risk controls. | | Is it logged? | Yes, including source, trigger, target, result, and failure state. | | Is it tested? | Yes, with canary prompts and commands before rollout and after changes. | ## Review project-carried hooks like supply chain Project hooks are convenient because a repository can define its own workflow. That is also the risk. A cloned repo can carry hook behavior that runs during an AI session, and reviewers may miss it because it looks like configuration rather than code. For managed environments: * Inventory hook files during repo intake. * Alert on new or changed hook config. * Block project hooks for normal users unless the repo is trusted and the hook owner is named. * Review plugin, skill, MCP, and hook changes together, because they can combine into one execution path. * Compare hook logs with OTel and sandbox denials. Mismatches usually mean either a coverage gap or a broken telemetry path. ## What to avoid * Do not use hooks as a replacement for sandboxing. Hooks are conditional logic. Sandboxes are boundaries. * Do not allow hooks to post prompts, files, or tool arguments to arbitrary URLs. * Do not let repo-local hooks run for broad employee groups without review. * Do not assume PostToolUse means prevention. It is after the action. * Do not rely on hook logs alone for investigations. Join them with OTel, endpoint logs, provider audit records, and target-system logs. * Do not assume lifecycle hooks give you org-wide prompt governance, and do not assume inference hooks give you tool-level control. They are different layers; most programs need both. ## Sources and related guidance * [Securing ChatGPT Work: A Practitioner's Guide](https://www.harmonic.security/resources/securing-chatgpt-work-a-practitioners-guide) * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) * [Inference hooks (Claude Platform)](https://platform.claude.com/docs/en/manage-claude/inference-hooks) * [Configure inference hooks (Claude Platform)](https://platform.claude.com/docs/en/manage-claude/inference-hooks-configuration) * [Claude Code hooks](https://code.claude.com/docs/en/hooks) * [Claude Code permissions](https://code.claude.com/docs/en/permissions) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Codex hooks](https://developers.openai.com/codex/hooks) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex) ## Related handbook guidance * [2. Supply Chain & Extensibility](/handbook/2.-supply-chain-and-extensibility) * [4.1 DLP for GenAI](/handbook/4.-data-protection-and-residency/4.1-dlp-for-genai) * [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk) # 2.7 The supply-chain review workflow A repeatable intake process covering allowlist, owner, scopes, credential handling, runtime permissions, update path, and review date for every AI extension. *Last reviewed: August 18, 2026* {% hint style="info" %} AI extensions need an intake path. If a tool can read data, write to a system, run code, or alter agent behavior, it needs an owner and a review date. {% endhint %} ## What security teams need to know about the supply-chain review workflow Supply-chain review is the operating system for AI extensibility. The same intake form should handle connectors, MCP servers, skills, plugins, hooks, prompt templates, model gateways, and hosted-agent packages. The goal is not to slow every experiment. The goal is to separate low-risk exploration from production access, then make production approvals repeatable. ## Common the supply-chain review workflow security failures * Each AI surface has a different approval process. * The review checks source code but misses OAuth scopes or data classes. * The owner leaves and the extension stays enabled. * Updates are treated as routine even when scopes or behavior change. * No register exists for approved AI extensions. ## The supply-chain review workflow security controls checklist * Create one intake form for all AI extension types. * Record owner, source, version, data class, scopes, write actions, credentials, logs, and review date. * Separate sandbox approval from production approval. * Trigger review on scope change, owner change, new write action, new dependency, or vendor update. * Keep a central register that maps extensions to handbook controls. ## Minimum agent bill of materials Keep one record for every approved agent or AI workflow. At minimum, record: | Field | Required detail | | ------------------------ | ----------------------------------------------------------------------------------------------------------- | | Component | Model, SDK, connector, MCP server, skill, plugin, hook, package, image, template, knowledge source, or tool | | Source and owner | Publisher, repository or marketplace, internal owner, and support contact | | Identity and permissions | Credentials, OAuth scopes, service accounts, data classes, actions, and destinations | | Version and provenance | Version, hash or signature where available, build source, and approved distribution channel | | Runtime | Local, browser, desktop, hosted, API, or low-code execution path | | Review state | Reviewer, decision, evidence, review date, exception, and expiry | | Change trigger | Update channel, permission change, owner change, new dependency, incident, or new data class | Reconcile the register against what is installed and enabled. A complete intake record that no longer matches production is not evidence. ## Anthropic ### Overview For Anthropic, the supply-chain intake should track the surface first: Claude connectors, Cowork remote or local execution, desktop extensions, Claude Code customizations, Claude API tool use, Agent Skills, Office add-ins, and Claude Managed Agents. A connector approval is not the same object as a Claude Code plugin, a local MCP server, or a Managed Agent definition. The intake register should record connector or MCP owner, surface, transport, source, version, OAuth scopes or vault credentials, tool allowlist, write actions, skill or plugin contents, environment type, beta headers, logging path, and review cadence. For Managed Agents, include the agent definition, environment, session pattern, MCP servers, skills, credentials, and whether multi-agent delegation is enabled. For Claude Tag, add the Slack workspace and channel scope, dedicated service accounts, Access bundles, allowed domains, repository grants, channel instructions or plugins, and routines. ### 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-claude-s-capabilities) * [Tool use with Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview) * [MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector) * [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 Code settings](https://code.claude.com/docs/en/settings) * [Claude Code plugins](https://code.claude.com/docs/en/plugins) * [Claude Code hooks](https://code.claude.com/docs/en/hooks) * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [How Claude Tag agent identity works](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) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview For OpenAI, the intake workflow should distinguish ChatGPT Work, apps, plugins, Sites, and Workspace Agents from Codex extensions and API-hosted agent frameworks. Work is a user-owned agent surface; plugins package workflow instructions and app dependencies; apps remain the data and action integrations. Direct Codex MCP configuration, hooks, skills, and sandbox policy need their own review. API-built agents add Agents SDK packages, tool definitions, MCP servers, evals, tracing, credentials, and deployment gates. Include surface, owner, app or plugin source, package or workflow version, connected data class, write actions, action-control mode, workspace role, tool list, MCP server URL, sandbox or cloud mode, eval requirement, audit export path, and re-review trigger. For legacy Agent Builder workflows, record the November 30, 2026 shutdown date and migration owner. ### OpenAI documentation * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [Apps in ChatGPT](https://help.openai.com/en/articles/11487775-apps-in-chatgpt) * [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) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [Workspace Agents](https://developers.openai.com/workspace-agents) * [Agent Builder](https://developers.openai.com/api/docs/guides/agent-builder) * [Safety in building agents](https://developers.openai.com/api/docs/guides/agent-builder-safety) * [Agents SDK](https://developers.openai.com/api/docs/guides/agents) * [Using tools](https://developers.openai.com/api/docs/guides/tools) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [Codex hooks](https://developers.openai.com/codex/hooks) * [Codex skills](https://developers.openai.com/codex/skills) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) ### Applicable Harmonic guides for OpenAI * [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) ## Frequently asked questions about the supply-chain review workflow ### What belongs in an AI supply-chain review? Anything that can read data, write to a system, run code, or alter agent behavior: connectors and apps, MCP servers, skills, plugins, hooks, prompt templates, desktop extensions, hosted-agent packages, and model gateways. One intake form should cover all of them, because the same questions about owner, scopes, write actions, and evidence apply regardless of the label. ### Who should approve AI extensions? Shared approval works best: the business owner confirms the need, the app or data owner validates what the extension can reach, security approves scopes and actions against the access standard, and the platform team confirms the control is enforceable. Security should hold the veto and own the exception register so approvals stay consistent across surfaces. ### What is the minimum intake record for an AI extension? Owner, purpose, source, version, surface (which product and mode it runs in), scopes and credentials, data class, write actions, logging path, approval date, and next review date. If you cannot fill in the owner and the revocation path, the extension is not ready for production. ### When should an AI extension be re-reviewed? On any scope change, new write action, ownership change, dependency or version update, vendor behavior change, or incident. Vendor changes count even when nothing local changed: a renamed setting or a new default can silently invalidate the original approval. ### How do pilots fit the review workflow? Pilots can use a lighter review, with sandbox scope, no production data, and a named sponsor, so experimentation stays fast. The gate is promotion: production access requires the full intake record, and the pilot's own telemetry becomes the evidence for that decision. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports provider instructions, dependencies, changes, and approvals. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports ICT asset, dependency, and third-party risk management. | | G.4 Colorado AI Act and the US state patchwork | Conditional: for covered Colorado ADMT, this supports developer documentation, system versions, material updates, and approved uses. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies, Inference Security, 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 a repeatable workflow for third-party review, control selection, and change control. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA approved vendors, business-associate review, data paths, and tool authorization. | *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 * [2. Supply Chain & Extensibility](/handbook/2.-supply-chain-and-extensibility) * [2.4 Analyzing skills for risk](/handbook/2.-supply-chain-and-extensibility/2.4-analyzing-skills-for-risk) * [2.5 Plugins and marketplaces](/handbook/2.-supply-chain-and-extensibility/2.5-plugins-and-marketplaces) * [2.8 Signing and packaging](/handbook/2.-supply-chain-and-extensibility/2.8-signing-and-packaging) * [7.2 Pilot design and success metrics](/handbook/7.-rollout-and-operations/7.2-pilot-design-and-success-metrics) # 2.8 Signing and packaging How to prefer signed, centrally versioned, and managed packages over hand-deployed binaries or ad hoc local extensions. *Last reviewed: August 18, 2026* {% hint style="info" %} Packaged extensions are easier to review than scattered files. Require versioned, centrally distributed packages for anything that reaches production users. {% endhint %} ## Signing and packaging: what security teams need to know Packaging turns local extension sprawl into a manageable release object. A package can contain the manifest, server configuration, skills, hooks, and supporting files that a reviewer needs to inspect. Signing and version pinning add evidence. They help the organization prove what was approved, what was installed, and whether a later update changed behavior. ## Common signing and packaging security failures * Users install unpackaged local extensions from shared folders. * A package version is approved, then the source branch changes. * No one can tell which users have which extension version. * A signed package is trusted forever without update review. * Package review misses scripts or hooks inside the bundle. ## Signing and packaging security controls checklist * Prefer signed, versioned packages over hand-deployed files. * Require manifest review and source review before publication. * Pin versions for production groups. * Distribute packages through a managed marketplace or admin channel. * Record package hash, version, owner, source repository, and review date. ## Anthropic ### Overview For MCPB and desktop extension packaging, the main Anthropic surfaces are Claude Desktop and Claude Code. MCPB is the MCP Bundle format: a desktop extension is a `.mcpb` archive (formerly `.dxt`) that contains a local MCP server and a `manifest.json` describing the server and its capabilities. Desktop extensions package local MCP servers for Desktop and Claude Code; remote connectors and custom remote MCP servers are available across Claude surfaces and should be reviewed as connector grants rather than local desktop packages. Review the package manifest, bundled server, credentials, update path, extension directory or custom upload path, and enterprise policy controls. Also review Claude Code plugins when the package bundles skills, hooks, commands, agents, or MCP servers for coding workflows. ### 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-claude-s-capabilities) * [When to use desktop and web connectors](https://support.claude.com/en/articles/11725091-when-to-use-desktop-and-web-connectors) * [Getting Started with Local MCP Servers on Claude Desktop](https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop) * [Building Desktop Extensions with MCPB](https://github.com/modelcontextprotocol/mcpb) * [Build custom connectors via remote MCP servers](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp) * [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 Code MCP](https://code.claude.com/docs/en/mcp) * [Claude Code hooks](https://code.claude.com/docs/en/hooks) * [Claude Code plugins](https://code.claude.com/docs/en/plugins) * [Claude Code skills](https://code.claude.com/docs/en/skills) * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI does not use Claude-style MCPB desktop extensions for ChatGPT. Comparable packaging decisions show up as custom MCP apps, Apps SDK apps, plugins from the Plugin Directory, and direct Codex MCP server configuration. ChatGPT Desktop (Work / Codex) combines Work and Codex, but the package types still keep separate install, authorization, update, and audit paths. Review both the desktop and web Plugin Directory and the Codex CLI or IDE plugin browsers. Also review plugin-provided MCP servers, app integrations that require ChatGPT authorization, direct MCP server configuration shared by desktop Codex, CLI, and IDE extension, and managed configuration for organization policy. ### OpenAI documentation * [Apps in ChatGPT](https://help.openai.com/en/articles/11487775-apps-in-chatgpt) * [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) * [Developer mode and MCP apps in ChatGPT](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt) * [ChatGPT desktop app](https://learn.chatgpt.com/docs/app) * [Apps SDK MCP](https://developers.openai.com/apps-sdk/concepts/mcp-server) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [Plugins](https://learn.chatgpt.com/docs/plugins) * [Codex MCP](https://developers.openai.com/codex/mcp) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about signing and packaging ### What is an MCPB file? MCPB is the MCP Bundle format used for Claude desktop extensions: a `.mcpb` archive (formerly `.dxt`) containing a local MCP server plus a `manifest.json` describing the server and its capabilities. It makes local MCP servers installable in one click, which is exactly why the package, not just the server inside it, needs review before distribution. ### Why does signing matter for AI extension packages? Signing proves origin and integrity: the organization can show what was approved, what was installed, and whether a later update changed the contents. It does not replace code and permission review; a signed malicious package is still malicious, just attributable. ### Should users install local extension folders? Not in production groups. Hand-deployed folders leave no version, hash, or install inventory, so nobody can answer "who is running what" during an incident. Managed packages distributed through an admin channel or marketplace keep review, versioning, and rollback in one path. ### What should be version pinned? Pin anything with code execution or data access: plugins, MCP servers, packaged skills, and desktop extensions. Pinning turns updates into review events instead of silent behavior changes, which is the core defense against the benign-at-review, malicious-at-update supply-chain pattern. ### What packaging evidence should be kept? Source repository, version, hash, signature status, reviewer, owner, install population, and review date for every package in production. The working test: for any given user, you can name the exact package versions they run and who approved each one. ## 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 ICT asset, dependency, and third-party risk management. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies, Inference Security, and GRC guidance. | *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 * [2. Supply Chain & Extensibility](/handbook/2.-supply-chain-and-extensibility) * [2.7 The supply-chain review workflow](/handbook/2.-supply-chain-and-extensibility/2.7-the-supply-chain-review-workflow) * [2.4 Analyzing skills for risk](/handbook/2.-supply-chain-and-extensibility/2.4-analyzing-skills-for-risk) * [5.3 Supply chain attacks and notable CVEs](/handbook/5.-threats-and-adversarial/5.3-supply-chain-attacks-and-notable-cves) * [2.10 Hosted-agent framework dependencies](/handbook/2.-supply-chain-and-extensibility/2.10-hosted-agent-framework-dependencies) # 2.9 SaaS agent-building supply-chain How to govern the connectors, actions, triggers, and data sources that non-security staff wire together in Copilot Studio and similar low-code builders. *Last reviewed: August 18, 2026* {% hint style="info" %} Low-code agent builders move automation into the hands of business teams. Govern the building blocks before agents reach production users. {% endhint %} ## SaaS agent-building supply-chain: what security teams need to know Low-code builders let teams assemble agents from connectors, actions, triggers, prompts, and business rules. That shortens delivery time, but it also shifts integration risk outside traditional engineering review. The supply chain is the catalog. If anyone can choose any connector, any action, and any trigger, the agent-building surface becomes a shadow integration platform. ## Common SaaS agent-building supply-chain security failures * Users can publish agents without review. * Write actions are available to builders by default. * Triggers run on sensitive data without logging or owner approval. * Agents are shared broadly after a narrow pilot. * Connector scopes are inherited from the builder rather than a controlled service identity. ## SaaS agent-building supply-chain security controls checklist * Restrict who can create, test, publish, and share agents. * Use approved action and connector catalogs. * Require review for external write actions and unattended triggers. * Tag each agent with owner, data class, connected systems, and review date. * Monitor agent runs, failures, connector calls, and sharing changes. ## Anthropic ### Overview Anthropic-specific low-code and SaaS-style agent building appears in Claude connectors, Claude Cowork, Claude Desktop extensions, Agent Skills, Claude Tag, and Claude Managed Agents. In the Claude app surfaces, govern who can enable connectors, whether actions require approval, and whether desktop extensions are allowed. In Claude Tag, review the provisioned service accounts, Access bundles, channel instructions or plugins, repositories, and routines as one shared-agent release. In Managed Agents, review the agent definition, environment, tools, MCP servers, skills, credentials, sessions, and scheduled or multi-agent behavior. Do not collapse these into one approval. A Claude Cowork connector grant, a Claude Desktop extension, a custom Agent Skill, and a Managed Agent with vault credentials can all automate work, but they have different publishing and revocation controls. The agent catalog should identify the builder, publisher, connected systems, write actions, trigger or schedule, environment, and review owner. ### Anthropic documentation * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [When to use desktop and web connectors](https://support.claude.com/en/articles/11725091-when-to-use-desktop-and-web-connectors) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Multi-agent sessions](https://platform.claude.com/docs/en/managed-agents/multi-agent) * [Scheduled deployments](https://platform.claude.com/docs/en/managed-agents/scheduled-deployments) * [Skills for enterprise](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/enterprise) * [Claude Code plugins](https://code.claude.com/docs/en/plugins) * [Claude Code skills](https://code.claude.com/docs/en/skills) * [How Claude Tag agent identity works](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) ## OpenAI ### Overview OpenAI-specific low-code and SaaS agent building spans ChatGPT Work, plugins, apps, custom MCP apps, Workspace Agents, and the legacy Agent Builder surface. Work is a personal task agent, not a published reusable Workspace Agent, so inventory it through user access, scheduled tasks, plugins, and connected data rather than a publisher catalog. Workspace Agents remain the shared, publishable agents that can run on schedules or be triggered from external systems. Agent Builder is still relevant for existing workflows, but OpenAI documents it as legacy and scheduled to shut down on November 30, 2026. Treat any active Agent Builder workflow as a migration item. For Codex, plugin-based agent workflows are more developer-oriented, but the same catalog controls apply when a plugin exposes app actions, MCP servers, skills, or templates to users. ### OpenAI documentation * [Apps in ChatGPT](https://help.openai.com/en/articles/11487775-apps-in-chatgpt) * [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) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [Developer mode and MCP apps in ChatGPT](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt) * [Apps SDK MCP](https://developers.openai.com/apps-sdk/concepts/mcp-server) * [Workspace Agents](https://developers.openai.com/workspace-agents) * [Agent Builder](https://developers.openai.com/api/docs/guides/agent-builder) * [Safety in building agents](https://developers.openai.com/api/docs/guides/agent-builder-safety) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) ## Frequently asked questions about SaaS agent-building supply-chain ### What is a SaaS agent builder? A SaaS or low-code agent builder lets users assemble agents from prompts, connectors, actions, triggers, and business rules without writing much code; ChatGPT workspace agents and Claude Cowork are the mainstream examples alongside dedicated platforms. The supply chain is the catalog: whatever connectors and actions builders can pick become the organization's integration surface. ### Why is low-code agent building a supply-chain risk? Builders combine trusted and untrusted components, including connectors, prompts, triggers, and shared templates, into something that acts on business systems under real credentials. Because assembly happens outside engineering review, an over-scoped connector or misconfigured trigger can reach production without anyone reading a diff. ### Which controls matter first for agent builders? In order: who can publish and share agents (not just build them), which connectors and actions are in the approved catalog, which write actions require approval, whether agents run on the builder's credentials or a service identity, and how unattended triggers are reviewed. Publishing rights matter more than building rights; an unpublished experiment hurts less than a shared agent. ### Should business users build agents? Yes, in a sandbox with an approved catalog; that is where the productivity win is. Production publishing should require a review path, an accountable named owner, and credentials that survive the builder leaving. Agents that reach data through the publisher's personal authentication are the pattern to block before broad sharing. ### What should be logged for low-code agents? Builder, publisher, trigger, connector, action, target system, data class, run outcome, and sharing changes. Sharing events deserve alerts: a narrow pilot agent shared org-wide is the most common quiet escalation. ## 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 ICT asset, dependency, and third-party risk management. | | 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.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 * [2. Supply Chain & Extensibility](/handbook/2.-supply-chain-and-extensibility) * [2.10 Hosted-agent framework dependencies](/handbook/2.-supply-chain-and-extensibility/2.10-hosted-agent-framework-dependencies) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) * [5.7 Threat modeling AI systems](/handbook/5.-threats-and-adversarial/5.7-threat-modeling-ai-systems) # 2.10 Hosted-agent framework dependencies How to secure hosted-agent dependencies across SDKs, tools, MCP servers, prompts, models, containers, deployment pipelines, and runtime services. *Last reviewed: August 18, 2026* {% hint style="info" %} Code-defined agents have a supply chain too. Review packages, tools, prompts, templates, and deployment gates together. {% endhint %} ## What security teams need to know about hosted-agent framework dependencies Hosted agents are software systems. They use packages, frameworks, tool registries, prompt templates, model providers, vector stores, and deployment pipelines. Each layer can change what the agent can see or do. The review should follow the dependency graph from source control to runtime. A safe prompt with an unsafe tool registry still creates risk. ## Common hosted-agent framework dependencies security failures * Tool registration changes without security review. * Prompt templates are edited outside source control. * Packages are unpinned or pulled from untrusted registries. * A new model provider is added without data-flow review. * Eval results are stored, but deployment is not gated on them. ## Hosted-agent framework dependencies security controls checklist * Pin packages and produce an SBOM for hosted-agent services. * Keep tool definitions, prompts, and templates in source control. * Require review for new tools, model providers, memory stores, and outbound destinations. * Use eval gates for high-risk workflows before release. * Log tool calls, model calls, retrieved context, and deployment version. ## Review the transitive runtime The framework is only the visible dependency. Include the model provider, agent and tool SDKs, MCP clients and servers, container base image, browser runtime, package manager, retrieval and memory services, telemetry exporters, policy libraries, and deployment templates. Pin where operationally feasible, monitor advisories, and record the update owner. For every material update, test authorization, tool schemas, sandbox behavior, network policy, secret handling, event fields, and stop behavior. A minor SDK or model change can alter tool invocation, retries, token use, and logging without changing the application code. ## Anthropic ### Overview For Anthropic hosted-agent frameworks, decide whether the team is building its own loop on the Messages API or using Claude Managed Agents. The Messages API path puts tool execution, state, retries, and deployment controls in the application. Managed Agents provide a hosted harness with agent definitions, environments, sessions, tools, MCP servers, skills, event streams, and cloud or self-hosted sandboxes. Dependency review should cover SDK versions, tool schemas, MCP server definitions, Agent Skills and their scripts, sandbox environment configuration, beta headers, vault credentials, self-hosted sandbox images, and multi-agent version pinning. Cloud sandboxes include preinstalled tools and disabled-by-default network access, so environment configuration belongs in the supply-chain review alongside code dependencies. Managed Agents is currently in beta, and because sessions persist conversation history and sandbox state server-side, it is not eligible for zero-data-retention arrangements today; put that in the data-flow review alongside network configuration. ### Anthropic documentation * [Tool use with Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview) * [MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector) * [Using Agent Skills with the API](https://platform.claude.com/docs/en/build-with-claude/skills-guide) * [Skills for enterprise](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/enterprise) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Cloud sandbox reference](https://platform.claude.com/docs/en/managed-agents/cloud-sandboxes-reference) * [Multi-agent sessions](https://platform.claude.com/docs/en/managed-agents/multi-agent) * [API and data retention](https://platform.claude.com/docs/en/manage-claude/api-and-data-retention) ## OpenAI ### Overview For OpenAI hosted-agent frameworks, the main code-defined path is the Agents SDK with platform tools, remote MCP, handoffs, guardrails, sessions, approvals, and tracing. Teams may also build directly on the Responses API and `tools` parameter, trigger Workspace Agents, use ChatGPT apps built with the Apps SDK, or embed Codex as a coding specialist through the Codex SDK or MCP server pattern. Dependency review should cover the Agents SDK package, generated or exported workflow code, tool wrappers, MCP server URLs, app servers, prompt and instruction files, eval datasets, tracing destinations, sandbox agents, credentials, workload identity, and deployment gates. Keep ChatGPT workspace controls, OpenAI API project controls, and Codex managed configuration separate in the review record. Note that OpenAI documents the standalone Evals platform as deprecated with a transition window, so gate new work on code-defined or Agents SDK-based evaluation rather than the legacy platform. ### OpenAI documentation * [Agents SDK](https://developers.openai.com/api/docs/guides/agents) * [Using tools](https://developers.openai.com/api/docs/guides/tools) * [Working with evals](https://developers.openai.com/api/docs/guides/evals) * [Workspace Agents](https://developers.openai.com/workspace-agents) * [Apps SDK MCP](https://developers.openai.com/apps-sdk/concepts/mcp-server) * [Codex SDK](https://developers.openai.com/codex/sdk) * [Codex MCP](https://developers.openai.com/codex/mcp) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) * [Workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about hosted-agent framework dependencies ### What is a hosted-agent framework? It is the code path for running agents as software services: the team owns the agent loop, tool registry, prompts, and deployment pipeline rather than configuring an agent inside a vendor UI. Examples include agents built on the OpenAI Agents SDK or Responses API, and Claude agents built on the Messages API or run through Claude Managed Agents. The security consequence is that supply-chain review shifts from vendor settings to your own dependency graph. ### What dependencies matter most for AI agents? Everything that can change what the agent sees or does: application and framework packages, tool registries and schemas, MCP server definitions, prompt and instruction templates, model providers, retrieval and memory stores, and the deployment pipeline itself. Any of these layers can alter agent behavior without a single line of application code changing. Pin and review them together, not just the packages. ### Should prompts be in source control? Yes, for production agents. Prompt and template changes can change agent behavior as much as code changes, so they need the same review, versioning, and rollback path. A diffable prompt history is also what lets incident responders explain a behavior shift after the fact. ### What is an eval gate? An eval gate is a deployment control that blocks a release unless the agent passes defined tests for safety, quality, and business behavior, such as resisting a prompt-injection test set or refusing out-of-scope tool calls. Build gates on your own evaluation harness or code-defined tooling; OpenAI documents its hosted Evals platform as deprecated, so new gates should not depend on it. ### What should an agent SBOM include? Beyond normal application packages: agent-framework packages, tool and MCP server packages, runtime images, prompt and template versions, and the major external services the agent depends on, such as the model provider, vector store, and tracing destination. The goal is that an incident responder can answer "which agents use this dependency?" in minutes. ## 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 ICT asset, dependency, and third-party risk management. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies, Inference Security, 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA approved vendors, business-associate review, data paths, and tool authorization. | *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 * [2. Supply Chain & Extensibility](/handbook/2.-supply-chain-and-extensibility) * [2.9 SaaS agent-building supply-chain](/handbook/2.-supply-chain-and-extensibility/2.9-saas-agent-building-supply-chain) * [2.8 Signing and packaging](/handbook/2.-supply-chain-and-extensibility/2.8-signing-and-packaging) * [3.9 Central hosted-agent runtime hardening](/handbook/3.-runtime-sandbox-and-autonomy/3.9-central-hosted-agent-runtime-hardening) * [5.3 Supply chain attacks and notable CVEs](/handbook/5.-threats-and-adversarial/5.3-supply-chain-attacks-and-notable-cves) # 3. Runtime, Sandbox & Autonomy How to contain what AI agents can do at runtime — sandbox isolation, network egress, browser access, filesystem scope, approvals, and scheduled task governance. *Last reviewed: August 18, 2026* {% hint style="info" %} What an AI agent can do at runtime is as important as what data it can see. Sandbox isolation, network egress controls, browser access policies, and approval gates determine whether an agent's actions are contained or catastrophic. {% endhint %} ## Articles in this section 1. [3.1 What Even is an AI Sandbox?](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox) 2. [3.2 Approval policies and least-privilege autonomy](/handbook/3.-runtime-sandbox-and-autonomy/3.2-approval-policies-and-least-privilege-autonomy) 3. [3.3 Network egress control](/handbook/3.-runtime-sandbox-and-autonomy/3.3-network-egress-control) 4. [3.4 Internet access and browser automation](/handbook/3.-runtime-sandbox-and-autonomy/3.4-internet-access-and-browser-automation) 5. [3.5 Computer Use / desktop control risks](/handbook/3.-runtime-sandbox-and-autonomy/3.5-computer-use-desktop-control-risks) 6. [3.6 Scheduled and background tasks](/handbook/3.-runtime-sandbox-and-autonomy/3.6-scheduled-and-background-tasks) 7. [3.7 Remote access, dispatch and SSH](/handbook/3.-runtime-sandbox-and-autonomy/3.7-remote-access-dispatch-and-ssh) 8. [3.8 File and filesystem access controls](/handbook/3.-runtime-sandbox-and-autonomy/3.8-file-and-filesystem-access-controls) 9. [3.9 Central hosted-agent runtime hardening](/handbook/3.-runtime-sandbox-and-autonomy/3.9-central-hosted-agent-runtime-hardening) ## Frequently asked questions **What is the minimum safe runtime boundary for an agent?**\ Use the narrowest filesystem, network, credential, tool, duration, and action scope that supports the approved task. Separate the orchestrator from tool execution where feasible, require approval beyond the baseline, and test termination before production. **Why do local and hosted execution need separate reviews?**\ They have different isolation, credential, data-retention, network, evidence, and incident-containment paths. A product setting may enable both without applying the same controls to both runtimes. ## Related handbook guidance * [AI Security Handbook](/) * [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility) # 3.1 What Even is an AI Sandbox? What AI sandboxes give you, which AI work products support them, and how security teams should configure, test, and evidence the boundary. *Last reviewed: August 18, 2026* {% hint style="info" %} A sandbox is a control boundary. It limits what an agent can read, write, execute, and reach over the network. It is not, by itself, a complete audit trail. {% endhint %} ## The short version An AI sandbox gives you **control**. It narrows the blast radius when an agent works with files, code, tools, connectors, and the network. A good sandbox answers four questions before a task starts: * What can the agent read? * What can it write? * What can it execute? * What can it reach over the network? The sandbox gives some **visibility** when the platform records its mode, working directory, allowed paths, blocked paths, approval decisions, and network denials. For investigations, that is useful context, but it is not enough. Pair sandbox settings with OpenTelemetry, provider audit records, endpoint logs, SaaS audit logs, and the approval history for the task. The practical rollout lesson from ChatGPT Work and Claude Cowork is simple: separate **hosted work** from **local execution**. A local Codex or Claude Code sandbox does not automatically protect every hosted Work or Cowork task. Browser actions, Computer Use, connectors, scheduled tasks, artifacts, and publishing rights need their own control review. ## What it gives you | Security value | What the sandbox does | What it does not do | | ---------------- | ------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | Control | Limits file access, write scope, command execution, network egress, and sometimes subprocess behavior. | It does not decide who should have the product, connector, or data source in the first place. | | Containment | Keeps a mistaken or hijacked task from touching unrelated files, secrets, internal networks, or production systems. | It does not make prompt injection harmless if the approved workspace already contains sensitive data. | | Approval support | Forces sensitive actions through a human approval step when configured that way. | It does not guarantee that the approver understood the full downstream effect. | | Evidence context | Records mode, allowed paths, network policy, denials, and sometimes approval outcomes. | It does not replace runtime telemetry or target-system logs. | Use the sandbox as the floor for agentic work, not the ceiling of the control program. ## Product support | Product | Sandbox support | What security gets | Watch-outs | | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Claude Cowork | Yes, for remote sessions by default, with local execution still relevant for some desktop deployments. | Per-session temporary isolation, proxy-mediated egress, no private-network reach by default, and Desktop-mediated local file access. | Chrome, Computer Use, connectors, scheduled work, and shared artifacts still need separate controls and evidence. | | Claude Code | Yes. Claude Code has an explicit sandbox on macOS, Linux, and WSL2. | Local file and network boundaries, `/sandbox` inspection, managed settings, fail-closed behavior, and controls for unsandboxed commands. | Native Windows support is different. Full local access and unmanaged settings should be exception-only. | | Claude Tag | Limited from a practitioner sandbox-control perspective. Tag work runs in Anthropic-managed thread isolation, but reviewed docs do not expose a user-tunable sandbox mode. | Isolation for thread work, Agent Proxy controls, default-deny outbound hosts, and credential injection outside the sandbox. | Treat Tag as a channel, service-account, Agent Proxy, and audit problem. Do not manage it like Claude Code. | | ChatGPT Codex | Yes, especially for local Codex. | `read-only`, `workspace-write`, and full-access style modes, approval policy, working-directory scope, and network restrictions. | `danger-full-access` removes the useful boundary. Local settings do not cover every hosted Work surface. | | ChatGPT Work | Partial. Hosted Work runs in managed environments; desktop Work can touch local files and apps with permission. | Hosted task isolation, workspace access controls, connector controls, and local desktop permissions where applicable. | The ChatGPT Compliance Logs Platform may capture prompts and responses without file/action/tool-call detail. Do not assume Codex local sandbox settings cover hosted Work. | ## How to use it technically Start by classifying the work surface. A coding task in a local repository needs a different boundary from a hosted research task, a browser-driven task, or a scheduled task that can run unattended. For local coding-agent work, the technical baseline should look like this: 1. Use the smallest practical working directory. Keep home directories, cloud drives, password stores, SSH material, API keys, and unrelated repos outside scope. 2. Default to read-only or workspace-write. Full access belongs in disposable environments, not normal employee machines. 3. Keep broad network access off unless the workflow needs it. Prefer allowlists over open outbound access. 4. Block escape hatches. If the platform supports fail-closed behavior when the sandbox is unavailable, enable it. 5. Separate approval policy from sandbox policy, but review them together. A permissive approval mode can quietly widen what runs without friction. 6. Record the effective policy at session start: product, user, group, sandbox mode, working directory, writable roots, denied paths, network mode, and approval mode. For Codex local work, a conservative managed profile is the useful starting point: ```toml sandbox_mode = "workspace-write" approval_policy = "on-request" ``` For Claude Code, use managed settings to enforce the equivalent posture: sandbox enabled, fail if the sandbox is unavailable, restrict unsandboxed commands, restrict unmanaged read paths and unmanaged network domains where the product supports it, and keep the `/sandbox` view available for operator inspection. For hosted Work and Cowork, do not stop at the word "sandbox." Check where code actually runs, whether browser or Computer Use is involved, whether connectors can read or write, whether scheduled tasks can run without a human present, and where local files are copied for processing. ## How to use it as a practitioner A useful rollout is more operational than theoretical. * Create separate groups for ChatGPT Work, ChatGPT Codex, Claude Cowork, Claude Code, admins, connector builders, and exception users. * Block full-access local modes for normal users. Make the exception path explicit, time-limited, and tied to disposable environments. * Treat browser automation, Computer Use, scheduled tasks, publishing, and connector write actions as elevated risk, even when the core runtime is sandboxed. * Require a working-directory standard for code tasks. A repo root is reasonable. A home directory is not. * Run a canary test before production: denied secret file read, denied write outside workspace, denied network call, approved safe edit, and approved safe command. * Keep sandbox evidence near the runtime telemetry. Investigators need to know whether a task was read-only, workspace-write, remote sandboxed, or full access before they can read the rest of the logs correctly. The clearest practitioner mistake is to say "the agent is sandboxed" without naming the product, surface, mode, network policy, and approval policy. Those details are the control. ## What to evidence For each sandboxed surface, collect enough to reconstruct the boundary: | Evidence | Why it matters | | ----------------------------------- | ----------------------------------------------------------------------------------------------------- | | Product and surface | ChatGPT Work web, Codex local, Claude Cowork remote, and Claude Code local do not share one boundary. | | User and group | Confirms the task ran under an approved role and policy set. | | Sandbox mode | Shows whether the task was read-only, workspace-write, remote sandboxed, or effectively unrestricted. | | Working directory and mounted paths | Reveals whether sensitive folders were inside the boundary. | | Network policy | Shows whether outbound access was blocked, allowlisted, proxied, or open. | | Approval settings and decisions | Explains why a risky action did or did not run. | | Denials | High-signal evidence of the control doing work. | | Linked telemetry | Connects the boundary to the prompt, tool call, target system, and outcome. | ## Questions to ask before enabling a product * Which tasks run locally, and which run in a hosted environment? * Can admins enforce sandbox mode, or can users change it? * What folders are readable and writable by default? * Is network access off, allowlisted, proxied, or open? * Can a browser, Computer Use surface, connector, plugin, MCP server, or hook bypass the sandbox boundary? * Does the sandbox fail closed when unavailable? * Where do denials and approval outcomes appear? * How long is the evidence retained? ## Sources and related guidance * [Securing ChatGPT Work: A Practitioner's Guide](https://www.harmonic.security/resources/securing-chatgpt-work-a-practitioners-guide) * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) * [Claude Code sandboxing](https://code.claude.com/docs/en/sandboxing) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex) ## Related handbook guidance * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy) * [3.2 Approval policies and least-privilege autonomy](/handbook/3.-runtime-sandbox-and-autonomy/3.2-approval-policies-and-least-privilege-autonomy) * [3.3 Network egress control](/handbook/3.-runtime-sandbox-and-autonomy/3.3-network-egress-control) * [3.8 File and filesystem access controls](/handbook/3.-runtime-sandbox-and-autonomy/3.8-file-and-filesystem-access-controls) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk) # 3.2 Approval policies and least-privilege autonomy How to tune how much an agent can do without asking, based on posture, data sensitivity, user role, and task risk. *Last reviewed: August 18, 2026* {% hint style="info" %} Agent autonomy should match the task risk. Let agents move quickly where the blast radius is small, and slow them down where actions change systems or expose data. {% endhint %} ## Approval policies and least-privilege autonomy: what security teams need to know Autonomy is a policy decision. It decides how much an agent can do without a person approving each step. The right answer depends on data class, action type, environment, and user skill. High-trust modes are useful in disposable environments. They are risky in production folders, customer systems, and workspaces with live credentials. ## Common approval policies and least-privilege autonomy security failures * A team uses a high-autonomy mode because the pilot was low risk. * Approvals are disabled for write actions after users complain about friction. * Read-only tasks later grow into maintenance tasks without a new policy. * An automated reviewer agent is treated as equivalent to human review. * Break-glass access is left enabled after an incident. ## Approval policies and least-privilege autonomy security controls checklist * Define autonomy profiles for read-only, local write, external write, production, and break-glass work. * Require approval for external writes, destructive actions, credential access, and network changes. * Use full access only in disposable environments. * Record the policy mode in logs and runbooks. * Review autonomy settings after incidents and major feature releases. ## Anthropic ### Overview Claude Code encodes least privilege directly in permission rules: each tool or command pattern can be set to allow, ask, or deny, and deny rules take precedence over ask and allow. Two defaults do real work here. Suspicious bash commands trigger command-injection detection and require manual approval even when a matching rule is allowlisted, and permission matching fails closed, so a command that matches no rule defaults to asking. Managed settings can enforce these rules organization-wide, which turns a team convention into policy. Outside Claude Code, approvals live in different places. Team and Enterprise owners can enable connectors and restrict what actions they take, with connector permissions set to require approval, block, or always allow. Cowork can run without per-call approval prompts; Anthropic recommends ask-before-acting for sensitive files, accounts, sites, new tools, and hard-to-reverse actions, while permanent file deletion still requires approval. Managed Agents run unattended, so their approval posture is the deployment configuration itself. Claude Tag routines are another unattended path. A scheduled job, channel watch, or pull-request subscription uses the same Access bundles as a typed channel request. Restrict who can invoke Claude, narrow the channel's shared service accounts, and require downstream approval for high-impact writes; do not rely on a person being present in Slack when the routine fires. ### Anthropic documentation * [Configure permissions](https://code.claude.com/docs/en/permissions) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Use Claude Cowork safely](https://support.claude.com/en/articles/13364135-use-claude-cowork-safely) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) * [Set up Claude Tag routines](https://claude.com/docs/claude-tag/users/proactivity) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview Codex approval policies are named and configurable: on-request (the agent asks when it needs to escalate), never, untrusted, and granular policies that separately control sandbox approvals, MCP prompts, permission requests, and skill approvals. Auto-review is not a mode but a routing capability: it sends eligible approval requests through a reviewer agent instead of a person, which makes it a throughput tool rather than an accountability substitute. Managed configuration can set organization floors so local settings cannot drop below policy. Two adjacent controls round out the picture. Codex hooks can intercept tool calls, but they remain a guardrail rather than an enforcement boundary. In ChatGPT, Lockdown Mode limits outbound web and external-service access, though it does not affect Codex network access. ChatGPT Work introduces read, draft, write, share, scheduled, and execute action classes; apply human review, narrow credentials, app action controls, and supported approvals to the higher-impact classes. Desktop Work follows the local Codex permission and managed-configuration plane. ### OpenAI documentation * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Codex hooks](https://developers.openai.com/codex/hooks) * [Lockdown Mode](https://help.openai.com/en/articles/20001061) * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about approval policies and least-privilege autonomy ### What is least-privilege autonomy? It is granting an agent the minimum ability to act on its own that the task requires: the narrowest file scope, tool set, network reach, and write permissions that still let the work finish. In practice it means choosing a named autonomy profile per task type rather than one global setting. The profile should be visible in logs so reviewers can tell what the agent was allowed to do. ### When should agents run read-only? Use read-only modes for investigation, reporting, code review, and analysis, which produce recommendations rather than changes. Read-only is also the right default for a new workflow until someone has reviewed what write access it actually needs. Both Claude Code and Codex support read-only operation, so this is a configuration decision, not a product limitation. ### What actions should require approval? Writes outside the workspace, deletes, external messages, production changes, credential access, and new network destinations. The test is reversibility and blast radius: anything hard to undo, or visible outside the team, deserves a human pause. Keep the approval list short enough that users do not click through it on reflex. ### Is automated review enough for risky actions? No. Automated reviewers such as Codex's auto-review can filter routine approvals, but they are themselves model-driven and can be steered by the same injected content that steered the agent. Keep hard denies and human approval for destructive, external, or credential-touching actions, and treat automated review as a throughput optimization inside that boundary. ### How should break-glass be handled? Time-limit it, isolate it to a disposable environment, log every action taken under it, and review the session afterwards. Break-glass autonomy should be an incident-response tool with a named owner, not a convenience setting a frustrated user can leave enabled. Expire it automatically rather than trusting cleanup. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports human intervention, override, and stop controls. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports ICT containment, resilience, continuity, and recovery. | | G.4 Colorado AI Act and the US state patchwork | Conditional: for covered Colorado ADMT, this supports meaningful human review and override authority. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies and Inference Security 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 risk-based human oversight and action-approval records. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA technical access, integrity, transmission, availability, and audit safeguards. | *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 * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy) * [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies) * [3.1 What Even is an AI Sandbox?](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk) # 3.3 Network egress control Why default-deny outbound access with administrator-owned allowlists is safer than broad internet access for AI agents. *Last reviewed: August 18, 2026* {% hint style="info" %} Network egress is the path from a compromised prompt to external data loss. Default-deny is the clean starting point for agent runtimes. {% endhint %} ## Network egress control: what security teams need to know Agents often need network access for package installs, tests, retrieval, or API calls. That need should be explicit. A broad wildcard turns network policy into a hope that the agent behaves. Good egress control distinguishes model access, package registries, approved APIs, internal services, and general browsing. Each should have its own owner and review path. ## Common network egress control security failures * Network is opened for package installs and never narrowed again. * Bash tools can reach domains that the browser tool blocks. * The allowlist covers hostnames but not the business reason. * A prompt injection drives the agent to paste data into an approved but wrong endpoint. * Logs show a request happened but not the prompt or tool chain that caused it. ## Network egress control security controls checklist * Start from default-deny for agent-controlled network access. * Allow domains by workflow, not by user preference. * Separate package registries, vendor APIs, internal APIs, and web browsing. * Block shell network tools unless they are part of an approved workflow. * Log denied and allowed outbound attempts with process, tool, domain, and session. ## Anthropic ### Overview Claude Code treats the network as an approval surface: tools that make network requests require user approval by default, and network-fetching commands such as curl and wget are not auto-approved, so a prompt-injected exfiltration attempt hits a human decision. Permission rules can deny shell network tools outright, deny rules take precedence, and managed settings enforce the rules across the organization. Claude Code cloud execution adds isolated VMs with configurable network controls. Managed Agents put the default on your side: cloud sandboxes run with network access disabled until the environment configuration enables it, so every reachable domain is the result of an explicit environment decision. Cowork remote sessions use Anthropic-managed temporary sandboxes and a proxy that mediates outbound traffic, with no private-network access by default. Cowork local browser, computer, file, and app use instead follows the desktop and target application's network path. Review remote connectors and API web tools too; they are egress paths even when they do not look like network policy. Claude Tag channel egress is proxy-mediated and default-deny, but three allow layers can admit traffic: a connection's allowed websites, the Access bundle's Domains list, and the session environment's network setting. New environments can start at Anthropic's Trusted level, which includes documented developer hosts and package registries. Pin a stricter environment when the channel should reach only explicitly approved destinations. ### Anthropic documentation * [Claude Code security](https://code.claude.com/docs/en/security) * [Configure permissions](https://code.claude.com/docs/en/permissions) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Cloud sandbox reference](https://platform.claude.com/docs/en/managed-agents/cloud-sandboxes-reference) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview Codex network defaults are conservative where it matters: in workspace-write mode, commands run without network access unless it is explicitly enabled, and Codex cloud tasks allow network during the setup phase while the agent phase runs offline by default. Managed configuration can pin these settings so a local config cannot quietly reopen egress. That makes "who enabled command network access, and why" a concrete review question rather than a hope. For ChatGPT, Lockdown Mode limits outbound web and external-service access to reduce prompt-injection data exfiltration, and admins assign it through RBAC roles. It does not affect Codex network access. Work adds another boundary: web and mobile Work use workspace cloud controls, while desktop Work follows the local Codex permission and managed-configuration plane. Review Chat, Work cloud, Work desktop, and Codex egress separately even though the new desktop app places them together. ### OpenAI documentation * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) * [Lockdown Mode](https://help.openai.com/en/articles/20001061) * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about network egress control ### Why is network egress important for AI security? Egress is usually the last step of the attack chain: a prompt injection can steer an agent, but data only leaves when the agent can reach an external endpoint. Cutting or narrowing egress therefore weakens whole classes of attack even when the injection itself succeeds. That is why several agent runtimes now ship with network access off by default. ### Should web search bypass egress policy? No. Web search, web fetch, and browser tools are egress paths with friendly names, and injected content can use them to carry data out in a query string or URL. Govern them under the same allowlist thinking as shell network tools, and log their destinations the same way. ### What belongs on an allowlist? Only domains a defined workflow requires, each with an owner, a purpose, a data class, and a review date. Separate package registries, vendor APIs, internal services, and general browsing into different entries, because they fail differently and get reviewed by different people. An allowlist entry without a recorded reason is just a hole with better paperwork. ### Should package registries be allowed? Allow them where builds genuinely require installs, but restrict to approved registries and treat install scripts as code execution, because they are. A malicious package's install script runs inside whatever network and file boundary the agent has. Where the runtime separates a network-enabled setup phase from an offline execution phase, prefer that split. ### What should egress logs capture? For network events specifically: the tool or process that made the request, destination domain, URL class, allowed or denied result, and the user, agent, and session behind it. Denied attempts are the high-signal rows, because they show what an agent tried that policy stopped. Sandbox-mode and file-event logging are covered in 3.1 and 3.8. ## 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 ICT containment, resilience, continuity, and recovery. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies and Inference Security 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA technical access, integrity, transmission, availability, and audit safeguards. | *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 * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy) * [3.4 Internet access and browser automation](/handbook/3.-runtime-sandbox-and-autonomy/3.4-internet-access-and-browser-automation) * [3.1 What Even is an AI Sandbox?](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox) * [5.2 Data exfiltration via tools and connectors](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility) # 3.4 Internet access and browser automation Browser agents operate near the user’s signed-in sessions, so controls must cover page context, blocklists, per-site approval, and browser bridges. *Last reviewed: August 18, 2026* {% hint style="info" %} Browser agents act inside a live web session. Sensitive sites need explicit policy before an agent can read, click, submit, or copy from them. {% endhint %} ## Internet access and browser automation: what security teams need to know Browser automation gives agents a high-context view of the web. It also exposes them to hidden instructions, malicious pages, customer data, admin consoles, and live authenticated sessions. The browser should be treated as an action surface, not a research tool. Reading a page, clicking a button, and submitting a form are different risk levels. This handbook uses "browser bridge" as an umbrella term for the connection that lets an AI client observe or control a live browser session; Claude in Chrome and the ChatGPT Chrome extension are the current named examples. ## Common internet access and browser automation security failures * Sensitive sites are allowed because the browser is considered user-driven. * The agent reads pages in a signed-in admin console. * Default blocked categories are treated as a complete policy. * A page injects instructions that steer later tool calls. * Users approve site access without understanding the account context. ## Internet access and browser automation security controls checklist * Create a sensitive-site list for HR, finance, healthcare, cloud, identity, password, legal, and customer systems. * Require explicit approval for sensitive sites and write actions. * Disable browser bridges for groups that handle regulated data unless there is a reviewed use case. * Log URL, page class, action type, approval, and resulting tool calls. * Pair browser policy with network and DLP controls. ## Anthropic ### Overview The Anthropic browser surface is Claude in Chrome: a browser extension that lets Claude read, click, and navigate websites inside the user's signed-in session. It has two modes, "Ask before acting" (plan approval scoped to listed websites) and "Act without asking", with per-site permission prompts, and downloads, sensitive data entry, and authorizations always require approval regardless of mode. Team and Enterprise admins can set allowlists and blocklists that constrain which sites Claude can access no matter what an individual user permits. Who gets the extension at all is a role decision: Enterprise custom roles include Claude for Chrome as a controllable capability, so security can restrict the browser surface to reviewed groups. Cowork can also use Claude in Chrome from remote sessions through the desktop app; if the device or app is offline, the remote session cannot reach the browser. Treat everything the extension reads on a page as untrusted input that can steer later actions. Claude Tag separates web search from sandbox network access. Channel sessions can use Anthropic's server-side web search without an Access-bundle domain entry, while opening a URL or calling a service from the sandbox must pass Agent Proxy. Review search as an untrusted-content source even when the egress allowlist correctly blocks direct page fetches. ### Anthropic documentation * [Claude in Chrome permissions guide](https://support.claude.com/en/articles/12902446-claude-in-chrome-permissions-guide) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [Use Claude Cowork safely](https://support.claude.com/en/articles/13364135-use-claude-cowork-safely) * [How Claude Tag agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI has three current browser patterns with different boundaries. ChatGPT agent mode runs on an OpenAI-hosted virtual computer. The built-in browser is available in ChatGPT on the web and in the ChatGPT desktop app, where it uses a profile separate from the user's regular browser. The ChatGPT Chrome extension is the high-context option because it attaches Work or Codex to the user's existing signed-in Chrome state. The permission and evidence plan must follow the chosen pattern. A separate browser profile reduces accidental access to existing sessions but still holds any accounts the user signs into for the task. The Chrome extension carries the authority of the regular profile. ChatGPT Work on web and mobile follows workspace browser and network controls, while desktop Work follows the local permission plane. Atlas is no longer a rollout target: OpenAI says it will stop working on August 9, 2026 as browser capabilities move into ChatGPT and Codex. ### OpenAI documentation * [Introducing ChatGPT agent: bridging research and action](https://openai.com/index/introducing-chatgpt-agent/) * [ChatGPT Chrome extension](https://learn.chatgpt.com/docs/chrome-extension) * [Browser](https://learn.chatgpt.com/docs/browser) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) ### Applicable Harmonic guides for OpenAI * [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) ## Frequently asked questions about internet access and browser automation ### Why are browser agents risky? They read and act inside a signed-in web session, where the page itself is untrusted input: hidden text or malicious markup can inject instructions that steer later actions, and the session carries the user's real authority in admin consoles, mail, and SaaS tools. The combination of attacker-controlled content and user-level credentials is what makes this surface different from an API tool call. ### Which websites should be blocked first? Start with password managers, identity-provider admin pages, cloud consoles, HR, payroll, healthcare, financial, legal, and customer-admin systems: sites where a single agent action or copied page is an incident. Use the platform blocklists where they exist; Claude in Chrome and the Codex Chrome extension both support admin-managed blocklists. Vendor default protections are a floor, not your policy. ### Is read-only browser access safe? Safer than write access, but not safe by default: an agent that only reads can still copy sensitive page content into prompts, outputs, or tool calls, which is an exfiltration path in itself. Injected page content can also steer what the agent does next outside the browser. Treat read access to sensitive sites as a data-handling decision, not a harmless default. ### What is a browser bridge? Browser bridge is this handbook's umbrella term for the connection that lets an AI client observe or control a live browser session; concretely, extensions such as Claude in Chrome and the ChatGPT Chrome extension. Disabling the bridge removes the whole path, while per-site permissions and allowlists narrow it. The term does not appear in vendor documentation, so use the product names when reading vendor docs. ### How should browser actions be audited? Record the site, account context, action type (read, click, form submit), the approval that permitted it, and any downstream tool calls the page content triggered. Be realistic about coverage: hosted browser surfaces, the desktop app's separate browser profile, and extensions attached to a regular profile emit different evidence. Keep endpoint and target-system logs in the plan. ## 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 ICT containment, resilience, continuity, and recovery. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies and Inference Security 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.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 * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy) * [3.3 Network egress control](/handbook/3.-runtime-sandbox-and-autonomy/3.3-network-egress-control) * [3.5 Computer Use / desktop control risks](/handbook/3.-runtime-sandbox-and-autonomy/3.5-computer-use-desktop-control-risks) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk) * [5.2 Data exfiltration via tools and connectors](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors) # 3.5 Computer Use / desktop control risks Screen-and-click control can see and act across desktop apps, creating risks that differ from sandboxed code execution. *Last reviewed: August 18, 2026* {% hint style="info" %} Desktop control gives an agent the user's screen and mouse. That is different from a sandboxed tool call and needs endpoint-level governance. {% endhint %} ## Computer Use / desktop control risks: what security teams need to know Computer Use and desktop-control modes operate through screenshots, clicks, typing, and application context. They can cross from one app into another without the neat boundaries that API tools usually provide. The main control question is whether the organization can see and restrict what the agent can observe or do on the endpoint. Browser and network controls alone usually miss part of this surface. ## Common computer use / desktop control risks security failures * The agent can see secrets or personal data on screen. * A desktop app runs outside browser inspection. * Personal AI accounts are used on managed devices. * Screen-based prompt injection appears inside a document, page, or app. * Endpoint logs do not identify which actions were agent-driven. ## Computer Use / desktop control risks security controls checklist * Restrict desktop-control features to reviewed groups and devices. * Keep password managers, secret stores, HR, finance, and identity admin apps out of agent workflows. * Use endpoint controls to detect desktop app usage and personal-account sign-in. * Require approval before cross-app actions and external writes. * Log app, window class, user, session, approval, and outcome where possible. ## Anthropic ### Overview On the desktop, the Anthropic surfaces are Claude Desktop, Cowork, Claude Code, extensions, browser use, and computer use. Desktop extensions are MCP Bundles (.mcpb): archives containing a local MCP server and a manifest describing its capabilities. Computer use is different: Claude takes screenshots and clicks or types directly in approved applications, with no sandbox between Claude and those apps. Remote Cowork sessions on web or mobile can reach local files, browser state, or computer use only through the Claude Desktop app while the device is online. Computer use is currently a Pro and Max research preview, not a Team or Enterprise capability, so do not describe it as an enterprise control surface until that availability changes. ### Anthropic documentation * [Building Desktop Extensions with MCPB](https://github.com/modelcontextprotocol/mcpb) * [Getting Started with Local MCP Servers on Claude Desktop](https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop) * [When to use desktop and web connectors](https://support.claude.com/en/articles/11725091-when-to-use-desktop-and-web-connectors) * [Let Claude use your computer in Cowork](https://support.claude.com/en/articles/14128542-let-claude-use-your-computer-in-cowork) * [Use Claude Cowork safely](https://support.claude.com/en/articles/13364135-use-claude-cowork-safely) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview Keep hosted and local OpenAI control separate, because their evidence differs. ChatGPT agent mode is a hosted virtual computer, so its actions do not appear in endpoint telemetry. Local Computer Use runs in ChatGPT Desktop (Work / Codex) on macOS and Windows in both Work and Codex. It can see and operate graphical applications outside the project workspace, so operating-system permissions and the app's allowed-application list become part of the control plane. ChatGPT Desktop (Work / Codex) combines Chat, Work, and Codex in one installation. Review which executable is deployed, whether Computer Use is installed and enabled, which apps are approved, and which mode initiated the action. ### OpenAI documentation * [ChatGPT desktop app](https://learn.chatgpt.com/docs/app) * [Computer Use](https://learn.chatgpt.com/docs/computer-use) * [Moving to ChatGPT Desktop (Work / Codex)](https://help.openai.com/en/articles/20001276) * [Introducing ChatGPT agent: bridging research and action](https://openai.com/index/introducing-chatgpt-agent/) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) * [RBAC](https://help.openai.com/en/articles/11750701-rbac) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about computer use / desktop control risks ### What is Computer Use in AI tools? It is a family of capabilities where the agent observes a screen and acts through clicks, typing, and screenshots rather than structured API calls. It comes in two shapes: hosted virtual computers, such as ChatGPT agent mode, where the desktop belongs to the vendor, and local desktop control, where the agent acts on the user's own machine. The two need different controls and produce different evidence. ### Why is desktop control different from API tools? A screenshot captures whatever is visible, including notifications, password managers, other apps, and personal data, not just what was intentionally shared, and clicks can cross app boundaries that API scopes would have enforced. Screen content is also an injection surface: instructions rendered in a document or page can steer the agent. The tidy per-tool permission model largely disappears. ### Should desktop control be allowed on managed devices? Only for reviewed use cases, restricted user groups, and devices where endpoint telemetry can attribute agent actions. Use platform gates where they exist, such as role-based access for agent capabilities and enterprise controls for desktop extensions, rather than relying on user discipline. Handle personal AI accounts on managed devices first, since they bypass every workspace control. ### What apps should be off limits? Start with password managers, identity admin consoles, finance, HR, healthcare, legal, source-control administration, and production cloud consoles. The pattern: apps where one click is irreversible or one visible screen is a reportable exposure. Keep those apps closed during agent sessions rather than trusting the agent to ignore them. ### How can teams monitor desktop-control risk? Combine endpoint telemetry for which apps ran and which windows were active, AI-platform logs where they exist, app inventory for desktop extensions and local servers, and user reporting. Know the gaps in advance: hosted virtual computers leave no endpoint trace, and local extension activity may not appear in vendor compliance feeds. Section 6.6 maps evidence by surface. ## 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 ICT containment, resilience, continuity, and recovery. | | 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.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 * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy) * [3.1 What Even is an AI Sandbox?](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox) * [3.4 Internet access and browser automation](/handbook/3.-runtime-sandbox-and-autonomy/3.4-internet-access-and-browser-automation) * [4.6 Cross-app data flow and live artifacts](/handbook/4.-data-protection-and-residency/4.6-cross-app-data-flow-and-live-artifacts) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk) # 3.6 Scheduled and background tasks Unattended agent runs execute without a human watching, so they need stricter controls than interactive sessions. *Last reviewed: August 18, 2026* {% hint style="info" %} Unattended agents need tighter boundaries than interactive sessions. The user is not watching when the run drifts. {% endhint %} ## Scheduled and background tasks: what security teams need to know Scheduled and background tasks turn an AI workflow into automation. That can be useful for reporting, maintenance, triage, and repetitive analysis. It also removes the user's real-time judgment from the loop. The safe pattern is to start with read-only reporting, define stop conditions, test runs before scheduling, and require a stronger review before any background task writes to an external system. ## Common scheduled and background tasks security failures * A scheduled task inherits a broad user session or old credentials. * The task runs after the owner changes roles. * A report task gains write actions without a new review. * Failures are silent because no one owns monitoring. * The task runs against production data without a retention decision. ## Scheduled and background tasks security controls checklist * Assign every scheduled task an owner and review date. * Keep initial scheduled tasks read-only unless a write action is reviewed separately. * Define stop conditions, retry limits, and alert paths. * Log each run, data source, tool call, output location, and failure. * Review tasks after vendor releases, credential changes, and incidents. ## Anthropic ### Overview Anthropic has two documented scheduling surfaces. Claude Managed Agents support scheduled deployments for recurring agent work, with vault-based authentication so unattended runs do not carry static secrets; note that Managed Agents is in beta and sessions persist state server-side without current eligibility for zero data retention or HIPAA BAA coverage, which is a gate for regulated data. Cloud sandbox network access stays disabled unless the environment enables it, the right default for a run nobody is watching. Claude Cowork scheduled tasks are the end-user equivalent. They run with the same connectors, skills, and plugins as regular Cowork work and execute remotely by default, even when the user's computer is asleep. A task tied to a local folder or app runs locally and needs the desktop environment. Scheduled tasks can be created and reviewed across supported Cowork surfaces; the Cowork organization toggle remains the broad kill switch for Team and Enterprise. Claude Tag routines add scheduled jobs, channel watches, and repository-event follow-ups inside Slack. They inherit the channel's connections and permissions, and any channel member may be able to create standing work unless governance narrows that path. Record the routine owner and trigger, cap spend, and use the Claude Tag Audit view plus the channel thread and target-system logs to review what ran. ### Anthropic documentation * [Scheduled deployments](https://platform.claude.com/docs/en/managed-agents/scheduled-deployments) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Schedule recurring tasks in Claude Cowork](https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [Use Claude Cowork safely](https://support.claude.com/en/articles/13364135-use-claude-cowork-safely) * [Set up Claude Tag routines](https://claude.com/docs/claude-tag/users/proactivity) * [Audit and review Claude Tag](https://claude.com/docs/claude-tag/admins/audit) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview ChatGPT Work can run once, on a schedule or trigger, or as a monitor. Web scheduled tasks can use uploaded files, connected tools, skills, and plugins, but cannot work directly in a folder on the user's computer. Desktop scheduled tasks can use local projects and run in the project directory or an isolated worktree, and the computer and app must stay running when local files are required. The old split between ChatGPT Tasks and Codex Automations has converged into a Scheduled surface across Chat and Work, with desktop project and worktree execution for local tasks. Review each task's execution location, connected tools, local folder, credentials, and approval profile. CLI and IDE clients can prepare the workflow but do not provide the Scheduled management interface. ### OpenAI documentation * [Scheduled Tasks in ChatGPT](https://help.openai.com/en/articles/10291617-scheduled-tasks-in-chatgpt) * [Scheduled tasks](https://learn.chatgpt.com/docs/automations) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) ### Applicable Harmonic guides for OpenAI * [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) ## Frequently asked questions about scheduled and background tasks ### What are scheduled AI tasks? They are agent runs that start on a timer or trigger rather than with a person driving each step: one-off reminders, recurring reports, monitoring jobs, or unattended code maintenance. Current examples include ChatGPT Scheduled tasks from Chat or Work, Claude Cowork scheduled tasks, and Managed Agents scheduled deployments. The common property is that no one is watching when the run drifts. ### What should scheduled tasks be allowed to do? Start read-only: reporting, analysis, triage, and monitoring. Add write actions only after a separate review that names the systems written to and the failure handling. The inherited-permission question matters more than the schedule, because a task typically runs with its creator's connectors and sandbox settings, so review those, not just the cron line. ### What are stop conditions? Concrete bounds that end a run before it does damage: a maximum number of files changed, a spend or token ceiling, an error-rate threshold, a data-volume cap, or a denylist hit. For example, a nightly dependency-update automation should stop and alert, rather than retry, if it would modify more than twenty files or touch anything outside its repository. Without stop conditions, a misfiring task repeats its mistake on schedule. ### Who owns a background agent? Assign both a business owner accountable for the task existing and a technical owner accountable for its permissions, credentials, and failures, and record both in a task register. Ownership must survive role changes; a scheduled task that outlives its creator's tenure is a classic orphaned-automation finding. Review the register at the cadence set in 6.7. ### What should be monitored? Run status and failures, data sources touched, tool calls, output destinations, approval fallbacks, and volume anomalies against the task's baseline. Platform inboxes such as the Codex Triage inbox help, but only if someone owns triaging them. Silent failure is the characteristic scheduled-task incident: nothing alerts, and the gap is found weeks later. ## 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 ICT containment, resilience, continuity, and recovery. | | 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.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 * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity) * [3.2 Approval policies and least-privilege autonomy](/handbook/3.-runtime-sandbox-and-autonomy/3.2-approval-policies-and-least-privilege-autonomy) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility) * [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence) # 3.7 Remote access, dispatch and SSH Mobile-to-desktop bridges, remote dispatch, and SSH can let remote triggers drive local tools and files, expanding the attack surface. *Last reviewed: August 18, 2026* {% hint style="info" %} Remote triggers can drive local tools and files. Review them like privileged access, not like notifications. {% endhint %} ## Remote access, dispatch and SSH: what security teams need to know Remote access features let work start from a phone, browser, cloud queue, or SSH session and continue on another machine. That can help developers, but it also creates an access chain that spans identities and devices. The risk is inherited context. A remote trigger may reuse local credentials, project trust, paired devices, or workspace settings that the remote user does not see in full. ## Common remote access, dispatch and SSH security failures * A stale paired device can trigger work on a managed laptop. * SSH sessions run with broad filesystem and credential access. * A mobile dispatch starts a task in the wrong project context. * Remote runs bypass the approval expectations of local sessions. * Logs show local execution but not the remote trigger source. ## Remote access, dispatch and SSH security controls checklist * Inventory remote-trigger paths, including mobile, browser, SSH, CI, and cloud queues. * Require device review and stale pairing cleanup. * Log trigger source, target device, project, user, and credential context. * Restrict remote runs that can reach production systems. * Require stronger approval for remote writes and credential access. ## Anthropic ### Overview For Claude Code, the remote-access question is mostly a credential question. Credential precedence runs through cloud provider credentials, bearer token, API key, apiKeyHelper, OAuth token, and subscription OAuth credentials, so a dispatched or CI-triggered session inherits whichever of those resolves on the target machine, an inheritance the remote user never sees. Cloud execution is the cleaner remote path: isolated VMs with scoped credentials, configurable network controls, and audit logging. Managed settings can pin configuration on managed machines so a remote trigger cannot arrive into a looser policy than an interactive session would get. Cowork is now a separate remote path: sessions run on Anthropic's servers and can be steered from web, desktop, or mobile, but they reach local folders, browsers, and apps only through an online Claude Desktop host and its existing permissions. Managed Agents move the whole environment into Anthropic-managed or self-hosted sandboxes. ### Anthropic documentation * [Claude Code authentication](https://code.claude.com/docs/en/team) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview Codex remote connections are the concrete SSH surface in the ChatGPT desktop app. The app discovers hosts from \~/.ssh/config, requires Codex installed and authenticated on the remote host, and starts the remote app server over SSH. A remote project thread then runs commands, reads files, and writes changes on the remote host's filesystem and shell, so the remote machine's sandbox and approval posture is what contains it. Use SSH port forwarding with localhost listeners and never expose an unauthenticated app-server listener to shared or public networks. Beyond SSH, Codex cloud dispatch and the app's local, worktree, and cloud modes are remote-trigger paths with different inheritance, and Workspace Agents let external systems trigger published ChatGPT agents using access tokens that are distinct from platform and Compliance API credentials; inventory those tokens as non-human identities (see 1.5). Managed configuration keeps remote-reachable machines from drifting to permissive defaults. ### OpenAI documentation * [Remote connections (Codex)](https://developers.openai.com/codex/remote-connections) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Workspace Agents](https://developers.openai.com/workspace-agents) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about remote access, dispatch and SSH ### What is remote dispatch for AI agents? It is starting or steering agent work from a different device or context than where the work executes: phone to desktop, browser to cloud queue, laptop to an SSH host. The security property that matters is inheritance, because the run executes with the target environment's credentials, project trust, and settings, which the person triggering it may never see. ### Why is SSH risky for AI agents? An SSH session typically carries privileged shell and file access, and an agent operating through it inherits that full reach; Codex remote connections, for example, run commands and write files on the remote host's filesystem. The remote host's sandbox and approval settings become the effective policy, so a hardened laptop dispatching to a permissive server gets the server's posture. Follow the vendor guidance: port-forward over SSH with localhost listeners and never expose an unauthenticated agent listener to a shared network. ### What are stale paired devices? They are device or host entries that still permit remote triggering after the user, device, or role has changed: an old laptop in a device list, or a forgotten host in \~/.ssh/config that a remote-connection feature rediscovers. Where the product has a connections screen, such as Codex hosts under Settings > Connections, make reviewing and disabling entries part of access review. ### What should remote access logs include? The trigger source (device, surface, user), target machine, project context, credential type that authenticated the run, command class, approvals granted, and outcome. The pairing of trigger source with target matters most, because local execution logs alone make remote-triggered work look like the machine owner's own activity. ### Should remote writes be blocked? Block by default for hosts that can reach production systems or sensitive data, and allow only reviewed workflows with a named owner and logging. A useful floor: remote-triggered sessions should never run under a weaker approval policy than an interactive session on the same machine, enforced with managed configuration rather than convention. ## 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 ICT containment, resilience, continuity, and recovery. | *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 * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy) * [3.3 Network egress control](/handbook/3.-runtime-sandbox-and-autonomy/3.3-network-egress-control) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity) * [3.8 File and filesystem access controls](/handbook/3.-runtime-sandbox-and-autonomy/3.8-file-and-filesystem-access-controls) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) # 3.8 File and filesystem access controls How to scope which folders an agent can read and write, and how to keep home directories, secrets, and cloud-synced roots out of default access. *Last reviewed: August 18, 2026* {% hint style="info" %} File access should be scoped to the work. Keep home folders, cloud drives, and secret stores out of the agent's normal reach. {% endhint %} ## File and filesystem access controls: what security teams need to know Agents are often useful because they can read and edit files. That access should be intentional. A broad folder grant can expose unrelated projects, personal files, credentials, and synced documents. Good filesystem control starts before the session. Choose the workspace, exclude sensitive paths, decide what can be written, and make destructive actions hard to approve by accident. ## Common file and filesystem access controls security failures * The agent starts in the user's home directory. * Cloud-synced folders expose files from unrelated teams. * Secrets live in the same project root as the work. * Generated files overwrite source or evidence without review. * The agent can delete or rename broad directory trees. ## File and filesystem access controls security controls checklist * Start agents in a narrow project directory. * Keep home, Desktop, Downloads, cloud drives, password stores, and secret stores outside normal scope. * Use deny rules for `.env`, key files, tokens, and credential directories. * Require approval for deletes, moves, broad rewrites, and generated code touching sensitive paths. * Log denied reads and writes to sensitive locations. ## Anthropic ### Overview Claude Code is where filesystem policy is enforceable. It starts from read-only permissions and prompts before edits, and permission rules can deny reads and edits of specific paths such as .env files, key material, and credential directories. Deny rules take precedence over ask and allow, so a sensitive-path deny list holds even against a broad allow rule, and managed settings push those rules organization-wide, which is how a file-access standard becomes more than a team convention. Two adjacent surfaces widen local file reach: desktop extensions and local MCP servers run with local access on Claude Desktop and Claude Code, while Cowork remote sessions can reach folders connected through Claude Desktop only while that app is online. Those files are processed in the remote session on Anthropic's servers, and each local call is checked against the member's folder permissions. Managed Agents cloud sandboxes contain file work inside an isolated Linux container instead. Claude Tag channel sessions can read and write files inside their per-thread hosted sandbox, but files that exist only there disappear when the sandbox is released. Persisted outputs must be posted to Slack or pushed to a connected repository or service, which creates a separate sharing and authorization event. Do not confuse ephemeral sandbox storage with a guarantee that the thread, memory, transcript, or exported result is ephemeral. ### Anthropic documentation * [Configure permissions](https://code.claude.com/docs/en/permissions) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Code security](https://code.claude.com/docs/en/security) * [Getting Started with Local MCP Servers on Claude Desktop](https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop) * [Cloud sandbox reference](https://platform.claude.com/docs/en/managed-agents/cloud-sandboxes-reference) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview For Codex, sandbox mode is the filesystem policy. Read-only mode lets the agent inspect but not change files; workspace-write limits writes to the workspace, with command network access off by default; danger-full-access removes the boundary and belongs only in disposable environments. The mode names are the review vocabulary: "which mode, over which directory" answers most file-access questions, and approval policy governs when the agent can escalate past the mode's limits. Managed configuration can pin which sandbox modes and approval policies are available, so organizations can keep full access out of reach for standard users rather than relying on prompts. Desktop Work uses the same local permission plane as Codex and can open local folders or projects. Work on web and mobile cannot directly access computer files; it uses uploaded files, workspace resources, and connected systems instead. Treat those as data flows rather than filesystem grants. ### OpenAI documentation * [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) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about file and filesystem access controls ### What folders should AI agents access? Only the project directory the task needs, added explicitly and removed when the work ends. Broad grants such as home directories, Documents, or whole-drive access expose unrelated projects, personal files, and synced content the user forgot was there. The folder choice is the single highest-leverage filesystem control because everything else operates inside it. ### Should agents read `.env` files? Block them by default with deny rules, along with key files, token caches, and credential directories. If a task genuinely needs configuration, provide sanitized examples or inject secrets through an approved mechanism at runtime rather than letting the agent read live values. A leaked .env in a prompt or log is a credential incident, not a hygiene issue. ### Are cloud-synced folders safe? They are risky as agent workspaces on two counts: they often contain files from unrelated teams and projects, and agent writes propagate through sync, so an unwanted mass edit or delete replicates to every device and collaborator before anyone reviews it. Prefer a local, narrowly scoped project directory and copy results into synced locations deliberately. ### How should deletes be handled? Require explicit approval for deletes, renames, moves, and any operation touching many files, and make the approval show the full scope before it executes. Version control is the safety net for repositories; for everything else, prefer soft-delete or staging patterns so a wrong approval is recoverable. ### What file activity should be logged? For the filesystem specifically: denied reads and writes on sensitive paths, which are the high-signal events, plus successful writes and deletes with paths, the workspace root for the session, and any change to file-access policy itself. Pair this with the session-level sandbox-mode logging from 3.1 so an investigator can tie a file event to the boundary that allowed it. ## 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 ICT containment, resilience, continuity, and recovery. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies and Inference Security 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA technical access, integrity, transmission, availability, and audit safeguards. | *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 * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy) * [3.1 What Even is an AI Sandbox?](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox) * [4.7 Secrets and credential hygiene in prompts and tools](/handbook/4.-data-protection-and-residency/4.7-secrets-and-credential-hygiene-in-prompts-and-tools) * [5.2 Data exfiltration via tools and connectors](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility) # 3.9 Central hosted-agent runtime hardening For agents you run yourself on frameworks or cloud platforms — container isolation, egress, secrets, tool sandboxing, and audit are yours to own end-to-end. *Last reviewed: August 18, 2026* {% hint style="info" %} For agents you host, the runtime is your control plane. Own isolation, secrets, egress, logging, and kill switches before production. {% endhint %} ## What security teams need to know about central hosted-agent runtime hardening A hosted agent is an application runtime that calls models and tools. The provider may host the model, but your team usually owns the container, network policy, credentials, tool registry, retrieval systems, and logs. Treat each agent like a service with extra autonomy. It needs standard app security plus controls for tool choice, prompt injection, model calls, and human approval. ## Common central hosted-agent runtime hardening security failures * Multiple agents share the same runtime and secrets. * Outbound network access is open for convenience. * Tools run in the same process as the orchestrator. * Rate limits and spend limits are not tied to agent identity. * Logs omit prompts, retrieved context, or tool-call outcomes. ## Central hosted-agent runtime hardening security controls checklist * Authenticate inbound triggers and protect them against replay, duplication, and unauthorized scheduling. * Run each task in a tenant- and task-isolated environment; prefer an ephemeral environment for high-risk work. * Separate the control plane, orchestrator, model access, and tool execution boundaries where feasible. * Issue task-scoped, short-lived credentials through a secret broker or vault instead of injecting broad static secrets. * Deny network egress by default and own every allowed destination. * Restrict inbound access, local bindings, metadata services, management sockets, and internal network routes. * Pin and verify container images, tools, agent definitions, models, and deployment artifacts. * Set concurrency, duration, recursion, token, spend, rate, storage, and action limits per agent and environment. * Require approval or deterministic policy for actions outside the approved baseline. * Capture initiator, agent identity, version, tool, approval, target, result, spend, and termination events. * Provide a tested kill switch that stops work and revokes active credentials, sessions, queues, and downstream access. * Define quarantine, rollback, recovery, and evidence-preservation procedures before production. ## Minimum production architecture **Ingress.** Authenticate every API call, webhook, queue message, schedule, and remote dispatch. Use nonces, timestamps, idempotency keys, and narrow trigger identities where the protocol supports them. Reject stale or duplicate work. **Run boundary.** Create a distinct security context for each tenant and task. Reset or destroy state after the run unless persistence is an explicit requirement with its own access and retention controls. Do not let one task inherit another task's files, memory, browser session, network state, or credentials. **Credentials.** Resolve credentials at execution time from a broker or vault. Bind them to the task identity, tool, destination, and duration. Prevent models and untrusted tools from reading raw secret values when a mediated action can perform the operation instead. **Control plane.** Keep deployment, policy, identity, secrets, and termination controls outside the agent's writable runtime. An agent must not be able to change its own sandbox, policy, logging, budget, or kill switch. **Recovery.** Preserve the triggering request, agent and tool versions, approvals, actions, outputs, and runtime evidence before cleanup. Practice stopping active work, draining queues, revoking credentials, quarantining outputs, and restoring the previous approved version. ## Anthropic ### Overview The build-or-rent decision comes first: a Messages API loop your team hosts, or Claude Managed Agents. Managed Agents define an agent by model, system prompt, tools, MCP servers, skills, environment, session, and event history, and run in Anthropic-managed cloud sandboxes (isolated Linux containers with network access disabled by default) or self-hosted sandboxes. Credentials go through vault-based authentication rather than baked-in secrets, and multi-agent sessions pin referenced agents to versions resolved when the coordinator is created or updated, which is a real supply-chain control. Two facts gate production use: Managed Agents is in beta and requires the beta header on all requests, and sessions persist state server-side with no current zero data retention or HIPAA BAA eligibility, so regulated workloads need a different home for now. For self-built loops, the tool boundary is yours: tool definitions, descriptions, schemas, and results are part of the trust boundary, and the MCP connector's allowlist and denylist toolsets are the narrowing mechanism. Do not treat Cowork remote sessions as customer-hosted runtimes. They run in temporary Anthropic-managed sandboxes with proxy-mediated egress, and endpoint tools cannot inspect the sandbox. If a workflow needs customer-owned container, network, and evidence controls, use a self-hosted API loop or a supported self-hosted Managed Agents sandbox instead. Claude Tag is another Anthropic-hosted runtime, optimized for shared Slack work rather than a customer-built agent. Each thread receives an isolated sandbox, requests leave through Agent Proxy, and connected systems see the dedicated service account. Include it in the hosted-runtime inventory when a channel can reach production repositories, data warehouses, ticketing systems, or monitoring tools. ### Anthropic documentation * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Cloud sandbox reference](https://platform.claude.com/docs/en/managed-agents/cloud-sandboxes-reference) * [Multi-agent sessions](https://platform.claude.com/docs/en/managed-agents/multi-agent) * [Tool use with Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview) * [MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector) * [Using Agent Skills with the API](https://platform.claude.com/docs/en/build-with-claude/skills-guide) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) * [How Claude Tag agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) ## OpenAI ### Overview The supported OpenAI path for self-hosted agent runtimes is the Agents SDK, which manages the agent loop, tool execution, handoffs, sessions, guardrails, approvals, and tracing, the harness features a hardening review should verify are actually configured. Agent Builder is now legacy: OpenAI has scheduled its shutdown for November 30, 2026, with published workflows exportable as Agents SDK code, so treat any Agent Builder workflow in production as a migration item with a deadline. Codex SDK and Codex-as-MCP-server extend the same review to coding agents embedded in delivery workflows. For credentials and identity, prefer workload identity federation, which exchanges external identity tokens for short-lived OpenAI access tokens through scoped service-account mappings, over long-lived API keys in the runtime, and keep staging and production in separate projects. Workspace Agents deserve a dedicated line: their access tokens are distinct from platform and Compliance API credentials, and a published agent with agent-owned connections can expose data through the builder's credentials rather than the end user's. ChatGPT Work is also vendor-hosted on web and mobile, but it is a user task surface rather than a customer-hosted application runtime. Its workspace RBAC, plugins, apps, and Work compliance evidence do not replace the isolation, secrets, egress, tracing, and kill switches required for an Agents SDK service. Desktop Work follows local Codex controls and belongs in the local runtime model instead. ### OpenAI documentation * [Agents SDK](https://developers.openai.com/api/docs/guides/agents) * [Agent Builder](https://developers.openai.com/api/docs/guides/agent-builder) * [Using tools](https://developers.openai.com/api/docs/guides/tools) * [Codex SDK](https://developers.openai.com/codex/sdk) * [Workspace Agents](https://developers.openai.com/workspace-agents) * [Workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation) * [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about central hosted-agent runtime hardening ### What is a hosted-agent runtime? It is the application infrastructure that runs an agent as a service: the orchestration loop, tool registry, model calls, secrets, retrieval systems, and logs. The model may be the vendor's, but the runtime is typically yours, whether built on the Messages API or the OpenAI Agents SDK, or rented through Claude Managed Agents. Hardening it is standard service security plus agent-specific tool and injection controls. ### Who owns hosted-agent security? It is shared, and the split should be written down. The provider owns model hosting and, for managed offerings, the sandbox substrate, such as the Anthropic-managed containers behind Managed Agents. Your team owns everything it configures: tool registry, MCP server selection, credentials, egress policy, approval gates, logging, and deployment. A hardening review that cannot name an owner for each of those has found its first gap. ### Should tools run in the same process? Avoid it for risky tools. Sandboxing tool execution away from the orchestrator means a compromised or injected tool call cannot read the orchestrator's secrets or memory, and it gives containment and per-tool logging a natural seam. MCP makes the boundary explicit; the specification itself notes that tools can represent arbitrary code execution and require careful consent and authorization. ### What limits should agents have? Per agent and per environment: rate limits, spend and token ceilings, action counts, connector scopes, and network allowlists, tied to the agent's identity so a runaway or hijacked agent hits its own ceiling rather than a shared one. Limits double as detection, because a spend spike on one agent identity is one of the cheapest anomaly signals available. ### What logs matter most? Model calls, tool calls, input classification, retrieved-context identifiers, action results, agent identity, and deployment version: enough to reconstruct what the agent saw, decided, and did in a session. Version matters more than teams expect; multi-agent setups that pin referenced agent versions make "which version acted" answerable, and unpinned setups do not. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports runtime monitoring, version evidence, and intervention controls. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports ICT containment, resilience, continuity, and recovery. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies and Inference Security 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA technical access, integrity, transmission, availability, and audit safeguards. | *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 * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy) * [3.1 What Even is an AI Sandbox?](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox) * [3.3 Network egress control](/handbook/3.-runtime-sandbox-and-autonomy/3.3-network-egress-control) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility) # 4. Data Protection & Residency How to control sensitive data in AI prompts, outputs, files, tools, and agent actions — including DLP, classification, residency, retention, and secrets hygiene. *Last reviewed: August 18, 2026* {% hint style="info" %} AI tools create data exit points and derived stores that traditional DLP may not see: prompts, tool calls, outputs, embeddings, vector stores, caches, evaluation data, and cross-app artifacts. This section covers how to classify, control, retain, delete, and audit sensitive data across those paths. {% endhint %} ## Articles in this section 1. [4.1 DLP for GenAI](/handbook/4.-data-protection-and-residency/4.1-dlp-for-genai) 2. [4.2 Data classification for AI prompts and outputs](/handbook/4.-data-protection-and-residency/4.2-data-classification-for-ai-prompts-and-outputs) 3. [4.3 Data residency and regional inference](/handbook/4.-data-protection-and-residency/4.3-data-residency-and-regional-inference) 4. [4.4 Retention and Zero Data Retention](/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention) 5. [4.5 Training opt-out and data usage](/handbook/4.-data-protection-and-residency/4.5-training-opt-out-and-data-usage) 6. [4.6 Cross-app data flow and live artifacts](/handbook/4.-data-protection-and-residency/4.6-cross-app-data-flow-and-live-artifacts) 7. [4.7 Secrets and credential hygiene in prompts and tools](/handbook/4.-data-protection-and-residency/4.7-secrets-and-credential-hygiene-in-prompts-and-tools) ## Frequently asked questions **Why doesn't traditional DLP protect against AI data leakage?**\ Traditional DLP can inspect files and traffic on the channels it covers, but AI introduces paths that many deployments do not inspect: pasted prompts, uploads, native desktop clients, API requests, tool calls, connectors, and agent-generated actions. The gap is coverage, not that DLP is inherently unable to recognize sensitive data. Map each AI surface to an enforcement point, then test browser, endpoint, API, and agent paths separately. **What data types are most commonly exposed through AI tools?**\ Prioritize credentials and secrets, source code, customer and employee personal data, financial information, legal and contract material, and internal strategy or product documents. Do not treat this as a universal ranking; exposure patterns depend on the organization, workforce, and tools. Use pilot and production telemetry to tune policies around the data users actually submit. **Does Zero Data Retention mean my data never touches the vendor's infrastructure?**\ Not necessarily. Zero Data Retention generally means eligible customer content is not retained after processing under vendor-specific terms. The data still transits vendor infrastructure, and some endpoints or features may retain application state or be ineligible for ZDR. Metadata, third-party tools and connectors, files, background jobs, and customer-controlled storage can follow different rules. Verify scope by product, endpoint, region, and subprocessor before treating ZDR as a control. **What AI data stores need separate lifecycle controls?**\ Include source documents, uploads, knowledge bases, embeddings, vector stores, fine-tuning and evaluation datasets, provider caches, temporary files, backups, traces, compliance exports, and generated artifacts. Define an owner, region, retention period, access model, deletion path, and verification method for each store. ## Related handbook guidance * [AI Security Handbook](/) * [2.6 AI hooks: inference controls and lifecycle automation](/handbook/2.-supply-chain-and-extensibility/2.6-ai-hooks-inference-controls-and-lifecycle-automation) * [5.2 Data exfiltration via tools and connectors](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors) * [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform) # 4.1 DLP for GenAI How to detect and control sensitive data moving into prompts, files, tools, connectors, and outputs where classic DLP often lacks visibility. *Last reviewed: August 18, 2026* {% hint style="info" %} DLP for AI starts where data enters prompts and tools. Classic email and web DLP will miss part of the path unless it sees AI-specific context. {% endhint %} ## DLP for GenAI: what security teams need to know AI changes the DLP problem because the exit point is often a prompt, a file upload, a connector call, a browser action, or an API request. The same sensitive record can move through several of those surfaces in one session. Effective GenAI DLP combines content detection with context. The policy should know which user, app, destination, connector, action, and data class are involved. ## Common DLP for GenAI security failures * The control sees the browser but not the desktop app or CLI. * A paste is blocked, but the same data moves through a file upload. * Tool parameters and outputs are not inspected. * The DLP rule sees a secret but cannot tell whether the destination is approved. * Users move to personal accounts when enterprise tools are blocked. ## DLP for GenAI security controls checklist * Map all AI data entry points: prompt, paste, upload, connector, browser, desktop, and API. * Classify data before deciding which AI surfaces may receive it. * Inspect tool parameters and outputs where telemetry allows it. * Use block, warn, justify, and allow modes based on data class and destination. * Review incidents for bypass paths across blocked and allowed events. ## Anthropic ### Overview Anthropic's enforcement points sit in roles, connector policy, and managed settings rather than in a single DLP console. Enterprise custom roles gate capabilities per surface — chat, web search, skills, Claude Code, Cowork, and Claude for Chrome — and connector permissions can require approval, block access, or always allow it. The organization-wide per-tool policy acts as a ceiling: role grants can narrow access within it but cannot widen it, and enforcement fails closed toward denial. On the desktop, Team and Enterprise owners can enable or disable public desktop extensions, and enterprise policy controls override in-app allowlist and blocklist settings. Cowork and the Claude Office add-ins need separate telemetry paths: both are outside the Compliance API today, while Anthropic offers OpenTelemetry exports that can include full prompts, tool parameters, file paths, document URLs, and user identity. Configure filtering, access, and retention before that stream reaches a broad SIEM index. Claude Tag moves the DLP boundary into Slack channels. Channel members share the agent's Access bundles, memory, repositories, and service-account authority, while direct messages use personal connectors. Restrict who can invoke it, keep sensitive credentials and repositories out of organization-wide bundles, and include Slack retention, Agent Proxy destinations, and target-system logs in the data-flow review. ### 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-claude-s-capabilities) * [Getting Started with Local MCP Servers on Claude Desktop](https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Monitoring](https://code.claude.com/docs/en/monitoring-usage) * [Monitor Claude Cowork activity with OpenTelemetry](https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry) * [Work across Microsoft 365 apps](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps) * [Configure a custom OpenTelemetry collector for Office agents](https://support.claude.com/en/articles/14447276-configure-a-custom-opentelemetry-collector-for-office-agents) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI's closest DLP primitives are Lockdown Mode, RBAC, and app action controls. Lockdown Mode limits outbound web and external-service access to reduce prompt-injection data exfiltration, and admins assign it through RBAC roles; note that it does not affect Codex network access, so Codex needs its own egress controls. RBAC custom roles also gate apps, GPTs, canvas networking, and skills per group. For connected apps, action control determines whether an app can read only, take actions, or use a custom set of actions. ChatGPT Work, ChatGPT for Excel or Google Sheets, and ChatGPT for PowerPoint can carry approved apps and skills into document workflows, so DLP must follow the source file, connected app, generated artifact, and final share. OpenAI's Work guidance says the Compliance API covers user messages and responses across Chat, Work, and Codex, but not files, actions, or tool calls. ### OpenAI documentation * [Lockdown Mode](https://help.openai.com/en/articles/20001061) * [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) * [Codex Governance](https://developers.openai.com/codex/enterprise/governance) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [ChatGPT for Excel and Google Sheets](https://help.openai.com/en/articles/20001063) * [ChatGPT for PowerPoint](https://help.openai.com/en/articles/20001242) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about DLP for GenAI ### What is GenAI DLP? GenAI data loss prevention is the set of controls that detect and govern sensitive data moving into and out of AI tools such as ChatGPT, Claude, Copilot, and Gemini. It inspects prompts, pasted text, file uploads, connector and tool calls, and generated outputs rather than just email and web traffic. The decision logic pairs content detection with context: which user, account type, surface, and destination are involved. ### Why does classic DLP miss AI risk? Classic DLP focuses on email, web uploads, and storage, so it tends to see the browser but not desktop apps, CLIs, connectors, or API traffic. AI workflows move the same record through several of those surfaces in one session, and tool parameters or model outputs are rarely inspected at all. Coverage needs to follow the surface list, not the network perimeter. ### Should DLP block all sensitive data in AI tools? No. Blanket blocking pushes users toward personal accounts, which is usually a worse outcome than monitored enterprise use. Match the response — block, warn, justify, or allow — to the data class, the destination, the user's role, and whether the surface is an approved enterprise tenant. ### What should be monitored first? Start with secrets and credentials, regulated records, customer data, source code, and financial data, plus any use of personal accounts for corporate work. These classes produce the highest-impact incidents and the clearest policy decisions. Expand into lower-sensitivity classes once triage keeps up with the alert volume. ### How should DLP alerts be triaged? Triage on data class, destination, and account type first: a secret sent to a personal account outranks internal data in an approved workspace. Then check whether the event created a durable external copy, such as a shared artifact or a connector write. Close the loop by reviewing blocked and allowed events together to spot bypass paths. ## 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 data protection, integrity, and third-party service review. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Data Protection 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA PHI identification, minimum-necessary handling, retention, and disclosure controls. | *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 * [4. Data Protection & Residency](/handbook/4.-data-protection-and-residency) * [4.2 Data classification for AI prompts and outputs](/handbook/4.-data-protection-and-residency/4.2-data-classification-for-ai-prompts-and-outputs) * [2.6 AI hooks: inference controls and lifecycle automation](/handbook/2.-supply-chain-and-extensibility/2.6-ai-hooks-inference-controls-and-lifecycle-automation) * [5.2 Data exfiltration via tools and connectors](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors) * [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform) # 4.2 Data classification for AI prompts and outputs Which data classes may touch which AI tools and how to enforce the matrix technically across browsers, endpoints, APIs, and agents. *Last reviewed: August 18, 2026* {% hint style="info" %} AI policy needs a data-class matrix. Users should know which data classes can enter which tools before a prompt is written. {% endhint %} ## Data classification for AI prompts and outputs: what security teams need to know Data classification turns AI policy from a slogan into a decision table. The table should say which data classes are allowed in each tool, account type, connector, model endpoint, and deployment mode. Classification should cover outputs too. An AI-generated answer can contain secrets, customer data, source code, or regulated information copied from context. ## Common data classification for AI prompts and outputs security failures * The policy says confidential data is restricted, but tools are not mapped to data classes. * Outputs are shared externally without reclassification. * Users cannot tell whether source code, logs, or tickets count as sensitive. * Artifacts and connector writes inherit the source data class but are never relabeled. * Regulated data is allowed in chat but not in API workflows, or the reverse. ## Data classification for AI prompts and outputs security controls checklist * Define data classes that users understand. * Create a class-to-tool and class-to-action matrix. * Include prompts, uploads, retrieved context, tool parameters, outputs, and artifacts. * Require stronger controls for regulated data, customer data, source code, and secrets. * Review output-sharing paths such as links, exports, artifacts, and connector writes. ## Anthropic ### Overview A class-to-tool matrix maps onto three Anthropic levers. Enterprise custom roles decide which groups get which capabilities — chat, code execution and file creation, skills, Claude Code, Cowork — so a role can embody "this team may use this surface with this data class." Connector permissions add the class-to-action dimension: each connector can require approval, be blocked, or be always allowed, and connectors act according to the person's source-system permissions, so the source ACL remains part of the effective classification. Outputs need their own row in the matrix. Artifacts require the code execution and file creation capability and inherit whatever data class entered the conversation. The Claude Office add-ins can pass context between open Excel, PowerPoint, Word, and Outlook files, so classify the cross-app session at the highest input class and review the target file before writing into it. For Claude Tag, classify the Slack channel, its inherited workspace memory, and every attached Access bundle together. Organization-wide and workspace-level credentials or repositories flow into narrower scopes, while a private channel can add more access. Do not attach a high-classification data source to a broad channel simply because the Slack channel itself began as low sensitivity. ### 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-claude-s-capabilities) * [What are artifacts and how do I use them?](https://support.claude.com/en/articles/9487310-what-are-artifacts-and-how-do-i-use-them) * [Work across Microsoft 365 apps](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps) * [What is Claude Tag?](https://support.claude.com/en/articles/15594475-what-is-claude-tag) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview On the OpenAI side the matrix maps to RBAC and app controls. RBAC custom roles assign apps, GPTs, projects, canvas networking, and skills to groups, with effective permissions taking the maximum across a user's roles — worth remembering when one broad role quietly widens a narrow one. Enterprise and Edu workspaces can assign specific apps to custom roles, so app access itself can follow data-class boundaries. Action control is the class-to-action lever: it determines whether a connected app can read only, take actions, or use a custom set of actions. Work can create documents, spreadsheets, presentations, reports, and Sites from files and connected sources. Classify every deliverable like its most sensitive input, and treat a published Site as an application release rather than an ordinary chat output. ### OpenAI documentation * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [Apps in ChatGPT](https://help.openai.com/en/articles/11487775-apps-in-chatgpt) * [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) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Creating and managing ChatGPT Sites](https://help.openai.com/en/articles/20001339) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about data classification for AI prompts and outputs ### What data classes matter for AI security? Most programs reuse their existing scheme — public, internal, confidential, regulated — and add AI-specific classes: secrets and credentials, source code, customer content, and privileged operational data such as incident tickets. The AI-specific classes matter because they move through prompts and tool calls in ways stored-data controls never see. Keep the list short enough that users can apply it while writing a prompt. ### What is a class-to-tool matrix? It is a decision table that maps each data class to the AI tools, account types, connectors, and actions allowed to receive it, plus the required controls. For example: source code may enter Claude Code or Codex under an enterprise account with secret files denied, but never a personal chatbot account. It turns "be careful with confidential data" into a rule someone can check. ### Should AI outputs be classified? Yes. Outputs inherit the classification of what went in: an answer summarizing a confidential document is confidential, and an artifact built from customer data carries customer data. Reclassify before outputs are shared, exported, or written into another system through a connector. ### How should users know what is allowed? Publish the matrix as short, tool-specific rules with examples — "customer records: allowed in the enterprise ChatGPT workspace, never in personal accounts" — rather than a long policy memo. Put the rule where the decision happens: onboarding, tool launch pages, and DLP warning messages. One good example per class beats a page of definitions. ### What is the biggest classification gap? Most teams classify stored data but not data in motion through AI: prompt inputs, retrieved context, tool parameters, and generated outputs. Output reclassification is the most common miss — artifacts and connector writes inherit the source data class, but nothing enforces the label downstream. Close the gap by giving outputs and artifacts their own rows in the matrix. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports input-data relevance and governance. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports data protection, integrity, and third-party service review. | | G.4 Colorado AI Act and the US state patchwork | Conditional: for covered Colorado ADMT, this supports the personal-data inputs and outputs used in a consequential decision. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Data Protection 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 data-governance and classification records. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA PHI identification, minimum-necessary handling, retention, and disclosure controls. | *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 * [4. Data Protection & Residency](/handbook/4.-data-protection-and-residency) * [4.1 DLP for GenAI](/handbook/4.-data-protection-and-residency/4.1-dlp-for-genai) * [4.4 Retention and Zero Data Retention](/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention) * [4.6 Cross-app data flow and live artifacts](/handbook/4.-data-protection-and-residency/4.6-cross-app-data-flow-and-live-artifacts) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) # 4.3 Data residency and regional inference How to keep AI processing in-region using cloud model hosting and vendor-specific regional controls rather than assuming a plan setting solves residency. *Last reviewed: August 18, 2026* {% hint style="info" %} Residency is a data-flow question. A region setting helps only if processing, storage, logs, support access, and subprocessors match the requirement. {% endhint %} ## Data residency and regional inference: what security teams need to know AI residency requirements often come from customer contracts, regulated industries, or local law. The model provider, cloud host, logging pipeline, and retrieval store may each have a different location story. The safest way to document residency is a data-flow map. Show where prompts, files, embeddings, tool outputs, logs, eval data, and human support access go. ## Common data residency and regional inference security failures * A team assumes an enterprise plan keeps inference in-region without checking endpoint behavior. * Logs or telemetry leave the approved region. * Files are stored in one region while inference occurs in another. * A third-party connector moves data across borders. * Support access and subprocessors are not included in the evidence pack. ## Data residency and regional inference security controls checklist * Map processing, storage, logs, telemetry, support, and subprocessors separately. * Prefer regional cloud endpoints when residency is a hard requirement. * Document cross-border transfers and legal basis with counsel. * Keep retrieval stores and vector databases in the same approved region where required. * Review vendor retention and support-access terms before regulated rollout. ## Anthropic ### Overview As of the last review date, Anthropic's first-party residency controls work at two levels. A per-request `inference_geo` parameter selects where inference runs — `global` by default, or `us` — and workspace-level `allowed_inference_geos` and `default_inference_geo` settings constrain what requests in a workspace may choose. Workspace geo, which governs where data is stored at rest and where endpoint processing happens, currently supports only `us` and cannot be changed after workspace creation, so check the current documentation before committing to storage in any other region. The deployment route changes the mechanism: on Amazon Bedrock and Google Cloud Vertex AI, the inference region is determined by the endpoint URL or inference profile rather than the `inference_geo` parameter. Map Managed Agents separately because sessions persist state server-side. Map Cowork separately too: remote sessions and their files live on Anthropic's servers, and local files opened through Claude Desktop are processed there. Do not assume a Claude workspace region setting covers Cowork until the current documentation and contract say so. ### Anthropic documentation * [Data residency (Claude Platform)](https://platform.claude.com/docs/en/manage-claude/data-residency) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Claude Code data usage](https://code.claude.com/docs/en/data-usage) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview As of the last review date, ChatGPT Enterprise and Edu offer data residency — storage at rest — in Australia, Canada, Europe (EEA plus Switzerland), India, Japan, Singapore, South Korea, the UAE, the UK, and the US. Inference residency, meaning in-region GPU execution on customer content, is narrower: it is available only in Europe, the US, and the UAE, and requires data residency enabled in the same region. Even then, workspace metadata, billing information, and user logins may be stored outside the selected region, so the setting is not a complete data-flow answer on its own. The API Platform is a separate control plane with its own residency model. ChatGPT Work also needs feature-level checking: OpenAI says Work inherits workspace protections, but residency and inference coverage varies by plan, region, surface, and capability. ChatGPT Sites is explicitly outside data residency at launch, including deployed sites, code, storage, generated artifacts, and related logs. Region and feature lists change, so verify them before making contract commitments. ### OpenAI documentation * [Data residency and inference residency for ChatGPT](https://help.openai.com/en/articles/9903489-data-residency-and-inference-residency-for-chatgpt) * [Data controls in the OpenAI platform](https://developers.openai.com/api/docs/guides/your-data) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Creating and managing ChatGPT Sites](https://help.openai.com/en/articles/20001339) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about data residency and regional inference ### What is data residency for AI? It is the requirement that certain data is processed or stored only in approved regions, usually driven by customer contracts, sector regulation, or local law. For AI systems it splits into at least two questions: where inference runs on your content, and where prompts, files, and session state are stored at rest. Vendors document and sell these separately — OpenAI, for example, distinguishes data residency from inference residency — so treat them as separate controls. ### Does a regional endpoint solve residency? Only for the inference leg of the flow. Logs, telemetry, retrieval stores, support access, and subprocessors can still cross borders, and vendor exceptions apply even inside the residency feature — ChatGPT data-residency workspaces may still store workspace metadata, billing information, and user logins outside the selected region. Map the full flow and get the exceptions in writing before certifying a deployment as in-region. ### What should a residency evidence pack include? Include a data-flow diagram covering prompts, files, embeddings, logs, and support access; the vendor's residency documentation with capture dates; screenshots of the configured regions and settings; the subprocessor list; retention terms; and named control owners. Contract language and technical settings should point at each other. Refresh the pack when the vendor updates its region lists, which happens regularly. ### Are embeddings part of residency review? Yes. Embeddings are derived from source content and can often be matched or partially reconstructed back to it, so regulators and customers generally treat them as the same data class as the source. Keep vector stores and retrieval indexes in the approved region and include them in the data-flow map. ### Who should approve residency decisions? Hard residency requirements need security, legal, compliance, data governance, and the business owner in the same review, because the trade-offs cross all of them — a region constraint can rule out features or require contract amendments such as a ZDR addendum. Record the decision and its assumptions so it can be re-checked when vendor region support changes. ## 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 data protection, integrity, and third-party service review. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Data Protection guidance. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for ePHI, regional and subprocessor mapping supports risk and contract review; HIPAA does not itself require US data residency. | *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 * [4. Data Protection & Residency](/handbook/4.-data-protection-and-residency) * [4.4 Retention and Zero Data Retention](/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention) * [G.3 DORA and AI resilience in financial services](/reference/governance-and-frameworks/g.3-dora-and-ai-resilience-in-financial-services) * [G.9 HIPAA controls for AI systems handling PHI](/reference/governance-and-frameworks/g.9-hipaa-controls-for-ai-systems-handling-phi) * [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform) # 4.4 Retention and Zero Data Retention Where conversations, prompts, files, logs, and tool data live, for how long, and what Zero Data Retention does and does not cover. *Last reviewed: August 18, 2026* {% hint style="info" %} Retention settings decide what the provider keeps. They do not automatically cover every feature, log, connector, local file, or downstream system. {% endhint %} ## What security teams need to know about retention and Zero Data Retention Retention is a contract and architecture topic. A provider may handle API prompts differently from chat messages, files, compliance exports, abuse monitoring, or feature-specific data. Zero Data Retention can be valuable for sensitive workflows, but it has scope limits. Treat ZDR as one control in a broader data-flow review. ## Common retention and Zero Data Retention security failures * ZDR is assumed to cover features that are excluded. * Local conversation stores and downloaded files are ignored. * Telemetry keeps prompts or tool parameters longer than expected. * Compliance exports are retained without a lifecycle owner. * Users rely on consumer settings for enterprise data. ## Retention and Zero Data Retention security controls checklist * Record retention behavior by product surface, feature, endpoint, authentication path, and storage location. * Inventory prompts, responses, files, tool payloads, memory, retrieval indexes, embeddings, fine-tuning and evaluation data, caches, logs, compliance exports, backups, and abuse-monitoring copies. * Confirm Zero Data Retention scope and exclusions before regulated use. * Map every derived store back to its source data class and owner. * Define region, encryption, key ownership, access, retention, deletion, legal hold, and privacy-request handling for each store. * Synchronize source-system permissions and deletions with knowledge bases and vector stores. * Test deletion propagation, including provider systems, downstream SaaS, indexes, caches, backups, exports, and generated artifacts. * Define retention for local artifacts and investigation evidence. * Review lifecycle controls after new features, connectors, models, or execution paths are enabled. ## AI data stores and derived copies AI systems create copies that are easy to miss in a SaaS retention review: | Store | Security questions | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Retrieval and knowledge sources | Does retrieval enforce the source user's current permissions? How quickly do permission changes and deletions propagate? | | Embeddings and vector stores | Can records be tied back to their source, tenant, classification, region, and deletion request? Are metadata filters authorization controls or only search filters? | | Fine-tuning and evaluation datasets | Who can add, label, export, reuse, and delete examples? Are production records allowed? | | Memory and session state | Is state personal, shared, channel-based, project-based, or agent-owned? Can poisoned or obsolete state be removed selectively? | | Caches and temporary files | What is cached, for how long, in which region, and under which key? Does Zero Data Retention exclude any cache or feature? | | Logs, traces, and exports | Are prompts, tool arguments, file paths, identifiers, and outputs copied into systems with broader access or longer retention? | | Backups and legal holds | When does deletion become effective, and what exceptions prevent or delay removal? | | Generated artifacts | Can files, links, sites, messages, code, or downstream records outlive the source conversation? | Do not accept “deleted” as a single control state. Record the deletion request, affected stores, completion time, exceptions, and verification evidence. Where a provider cannot verify deletion at the required granularity, restrict the data class or use an architecture with customer-controlled storage. Encryption scope also needs precision. Distinguish provider-managed encryption, customer-managed keys, connector-side encryption, local device encryption, and encryption applied through sensitivity labels. A customer-managed key for one service does not automatically cover every AI feature or downstream copy. ## Anthropic ### Overview The headline fact for regulated workloads: Managed Agents sessions persist state server-side and are not currently eligible for zero data retention or HIPAA BAA coverage, so a ZDR commitment on the API does not extend to a Managed Agents deployment. Check eligibility at design time, not after the pilot. For the API itself, Anthropic documents data retention controls, including zero data retention options. Claude Code documents local and cloud execution separately. Cowork remote sessions save sessions and files to the user's Claude account and process any local files they open on Anthropic's servers. The Claude for Excel, PowerPoint, Word, and Outlook add-ins have a sharper exception: inputs and outputs are deleted within 30 days, but the add-ins do not inherit custom organization retention settings and are not in Enterprise audit logs, the Compliance API, or data exports. Claude chat has its own Enterprise custom-retention controls. Claude Tag has a different rule: it retains channel memory and session transcripts and is unavailable to organizations with Zero Data Retention enabled. Slack conversations follow the Slack workspace's retention policy, while Anthropic says its copy is deleted within 30 days after the integration is disconnected or uninstalled. Put both systems on the retention map. ### Anthropic documentation * [API and data retention](https://platform.claude.com/docs/en/manage-claude/api-and-data-retention) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Claude Code data usage](https://code.claude.com/docs/en/data-usage) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Work across Microsoft 365 apps](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps) * [Configure custom data retention controls for Enterprise plans](https://support.claude.com/en/articles/10440198-configure-custom-data-retention-controls-for-enterprise-plans) * [What is Claude Tag?](https://support.claude.com/en/articles/15594475-what-is-claude-tag) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview For ChatGPT Enterprise, Edu, and Healthcare workspaces, chats and files saved to Library are retained according to the workspace's configured retention policy, which workspace admins control. Deleted chats are scheduled for permanent deletion from OpenAI systems within 30 days unless de-identified or retained for security or legal obligations. Two details catch teams out: for Enterprise users, files not saved to Library expire after 48 hours, and data deleted via the Compliance API is retained internally for no more than 30 days after the deletion request — with canvas events not yet supported by that API. On the API Platform, data-control behavior varies by endpoint and feature. For ChatGPT Work, data stored by ChatGPT follows the workspace retention policy, while connected applications retain and delete their own data under separate policies. Work can create conversation content, files, artifacts, and execution metadata; Codex can add repository metadata, command output, diffs, and logs. Verify the current product and Compliance API schemas before claiming that a workspace deletion covers every artifact or tool-side copy. ### OpenAI documentation * [Chat and File Retention Policies in ChatGPT](https://help.openai.com/en/articles/8983778-chat-and-file-retention-policies-in-chatgpt) * [Compliance APIs for Enterprise Customers](https://help.openai.com/en/articles/9261474-compliance-apis-for-enterprise-customers) * [Enterprise privacy at OpenAI](https://openai.com/enterprise-privacy/) * [Data controls in the OpenAI platform](https://developers.openai.com/api/docs/guides/your-data) * [Codex Governance](https://developers.openai.com/codex/enterprise/governance) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about retention and Zero Data Retention ### What is Zero Data Retention? Zero Data Retention is a provider mode or contract term under which eligible prompt and response data is not retained on the provider's systems after the request completes. It is typically an API-side control granted per agreement rather than a settings checkbox, and eligibility varies by endpoint and feature. Both Anthropic and OpenAI document ZDR options for their API platforms. ### Does ZDR cover every AI feature? No. Scope is defined per endpoint and feature, and some services sit explicitly outside it — Claude Managed Agents sessions, for example, persist state server-side and are not currently ZDR-eligible. Read the current vendor documentation and your amendment together before assuming coverage for a new feature. ### What data should be checked for retention? Check prompts, responses, files, images, tool calls and parameters, logs, telemetry, compliance exports, and local stores such as CLI history and downloaded files. Feature-level differences matter: in ChatGPT Enterprise, a file saved to Library follows workspace policy while one that is not expires after 48 hours. Remember that provider-side settings never govern the local copies. ### Is training opt-out the same as retention? No. Training controls govern whether the provider may use your content to improve models; retention controls govern how long the provider stores it. Data can be retained without being trained on — abuse-monitoring copies are a common example — and a ZDR amendment does not substitute for a training opt-out or the reverse. Review both, per surface, as described in 4.5. ### Who owns retention evidence? Compliance usually owns the evidence requirement and the retention schedule; security and platform teams own the technical data-flow map that proves the schedule is real. Give compliance exports themselves a lifecycle owner — they are copies of the most sensitive conversations and will outlive the source data if nobody deletes them. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports retention of deployer-controlled automatic logs. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports data protection, integrity, and third-party service review. | | G.4 Colorado AI Act and the US state patchwork | Conditional: for covered Colorado ADMT, this supports retention of required system, notice, and decision records. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Data Protection 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA PHI identification, minimum-necessary handling, retention, and disclosure controls. | *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 * [4. Data Protection & Residency](/handbook/4.-data-protection-and-residency) * [4.3 Data residency and regional inference](/handbook/4.-data-protection-and-residency/4.3-data-residency-and-regional-inference) * [4.5 Training opt-out and data usage](/handbook/4.-data-protection-and-residency/4.5-training-opt-out-and-data-usage) * [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform) * [G.2 EU AI Act obligations for deployers](/reference/governance-and-frameworks/g.2-eu-ai-act-obligations-for-deployers) # 4.5 Training opt-out and data usage How to confirm whether prompts, files, connector data, and feedback are used for model improvement across consumer, business, enterprise, and API plans. *Last reviewed: August 18, 2026* {% hint style="info" %} Training use is a governance question, not a checkbox to trust from memory. Confirm the account type, product surface, and contract terms. {% endhint %} ## Training opt-out and data usage: what security teams need to know AI providers handle data usage differently across consumer, team, enterprise, and API products. The same user may have several account paths with different defaults. A good review asks whether inputs, outputs, files, feedback, evals, and telemetry can be used to improve models or services. It also asks what happens when users sign in with personal accounts. ## Common training opt-out and data usage security failures * Enterprise users assume consumer settings apply to managed workspaces. * API data terms are read as ChatGPT terms, or the reverse. * Feedback and eval data are left out of the review. * Personal accounts become the training-use gap. * Contract language is not linked to technical enforcement. ## Training opt-out and data usage security controls checklist * Confirm training-use terms by product surface and account type. * Document default settings for managed tiers and consumer tiers separately. * Block or detect personal-account use for corporate data. * Review feedback, evals, files, and telemetry in addition to prompts. * Keep vendor docs and contract excerpts in the evidence pack. ## Anthropic ### Overview As of the last review date, Anthropic does not use inputs or outputs from its commercial products — Claude for Work, the Anthropic API, and Claude Gov — to train its models by default. The documented exception is explicit feedback: when a user submits a thumbs up or down, the related conversation may be used for training and is stored for up to five years, de-linked from user and customer IDs. Team and Enterprise Primary Owners and Owners can disable feedback submission org-wide via the Rate chats setting, which closes that path. Cowork follows the account and workspace context rather than creating a separate training tier. Its remote sessions can move among web, desktop, and mobile, while local capabilities still depend on the desktop. Confirm that every Cowork user is operating in the intended commercial workspace, especially when personal Pro or Max accounts are also available. Claude Tag is available through Team and Enterprise organizations, but its Slack conversations are stored separately from Claude chat history and its channel work is billed to the organization while direct messages use the individual's Claude account. Include both modes in the commercial-versus-consumer account check; the surface looks the same in Slack even though the identity and billing context differ. Consumer plans follow a different model. Data from Free, Pro, and Max plans — including Claude Code sessions under those plans — is used to improve Anthropic's models when the user allows it through the Model Improvement privacy setting, when conversations are flagged for safety review, or through explicit opt-in programs. Incognito chats are never used to improve Claude, and training data excludes raw content from connectors and MCP servers unless it is copied directly into the conversation. Check the actual setting for each user population rather than assuming which way it points. ### Anthropic documentation * [Is my data used for model training? (Commercial)](https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training) * [Is my data used for model training? (Consumer)](https://privacy.claude.com/en/articles/10023580-is-my-data-used-for-model-training) * [Claude Code data usage](https://code.claude.com/docs/en/data-usage) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [What is Claude Tag?](https://support.claude.com/en/articles/15594475-what-is-claude-tag) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview As of the last review date, OpenAI does not train its models on business data by default: ChatGPT Business, Enterprise, Edu, Teachers, and Healthcare workspaces and the API Platform (since March 1, 2023) require explicit opt-in before customer content is used for training. Consumer ChatGPT is the opposite case — OpenAI does use data from the consumer versions of its services as a training data source, which is why the tenant and account controls in 1.3 are training controls too. Two review notes. First, data-control behavior on the API Platform varies by endpoint and feature, so confirm terms per integration rather than per vendor. Second, personal workspaces registered under company email addresses may be subject to deletion or merge into the enterprise workspace — but until that capture happens, corporate data pasted into them sits under consumer terms. ChatGPT Work inherits the workspace's business data protections, but connected applications retain and process their own copies under separate terms. Desktop Work can also use local files and applications. Review the workspace, plugin or app, and downstream system together rather than treating the ChatGPT training setting as the only data-use decision. ### OpenAI documentation * [Enterprise privacy at OpenAI](https://openai.com/enterprise-privacy/) * [Data controls in the OpenAI platform](https://developers.openai.com/api/docs/guides/your-data) * [Managing members, seat types, roles and access in ChatGPT Enterprise](https://help.openai.com/en/articles/8266401-managing-members-seat-types-roles-and-access-in-chatgpt-enterprise) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about training opt-out and data usage ### Do AI providers train on enterprise data? By default, no — for the major providers' business and API offerings. OpenAI states it does not train on business data from ChatGPT Business, Enterprise, Edu, or Healthcare workspaces or the API Platform without explicit opt-in, and Anthropic does not train on commercial-product data by default, with explicit thumbs up/down feedback as the documented exception. Consumer tiers are different: consumer ChatGPT data is a training source, and consumer Claude data can be used when the user's Model Improvement setting allows it. These terms have changed before — confirm the current policy pages and your contract. ### Is training opt-out enough? No. A training commitment says nothing about retention, residency, access, logging, or DLP, and it does not stop users from moving corporate data into personal accounts where the training answer is different. Treat the no-training default as one row in the data-protection review, alongside the retention and residency rows in 4.3 and 4.4. ### What is the consumer-tier gap? Employees may use free or personal accounts where data can be used for training — consumer ChatGPT data is a training source, and consumer Claude data (including Claude Code on Free, Pro, and Max plans) can be used when the Model Improvement setting allows it. The subtle case is a personal workspace registered under a company email, which runs under consumer terms until the organization claims or merges it. Tenant restrictions (see 1.3) are the enforcement layer. ### Should feedback be reviewed? Yes — feedback is the standard exception to no-training defaults. On Anthropic commercial plans, a thumbs up or down submits the related conversation, which may be stored for up to five years, de-linked from user and customer IDs, and used for training; org owners can disable this via the Rate chats setting. Treat eval and support-ticket data the same way: separate handling rules that deserve their own review line. ### What evidence should be kept? Keep dated copies of the vendor policy pages, the contract or DPA language, workspace settings screenshots — including feedback and model-improvement settings — an account-scope inventory, and the personal-account controls in force. Training policies changed materially in 2025, so date-stamp everything and re-verify on a schedule rather than at renewal only. ## 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.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Data Protection guidance. | | G.7 Ownership and RACI for AI security | This control depends on the ownership and evidence responsibilities defined in the RACI. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA PHI identification, minimum-necessary handling, retention, and disclosure controls. | *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 * [4. Data Protection & Residency](/handbook/4.-data-protection-and-residency) * [4.4 Retention and Zero Data Retention](/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention) * [4.2 Data classification for AI prompts and outputs](/handbook/4.-data-protection-and-residency/4.2-data-classification-for-ai-prompts-and-outputs) * [G.2 EU AI Act obligations for deployers](/reference/governance-and-frameworks/g.2-eu-ai-act-obligations-for-deployers) * [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform) # 4.6 Cross-app data flow and live artifacts How to control AI data moving through apps, connectors, generated artifacts, shared links, publishing workflows, and downstream systems. *Last reviewed: August 18, 2026* {% hint style="info" %} A session can move data between tools faster than users notice. Shared artifacts and connector-backed outputs need the same review as apps. {% endhint %} ## What security teams need to know about cross-app data flow and live artifacts AI sessions can combine prompts, files, connector results, browser pages, local code, and generated artifacts. A user may think they are working in one tool while data moves through several systems. Live artifacts raise the review bar because a generated page or component can call connectors when a viewer opens it and approves access. That makes the artifact a small app, not a static file. ## Common cross-app data flow and live artifacts security failures * Sensitive data is generated into an artifact, so sharing the artifact shares the data regardless of connector controls. * A user approves an artifact's connector access on first interaction without reviewing what it reads or writes. * Data from one connector appears in another system without a transfer review. * External sharing is allowed for outputs built from sensitive inputs. * Users treat generated apps as documents. ## Cross-app data flow and live artifacts security controls checklist * Map source, retrieval, prompt, model, tool, artifact, and downstream destinations inside each approved workflow. * Record which identity and credential authorizes each transfer and action. * Review live artifacts and connector-backed outputs as applications, not static files. * Restrict external sharing and public publishing for outputs built from sensitive data. * Preserve classification, labels, ownership, retention, and deletion requirements when data changes format or application. * Log artifact creation, opens, sharing changes, connector calls, publishing, user identity, and data class where possible. * Require an owner, review date, expiry or archival rule, and takedown path for durable shared artifacts. * Test whether source permission changes and deletion requests reach generated and downstream copies. ## Trace the complete fan-out Start with the source record and follow every copy: retrieval result, prompt context, model response, tool argument, temporary file, generated document, published page, message, ticket, code change, analytics event, and compliance export. Mark the identity, application, region, retention rule, and evidence source at each hop. Classification must survive transformation. A summary, embedding, chart, screenshot, generated document, or code patch can remain sensitive even when it no longer resembles the source. Where labels do not propagate automatically, require the workflow or user to apply the destination control before sharing or publishing. Give every durable artifact a removal path. Incident response should be able to find and revoke public links, unshare files, retract messages where supported, disable connector-backed behavior, and identify copies that cannot be recalled. ## Anthropic ### Overview Claude artifacts are standalone content — documents, code, HTML pages, SVGs, React components — rendered in a dedicated window, and they require the Code execution and file creation capability. On paid plans an artifact can connect to external services through MCP connectors, but the credential model is per-viewer: users are prompted to approve access on first interaction, and each user must authenticate MCP servers independently, even for shared or published artifacts. An artifact does not carry its author's credentials to a new viewer; the residual risks are data generated into the artifact itself, sharing that outruns the data's classification, and viewers approving connector access without reviewing it. Organization admins can enable or disable artifact MCP access at the organization level. Connectors retrieve data and take actions according to each person's source-system permissions, but that does not stop content already baked into a shared artifact. Cowork adds two more paths: remote sessions can move between web, desktop, and mobile, and the Claude Office add-ins can pass context between open Excel, PowerPoint, Word, and Outlook files. That cross-app transfer can happen inside one session, so the target file needs its own classification and sharing review. Claude Tag creates another cross-app path from shared Slack context into connected repositories, dashboards, ticketing systems, and document stores. Channel work uses the agent's service accounts and posts results back to a shared thread; direct messages use the individual's connectors and attribution. Preserve that distinction in data-flow diagrams, especially when the same person can invoke both modes. ### Anthropic documentation * [What are artifacts and how do I use them?](https://support.claude.com/en/articles/9487310-what-are-artifacts-and-how-do-i-use-them) * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [Use Claude Cowork safely](https://support.claude.com/en/articles/13364135-use-claude-cowork-safely) * [Work across Microsoft 365 apps](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps) * [What is Claude Tag?](https://support.claude.com/en/articles/15594475-what-is-claude-tag) * [How Claude Tag agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview ChatGPT Work can combine files, workspace resources, plugins, apps, browser activity, and local desktop context to create documents, spreadsheets, presentations, reports, and Sites. Plugins package the workflow, while underlying apps still control the data and actions. ChatGPT for Excel or Google Sheets and ChatGPT for PowerPoint carry approved apps and skills into Office-native files, so a source-system permission can become a document write without leaving the host application. Sites are a publication path, not just a generated file. Enterprise public publishing is off by default and requires admin enablement, but every deployment URL is a production URL. One lifecycle gotcha also remains: disabling or uninstalling a plugin does not necessarily remove or disable every underlying app shared with other workflows. Inventory plugins, apps, connected accounts, generated files, and published Sites separately. ### OpenAI documentation * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [Apps in ChatGPT](https://help.openai.com/en/articles/11487775-apps-in-chatgpt) * [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) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [Creating and managing ChatGPT Sites](https://help.openai.com/en/articles/20001339) * [ChatGPT for Excel and Google Sheets](https://help.openai.com/en/articles/20001063) * [ChatGPT for PowerPoint](https://help.openai.com/en/articles/20001242) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about cross-app data flow and live artifacts ### What is cross-app data flow in AI? It is the movement of data between prompts, files, connectors, browser sessions, tools, Office documents, outputs, artifacts, and published Sites within a single AI workflow. A session that reads a CRM record, summarizes it, and writes the summary into a presentation has crossed three systems in one conversation. Trace the chain from source system to AI surface to target file or publication. ### Why are live artifacts risky? Because they behave like small applications: an artifact can render interactive content and, on paid Claude plans, request access to MCP connectors when a viewer interacts with it. The realistic risks are sensitive data generated into the artifact itself, sharing that outruns the data's classification, and viewers approving connector access without review. Note that each viewer authenticates connectors independently — a shared or published artifact does not carry the author's credentials. ### Should artifacts be externally shareable? Only after a short, concrete review: what data class went into the artifact, whether sensitive content is embedded in the output itself, whether it requests connector access, and who the audience is. If any sensitive input was used, treat the artifact as a document of that class and restrict sharing accordingly. Durable shared artifacts need an owner and a review date, like any published application. ### What should be logged for live artifacts? Where the platform exposes them, log artifact creation, sharing changes, opens, and connector approval events, together with user identity and the data class of the inputs. Expect gaps: some artifact activity only appears in the connected system's own audit logs, so include downstream SaaS logs in the evidence plan (see 6.6). ### How should teams review artifact risk? Treat connector-capable artifacts and Sites as lightweight applications: identify an owner, the data class of the inputs, the connector scopes requested, and the sharing audience. For Office agents, add the open source and target files and the cross-app setting. Re-review when an artifact or Site is republished, a plugin gains a new app, or its sharing scope widens. ## 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 data protection, integrity, and third-party service review. | | G.4 Colorado AI Act and the US state patchwork | Conditional: for covered Colorado ADMT, this supports the cross-system input and decision path behind an outcome. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Data Protection 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 traceable data flows and responsibilities across integrated systems. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA PHI identification, minimum-necessary handling, retention, and disclosure controls. | *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 * [4. Data Protection & Residency](/handbook/4.-data-protection-and-residency) * [2.1 Connectors and apps: the integration backbone](/handbook/2.-supply-chain-and-extensibility/2.1-connectors-and-apps-the-integration-backbone) * [3.5 Computer Use / desktop control risks](/handbook/3.-runtime-sandbox-and-autonomy/3.5-computer-use-desktop-control-risks) * [5.2 Data exfiltration via tools and connectors](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) # 4.7 Secrets and credential hygiene in prompts and tools How to keep secrets out of prompts, files, tool parameters, shell history, logs, telemetry, and model-visible context. *Last reviewed: August 18, 2026* {% hint style="info" %} Secrets should never be normal prompt material. Give agents safe credential paths, and block secrets from prompts, files, and telemetry. {% endhint %} ## What security teams need to know about secrets and credential hygiene in prompts and tools Secrets leak into AI systems through copy-paste, code snippets, logs, environment files, CI output, tool parameters, and screenshots. Once included, they may appear in transcripts, telemetry, outputs, and downstream tools. The control pattern is to deny direct reads where possible, inject secrets at runtime through approved systems, and redact before telemetry leaves the runtime. ## Common secrets and credential hygiene in prompts and tools security failures * Agents read `.env` or cloud credential files during debugging. * A user pastes an API key into a prompt to make an example work. * Tool parameters send secrets to logs or traces. * CI outputs environment variables into a transcript. * A generated fix commits a secret into source control. ## Secrets and credential hygiene in prompts and tools security controls checklist * Block known secret files from agent reads. * Use secret managers and short-lived credentials for tools. * Add secret scanning to repos, CI logs, prompts, and telemetry where feasible. * Redact tool parameters before SIEM ingestion. * Rotate credentials after suspected prompt or log exposure. ## Prefer mediated credentials A model rarely needs the raw secret. Let a broker or tool perform the approved operation using a short-lived credential bound to the agent, task, destination, and action. Return only the minimum result to the model. Block secrets from prompts, files, environment discovery, tool arguments, command output, traces, error messages, and generated artifacts. Scan both inputs and outputs, because agents can retrieve secrets from local files or tool results even when the user did not paste them. Test revocation during an active run and confirm the agent cannot continue using a cached token. ## Anthropic ### Overview Claude Code offers a credential path that avoids pasted secrets: `apiKeyHelper` can provide dynamic or rotating credentials, and the documented precedence chain — cloud provider credentials, bearer token, API key, `apiKeyHelper`, then OAuth and subscription credentials — tells you exactly which credential a session will use when several are present. Pair that with permission rules: deny rules take precedence over ask and allow rules, so a deny on `.env` files, key files, and credential directories holds even where broad read access is allowed, and managed settings can enforce those permission rules organization-wide. For hosted work, Managed Agents supports vault-based authentication for credentials, keeping secrets out of prompts and environment blocks entirely. Keep skill scripts, hooks, and MCP servers inside the same review, since each can read files or emit tool parameters that end up in telemetry. Cowork expands the secret boundary. Remote sessions can call connected tools with short-lived credentials in an Anthropic-managed sandbox, while local Cowork can reach desktop files, browser sessions, and applications. Its OpenTelemetry stream can include full prompts, tool parameters, and file paths. Deny sensitive locations, narrow connector scopes, and redact telemetry before it reaches shared storage. Claude Tag keeps provisioned credentials outside the thread sandbox. Agent Proxy retrieves a matching secret from a separate store and injects it at the network boundary, so the model and sandbox do not receive the stored key. That protection depends on narrow connection rules: constrain the host, path prefix, HTTP methods, workspace, and channel scope, and use a dedicated service account that can be revoked without affecting a person. ### Anthropic documentation * [Claude Code authentication](https://code.claude.com/docs/en/team) * [Configure permissions](https://code.claude.com/docs/en/permissions) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [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) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI's guidance starts with key handling: store API keys in environment variables or secret management services, and use separate projects to isolate staging from production with different rate and spend limits — separation that also limits how far one leaked key reaches. Workload identity federation removes the long-lived secret altogether: trusted workloads exchange external identity tokens for short-lived OpenAI access tokens, with service account mappings controlling which external identities may mint them. For agent runs, Codex sandbox policy bounds file, command, and network access, which is the mechanism for keeping credential files out of an agent's reach during local or cloud work. Desktop Work and Computer Use can also reach local files and applications under approved permissions, so review shell profiles, credential stores, browser sessions, and app tokens in the local threat model. OpenAI Work compliance records omit files, actions, and tool calls, which makes prevention and downstream logging more important. None of this protects a secret pasted into a ChatGPT prompt, so detection and rotation still matter on chat surfaces. ### OpenAI documentation * [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) * [Workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Computer Use](https://learn.chatgpt.com/docs/computer-use) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about secrets and credential hygiene in prompts and tools ### Can secrets be pasted into AI tools? No — treat a pasted secret as exposed. It can persist in conversation history, provider-side storage, telemetry, and any downstream tool the session touches. Use secret managers, runtime environment injection, or brokered credentials such as Claude Code's `apiKeyHelper` or OpenAI workload identity federation instead. ### Which files should agents be blocked from reading? Start with `.env` files, private keys, cloud credential files, SSH keys, token stores, password exports, and CI secret files. In Claude Code, express these as deny rules, which take precedence over ask and allow rules; in Codex, keep the sandbox policy narrow enough that credential paths sit outside the agent's reachable filesystem. Revisit the deny list whenever a new tool, hook, or skill gains file access. ### How do secrets leak through tools? Tool parameters are the quiet path: a secret read from a file can be passed as an argument, logged in a trace, echoed in command output, or committed by a generated fix. Screenshots and CI logs add further copies that outlive the session. Redact tool parameters before telemetry leaves the runtime, and scan generated code before it merges. ### What should happen after a secret is exposed? Revoke or rotate the credential first — assume any copy in a transcript or log is compromised. Then find the durable copies: conversation history, telemetry, SIEM events, generated files, and downstream systems the session wrote to. Finish by asking whether the exposure path — a missing deny rule, an over-broad sandbox — needs a control fix, not just a cleanup. ### Should telemetry include tool parameters? Only with redaction and a clear reason, because parameters routinely carry secrets, tokens, and customer data. Filter or hash sensitive fields before SIEM ingestion, and prefer counts and classification metadata over raw values. Where raw parameters are needed for investigations, restrict access and shorten retention accordingly. ## 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 data protection, integrity, and third-party service review. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Data Protection 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA PHI identification, minimum-necessary handling, retention, and disclosure controls. | *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 * [4. Data Protection & Residency](/handbook/4.-data-protection-and-residency) * [1.6 API keys and service accounts governance](/handbook/1.-identity-and-access/1.6-api-keys-and-service-accounts-governance) * [3.8 File and filesystem access controls](/handbook/3.-runtime-sandbox-and-autonomy/3.8-file-and-filesystem-access-controls) * [5.2 Data exfiltration via tools and connectors](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors) * [2.4 Analyzing skills for risk](/handbook/2.-supply-chain-and-extensibility/2.4-analyzing-skills-for-risk) # 5. Threats & Adversarial The attack patterns unique to AI systems — prompt injection, tool-based exfiltration, supply-chain compromise, tool poisoning, confused deputy, and AI red-team response. *Last reviewed: August 18, 2026* {% hint style="info" %} AI systems introduce attack patterns that have no equivalent in traditional security — prompt injection runs through every other risk in this handbook. Understanding how AI-specific attacks work is a prerequisite for building controls that actually hold. {% endhint %} ## Articles in this section 1. [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk) 2. [5.2 Data exfiltration via tools and connectors](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors) 3. [5.3 Supply chain attacks and notable CVEs](/handbook/5.-threats-and-adversarial/5.3-supply-chain-attacks-and-notable-cves) 4. [5.4 Agent-specific threats: tool poisoning and confused deputy](/handbook/5.-threats-and-adversarial/5.4-agent-specific-threats-tool-poisoning-and-confused-deputy) 5. [5.5 Red-teaming AI systems](/handbook/5.-threats-and-adversarial/5.5-red-teaming-ai-systems) 6. [5.6 Incident response for AI system](/handbook/5.-threats-and-adversarial/5.6-incident-response-for-ai-system) 7. [5.7 Threat modeling AI systems](/handbook/5.-threats-and-adversarial/5.7-threat-modeling-ai-systems) ## Frequently asked questions **What is prompt injection and why does it matter more than other AI risks?**\ Prompt injection is crafted input that causes a model to treat attacker-controlled content as instructions. Direct injection comes from the user's prompt. Indirect injection arrives through content the model reads, such as a webpage, document, email, codebase, or tool response. It can steer responses or tool use, but the impact depends on the data and tools available to the model, the privileges granted, and the approvals required. Treat external content as untrusted and constrain resulting actions with deterministic policy. **How do AI agents get used to exfiltrate data?**\ A common path starts with indirect injection, reaches data the agent can access, and then uses a permitted tool or external destination to disclose that data. The connector call may use a legitimate identity, so authentication alone does not stop the attack. Use least-privilege connector scopes, destination and egress controls, confirmation for consequential actions, content inspection, and audit logging. Do not allow untrusted content to drive privileged actions without an independent check. **What makes AI supply chain attacks different from traditional software supply chain attacks?**\ AI supply chain risk includes malicious packages, extensions, MCP servers, skills, hooks, and repository-controlled configuration. In vulnerable or permissive tools, opening, installing, or trusting a project can execute code or influence agent behavior. Not every client executes project content on open, so treat that as a product-specific risk rather than a universal behavior. Review trust prompts, allowlist extensions and MCP servers, scan and pin dependencies, and protect hook and CI configuration. **Which agent threats are easiest to miss?**\ Persistent memory poisoning, spoofed tool results, denial-of-wallet, SSRF or internal network pivoting, cross-workspace boundary failures, data poisoning, and replay or approval race conditions often sit between teams. Include them in the threat model, red-team catalog, detections, and incident runbook rather than assigning them to one control layer. ## Related handbook guidance * [AI Security Handbook](/) * [5.7 Threat modeling AI systems](/handbook/5.-threats-and-adversarial/5.7-threat-modeling-ai-systems) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) * [7.2 Pilot design and success metrics](/handbook/7.-rollout-and-operations/7.2-pilot-design-and-success-metrics) # 5.1 Prompt injection: the connective risk Direct and indirect prompt injection runs through every other AI security risk — how it works, where it comes from, and how to test for it. *Last reviewed: August 18, 2026* {% hint style="info" %} Prompt injection is the connective risk in agentic AI. Untrusted text can steer the model toward unsafe tool use even when the tool itself works as designed. {% endhint %} ## Prompt injection: what security teams need to know Prompt injection happens when instructions in user input, retrieved content, documents, web pages, tool results, or metadata compete with the user's real task. OWASP ranks it first in its Top 10 for LLM applications (LLM01). Direct injection comes from the user or attacker prompt. Indirect injection rides inside content the model reads. The core problem is that models process instructions and data in the same channel. Security controls should assume some untrusted content will reach the model. The risk is proven in production. CVE-2025-32711 (EchoLeak) was a zero-click prompt-injection chain in Microsoft 365 Copilot that enabled data exfiltration (CVSS 9.3); Microsoft patched it in 2025. It is the canonical real-world case of indirect injection reaching an enterprise assistant. ## Common prompt injection security failures * A web page tells the agent to ignore prior instructions and exfiltrate data. * A document contains hidden text that changes tool behavior. * An MCP tool result includes instructions for the next step. * A skill or prompt template carries unsafe directions. * Users trust an approval prompt shaped by injected context. ## Prompt injection security controls checklist * Separate trusted instructions from untrusted content where the platform allows it. * Limit tools available while processing untrusted content. * Treat MCP tool descriptions and tool results as untrusted unless the server is trusted, as the MCP specification advises. * Use egress controls so injected instructions cannot send data out. * Test workflows with indirect-injection cases before rollout. * Log the content source that preceded risky tool calls. ## Anthropic ### Overview Anthropic prompt-injection review should include Claude chat and Cowork, connectors, Desktop extensions, Claude Code, MCP servers, Agent Skills, Managed Agents, Office add-ins, and API tools. Tool descriptions, connector results, web content, files, skill instructions, multi-agent messages, and content in open Excel, PowerPoint, Word, or Outlook files are all potential instruction carriers. Anthropic provides several enforcement points once injection is assumed. Connectors act with the person's source-system permissions, and Team or Enterprise owners can enable connectors and restrict actions. Claude Code permission rules can allow, ask, or deny tool use, with deny rules taking precedence, and managed settings can restrict MCP servers, plugins, hooks, and permission rules organization-wide. Claude Code also applies command injection detection and fail-closed permission matching, so suspicious or unmatched commands require manual approval even if previously allowlisted. Anthropic's skill-review guidance treats adversarial instructions inside skills as an explicit review item. Claude Tag adds shared Slack messages, channel memory, watched channels, web-search results, and connected-system responses to the injection surface. A channel session acts with the agent's shared service accounts rather than the requester's identity, so an injected message can become a confused-deputy request for everyone in scope. Keep Access bundles narrow, restrict who can invoke Claude, and test indirect instructions posted by people or integrations that are allowed to write into the channel. ### Anthropic documentation * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [Skills for enterprise](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/enterprise) * [Reduce prompt leak](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-prompt-leak) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Code permissions](https://code.claude.com/docs/en/permissions) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Use Claude Cowork safely](https://support.claude.com/en/articles/13364135-use-claude-cowork-safely) * [Work across Microsoft 365 apps](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI prompt-injection review should include ChatGPT Work, apps and synced content, plugins, Sites, ChatGPT for Excel or Google Sheets, ChatGPT for PowerPoint, Workspace Agents, Codex browser or computer use, API tools, and Agents SDK workflows. Test both the content surface and the action surface, because injected text becomes dangerous when it can drive a permitted write, share, publication, or scheduled run. Lockdown Mode is OpenAI's purpose-built control for injection outcomes: it limits outbound web and external-service access to reduce prompt-injection data exfiltration risk. Managed workspace admins assign it through RBAC roles, and it does not affect Codex network access, so Codex egress needs separate handling. For apps, action control determines whether an app can read only, take actions, or use a custom set of actions. For Codex, sandbox policy affects file, command, and network access, and approval policies range from read-only to dangerous full access. ### OpenAI documentation * [Lockdown Mode](https://help.openai.com/en/articles/20001061) * [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) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Creating and managing ChatGPT Sites](https://help.openai.com/en/articles/20001339) * [ChatGPT for Excel and Google Sheets](https://help.openai.com/en/articles/20001063) * [ChatGPT for PowerPoint](https://help.openai.com/en/articles/20001242) ### Applicable Harmonic guides for OpenAI * [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) ## Frequently asked questions about prompt injection ### What is prompt injection? Prompt injection is an attack where instructions in prompts or content steer a model away from the user's intended task. OWASP lists it as LLM01, the top risk for LLM applications. It matters most in agentic systems, where a steered model can call tools with real permissions. ### What is indirect prompt injection? Indirect injection comes from content the model reads, such as web pages, documents, emails, tool results, or retrieved records. The user never types the attack; the agent picks it up while doing legitimate work. CVE-2025-32711 (EchoLeak) in Microsoft 365 Copilot showed the pattern working zero-click in a production assistant. ### Can prompt injection be solved by better prompting? No. Prompting and system-message hygiene reduce the hit rate but cannot guarantee separation of instructions from data. Durable controls sit outside the model: tool limits, egress policy, approvals, and monitoring. Plan for some injections to succeed and make the blast radius small. ### Which workflows are most exposed? Workflows that read untrusted content and can call tools, send messages, browse, or access sensitive data are most exposed. The risk compounds when one session combines all three ingredients: untrusted input, sensitive data access, and an outbound path. Unattended runs raise exposure further because no human sees the steering happen. ### How should teams test for injection? Use a repeatable test set with malicious pages, documents, tool outputs, and connector data, and run it against the workflow rather than the bare model. Include indirect cases where the payload sits in content the agent reads mid-task, and cases specific to your own connectors and data classes. Re-run the set after every major tool, model, or connector change. ## 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 resilience testing, vulnerability handling, and incident response. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Inference Security, Monitoring, 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA risk analysis, safeguard testing, and security-incident response. | *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 * [5. Threats & Adversarial](/handbook/5.-threats-and-adversarial) * [5.2 Data exfiltration via tools and connectors](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors) * [3.4 Internet access and browser automation](/handbook/3.-runtime-sandbox-and-autonomy/3.4-internet-access-and-browser-automation) * [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies) * [2.6 AI hooks: inference controls and lifecycle automation](/handbook/2.-supply-chain-and-extensibility/2.6-ai-hooks-inference-controls-and-lifecycle-automation) # 5.2 Data exfiltration via tools and connectors The injection-to-egress chain uses legitimate tools to move data out, making egress allowlists, connector scoping, and approvals key choke points. *Last reviewed: August 18, 2026* {% hint style="info" %} The common chain is simple: inject the agent, gather data, then send it out through a legitimate tool. Break the chain at tools, egress, or approvals. {% endhint %} ## Data exfiltration via tools and connectors: what security teams need to know Exfiltration in AI systems often uses approved features. A connector can read source data. A browser can open an external page. A messaging tool can send a summary. An artifact can carry data into a shareable output. In OWASP LLM Top 10 terms, this pairs sensitive information disclosure with excessive agency. This makes prevention a chain problem. You do not need every link to be perfect if one link blocks the path. ## Common data exfiltration via tools and connectors security failures * An injected page asks the agent to send retrieved data to a webhook. * Rendered markdown images or links auto-fetch attacker URLs with data packed into query strings. This was the channel used by CVE-2025-32711 (EchoLeak), the zero-click prompt-injection chain in Microsoft 365 Copilot that Microsoft patched in 2025. * A connector write posts sensitive output to a broad channel. * An artifact embeds sensitive data and is shared externally. * A tool call hides exfiltration inside a normal-looking support ticket. * Network policy allows the destination because it is a common SaaS domain. ## Data exfiltration via tools and connectors security controls checklist * Limit tools available after untrusted-content reads. * Require approval for external writes and broad shares. * Use egress allowlists for agent-controlled network access. * Classify outputs before sharing or connector writes. * Alert on unusual connector destinations, large outputs, and new external domains. ## Anthropic ### Overview Anthropic exfiltration review should trace data from Claude prompts, files, connector reads, Desktop extensions, Cowork remote sessions, Office add-ins, local MCP, Claude Code tool calls, API tools, and Managed Agent outputs to any external action. The Office cross-app setting is an outbound path in its own right because context can move from one open file or application into another. Two documented chokepoints matter most. Connectors act with the person's source-system permissions, and Team or Enterprise owners can enable connectors and restrict actions, which narrows what an injected session can write outward. Managed Agents cloud sandboxes run as isolated Linux containers with network access disabled by default, so unattended runs have no egress path unless the environment configuration enables one. In Claude Code, tools that make network requests require user approval by default, and network-fetching commands such as curl and wget are not auto-approved. Claude Tag channel sessions send outbound requests through Agent Proxy. Requests that match no credential rule, domain entry, or environment allowance are blocked, and stored secrets are injected at the proxy rather than exposed to the sandbox. Test all three allow layers, including the environment's Trusted defaults, and treat posting a result back into a broad Slack channel as an exfiltration path even when no external host was called. ### Anthropic documentation * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [Cloud sandbox reference](https://platform.claude.com/docs/en/managed-agents/cloud-sandboxes-reference) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Code permissions](https://code.claude.com/docs/en/permissions) * [Use Claude Cowork safely](https://support.claude.com/en/articles/13364135-use-claude-cowork-safely) * [Work across Microsoft 365 apps](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI exfiltration review should trace data through ChatGPT Work, plugins, apps, Sites, Office-native agents, Workspace Agents, Codex MCP/browser/computer use, API tools, and Agents SDK handoffs. Separate app action controls, Site publishing, Office file writes, desktop sandbox and approval policy, API egress, and connected SaaS permissions. Lockdown Mode is the control built for this exact threat: it limits outbound web and external-service access to reduce prompt-injection data exfiltration risk, and managed workspace admins assign it through RBAC roles. It does not affect Codex network access, so Codex egress must be governed separately through sandbox policy, which bounds file, command, and network access. For apps, action control determines whether an app can read only, take actions, or use a custom set of actions: the read/write split that decides whether an app can serve as an outbound path. ### OpenAI documentation * [Lockdown Mode](https://help.openai.com/en/articles/20001061) * [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) * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Creating and managing ChatGPT Sites](https://help.openai.com/en/articles/20001339) ### Applicable Harmonic guides for OpenAI * [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) ## Frequently asked questions about data exfiltration via tools and connectors ### How do AI agents exfiltrate data? They use normal tools such as connectors, browser actions, external requests, messages, files, or artifacts. Rendering channels count too: a markdown image or link that auto-fetches an attacker URL can carry data in its query string without any explicit send action. CVE-2025-32711 (EchoLeak) showed that class of chain working zero-click against Microsoft 365 Copilot. ### What is the best choke point? Network egress and external write actions are strong choke points because they sit near the end of the attack chain. An attacker can vary how they inject and what they collect, but the data still has to leave through a network path or a write action you can restrict. Egress allowlists and controls such as OpenAI's Lockdown Mode work at this layer. ### Are read-only tools part of exfiltration? Yes. Read-only tools collect the data that another tool later sends out, so they form the first link of the chain. Scoping read access to the task shrinks what a successful exfiltration can take. ### How can DLP help? DLP can detect sensitive content before prompt entry, tool use, output sharing, or external write actions. In agentic systems the most valuable placement is on the outbound side: connector writes, network requests, and shared artifacts. Pair detection with classification so alerts reflect data sensitivity rather than volume. ### What should trigger an alert? Unexpected external domains, new connector write targets, large sensitive outputs, and tool chains that follow untrusted-content reads should trigger review. Sequence matters as much as any single event: a sensitive read followed quickly by a new outbound destination is the signature to catch. ## 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 resilience testing, vulnerability handling, and incident response. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Inference Security, Monitoring, 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA risk analysis, safeguard testing, and security-incident response. | *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 * [5. Threats & Adversarial](/handbook/5.-threats-and-adversarial) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk) * [2.1 Connectors and apps: the integration backbone](/handbook/2.-supply-chain-and-extensibility/2.1-connectors-and-apps-the-integration-backbone) * [4.1 DLP for GenAI](/handbook/4.-data-protection-and-residency/4.1-dlp-for-genai) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) # 5.3 Supply chain attacks and notable CVEs AI supply-chain attack patterns and CVEs involving repositories, MCP configurations, packages, extensions, hooks, clients, and agent runtimes. *Last reviewed: August 18, 2026* {% hint style="info" %} AI coding tools turn repositories and configuration into active inputs. Opening a project can become part of the attack path. {% endhint %} ## Supply chain attacks and notable CVEs: what security teams need to know AI supply-chain attacks often use trusted developer workflows. A repository may include configuration, hooks, MCP settings, or prompt files that influence the agent after the user opens the project. The pattern is no longer hypothetical. The CVEs and incidents below cluster around one theme: the tooling around the agent (MCP clients, debug proxies, IDE integrations, and the package ecosystem) is the attack surface, not the model. ## Notable CVEs and incidents | Identifier | What happened | Fix / status | | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | | CVE-2025-6514 (mcp-remote) | OS command injection in the mcp-remote client via a malicious MCP server's OAuth authorization endpoint (CVSS 9.6). | Fixed in mcp-remote 0.1.16. | | CVE-2025-49596 (MCP Inspector) | Browser-triggered remote code execution through the MCP Inspector's unauthenticated local proxy (CVSS 9.4). | Fixed in MCP Inspector 0.14.1. | | CVE-2025-52882 (Claude Code IDE extensions) | Unauthorized WebSocket connections from arbitrary origins to Claude Code IDE extensions (CVSS 8.8). | Patched in June 2025. | | Nx "s1ngularity" npm compromise | Compromised Nx packages shipped malware that invoked installed AI CLIs with permission-bypass flags to harvest credentials, collecting roughly 2,349 secrets. | Disclosed August 2025. | The Nx incident deserves particular attention: the malware did not exploit the AI CLIs, it invoked them with their own permission-bypass flags. That makes restricting those flags on managed machines a supply-chain control, not just an autonomy preference. ## Common supply chain attacks and notable CVEs security failures * A repository carries a hook that executes during an agent session. * MCP configuration points to an attacker-controlled server. * A base URL override sends credentials to the wrong service. * Project prompt files instruct the agent to weaken controls. * A dependency update changes a tool used by the agent. ## Supply chain attacks and notable CVEs security controls checklist * Treat project configuration as executable trust. * Require workspace trust before project-level settings take effect. * Review hooks, MCP configs, plugin files, and prompt files in external repositories. * Block or review base URL overrides and credential helpers. * Track CVEs and vendor advisories for AI tooling, and re-review this class of dependency on a shorter cadence than the rest. ## Anthropic ### Overview Anthropic supply-chain review should include Claude Code settings, hooks, plugins, skills, MCP servers, repository instructions, Desktop extensions, Agent Skills, and Managed Agent definitions. A malicious repository, skill script, plugin, MCP server, or extension can alter what Claude reads, runs, or trusts. The package-like objects are concrete: Claude Code plugins can package skills, agents, hooks, MCP servers, and commands in one install; skills are SKILL.md files that can ship supporting scripts and pre-approved tools; and desktop extensions are MCP Bundles (.mcpb) containing a local MCP server and a manifest describing its capabilities. Managed settings can restrict MCP servers, plugins, hooks, permission rules, and sandbox behavior organization-wide. CVE-2025-52882, which allowed unauthorized WebSocket connections from arbitrary origins to Claude Code IDE extensions and was patched in June 2025, is the reminder that the IDE integration layer itself belongs in scope. ### Anthropic documentation * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Code hooks](https://code.claude.com/docs/en/hooks) * [Claude Code plugins](https://code.claude.com/docs/en/plugins) * [Extend Claude with skills](https://code.claude.com/docs/en/skills) * [Building Desktop Extensions with MCPB](https://github.com/modelcontextprotocol/mcpb) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) ## OpenAI ### Overview OpenAI supply-chain review should include ChatGPT apps and custom MCP apps, Apps SDK servers, Codex plugins and marketplaces, direct Codex MCP config, Agents SDK packages, exported Agent Builder workflows, and Codex SDK/MCP orchestration. Track source, version, manifest, tool list, credentials, and update path for each package-like object. Two Codex surfaces can trigger when a repository is opened: hooks are discovered from hooks.json files next to active config layers, including repo-local .codex directories, and skills are reusable instructions with optional helper scripts that can be bundled and distributed through plugins. Codex hooks are experimental and gated behind a config feature flag, and pre-tool interception currently covers only simple shell calls, so treat it as a guardrail, not a complete enforcement boundary. Plugins can be published through marketplace sources such as a repo marketplace, and uninstalling a plugin leaves bundled apps installed in ChatGPT until they are removed there. Where exported Agent Builder workflows appear in inventories, note that OpenAI documents Agent Builder as legacy, with shutdown scheduled for November 30, 2026. ### OpenAI documentation * [Codex hooks](https://developers.openai.com/codex/hooks) * [Codex skills](https://developers.openai.com/codex/skills) * [Plugins](https://learn.chatgpt.com/docs/plugins) * [Agent Builder](https://developers.openai.com/api/docs/guides/agent-builder) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about supply chain attacks and notable CVEs ### What is an AI supply-chain attack? It is an attack that changes the code, configuration, tool, prompt, package, or extension an AI workflow depends on. Instead of attacking the model, the attacker poisons something the agent will read or execute: a hook, an MCP server, a plugin, or a dependency. OWASP counts supply chain vulnerabilities among its Top 10 risks for LLM applications, and the 2025 incidents on this page all followed that pattern. ### Why are repositories risky for AI agents? They can contain instructions and configuration that influence tool access, hooks, MCP servers, and generated changes. Some of it activates when the project is opened: Claude Code project-scoped settings and Codex repo-local hooks and skills are read from the repository itself. Workspace trust and managed settings exist to gate exactly this. ### Which CVEs have hit MCP and AI coding tools? The most cited 2025 examples are CVE-2025-6514, an OS command injection in the mcp-remote client via a malicious MCP server's OAuth authorization endpoint (CVSS 9.6, fixed in 0.1.16); CVE-2025-49596, browser-triggered remote code execution through the MCP Inspector's unauthenticated local proxy (CVSS 9.4, fixed in 0.14.1); and CVE-2025-52882, unauthorized WebSocket connections from arbitrary origins to Claude Code IDE extensions (CVSS 8.8, patched June 2025). The August 2025 Nx "s1ngularity" npm compromise added the incident pattern: malware invoking installed AI CLIs with permission-bypass flags, harvesting roughly 2,349 secrets. ### What files should reviewers check? Check hooks, MCP configs, plugin manifests, skills, prompt files, dependency manifests, and credential helpers. In Claude Code that means settings files, hooks, plugins, and SKILL.md files; in Codex it means repo-local .codex directories, hooks.json, skills, and plugin marketplace sources. Base URL overrides and credential helpers deserve special attention because they redirect secrets rather than run code. ### How should teams reduce trigger-on-open risk? Use workspace trust, managed settings, deny rules, source review, and isolated environments for unknown repositories. Open unfamiliar projects in a sandbox or disposable environment before letting project-level settings take effect. On managed machines, enforce configuration centrally so a repository cannot quietly re-enable what policy disabled. ## 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 resilience testing, vulnerability handling, and incident response. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Inference Security, Monitoring, 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA risk analysis, safeguard testing, and security-incident response. | *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 * [5. Threats & Adversarial](/handbook/5.-threats-and-adversarial) * [2.4 Analyzing skills for risk](/handbook/2.-supply-chain-and-extensibility/2.4-analyzing-skills-for-risk) * [2.5 Plugins and marketplaces](/handbook/2.-supply-chain-and-extensibility/2.5-plugins-and-marketplaces) * [2.8 Signing and packaging](/handbook/2.-supply-chain-and-extensibility/2.8-signing-and-packaging) * [5.6 Incident response for AI system](/handbook/5.-threats-and-adversarial/5.6-incident-response-for-ai-system) # 5.4 Agent-specific threats: tool poisoning and confused deputy Threats unique to tool-using agents include poisoned tool descriptions, misleading instructions, overbroad credentials, and confused-deputy privilege abuse. *Last reviewed: August 18, 2026* {% hint style="info" %} Agents can be tricked through the tools they trust. Review tool metadata, delegated permissions, and cross-agent messages as part of the threat model. {% endhint %} ## What security teams need to know about agent-specific threats: tool poisoning and confused deputy Tool-using agents have threats that ordinary chatbots do not. A tool description can mislead the agent. A connector can give the agent more access than the task needs. Another agent can pass untrusted instructions as if they were verified findings. A confused deputy appears when the agent uses its legitimate authority for someone else's goal. That is why tool scope and task context need to line up. In OWASP LLM Top 10 terms, these are the insecure plugin design and excessive agency risks. MCP's security guidance documents the recurring attack patterns by name. Confused deputy: an MCP proxy server using a static client ID with a third-party authorization server can let an attacker replay a consent cookie and obtain authorization codes. Token passthrough: a server accepts tokens that were not issued for it and forwards them downstream, defeating audience restrictions. Session hijacking: a predictable or exposed session ID lets an attacker inject events or resume someone else's session. All three are protocol-level shapes of the same problem: borrowed authority. ## Common agent-specific threats: tool poisoning and confused deputy security failures * A malicious tool description steers the agent to call it for unrelated tasks. * A tool description changes after approval (a rug pull), so the tool reviewers vetted is not the tool that runs. * A low-privilege user prompts an agent that has high-privilege connector access. * One agent passes hidden instructions to another agent. * A tool result tells the agent to ignore policy. * A broad service account lets the agent act outside the user's authority. ## Agent-specific threats: tool poisoning and confused deputy security controls checklist * Treat tool descriptions, schemas, results, retrieved content, memory, and inter-agent messages as untrusted inputs. * Pin or hash approved tool definitions so post-approval changes are detected. * Validate tool results against expected source, schema, identity, freshness, and authorization context. * Match connector and service-account scope to the task owner and preserve the initiating user. * Never accept or forward tokens that were not issued for the intended server and audience. * Use per-agent identities and task-specific permissions. * Prevent one agent or tool result from changing policy, identity, logging, budget, or tool access. * Restrict internal network, metadata-service, local-binding, callback, and redirect destinations. * Separate personal, shared, channel, tenant, and agent memory; review writes to persistent memory. * Require idempotency and replay protection for consequential actions. * Test poisoned tools, spoofed results, confused-deputy, cross-agent, memory-poisoning, SSRF, and approval-race cases. ## Threats that share the tool boundary **Tool-result spoofing** occurs when a compromised tool, connector, page, agent, or upstream service returns plausible but false content. Validate provenance and authorization context before using a result for a consequential action. **Memory poisoning** turns one malicious interaction into a persistent instruction or false fact. Separate memory by user, channel, project, tenant, and agent. Require review or policy for high-impact memory writes and support targeted removal. **SSRF and network pivoting** occur when an agent-controlled URL, callback, browser action, or tool request reaches metadata services, loopback listeners, private networks, management sockets, or unintended internal APIs. Apply destination policy after redirects and DNS resolution. **Replay and race conditions** occur when an approval, webhook, queue event, or tool request is reused or changes between review and execution. Bind approval to the exact action, arguments, identity, target, and expiry. ## Anthropic ### Overview Anthropic tool-poisoning review should cover MCP tool metadata, connector descriptions, skill instructions, Managed Agent toolsets, API tool schemas, and Claude Code plugin/hook behavior. A confused-deputy path appears when Claude uses legitimate user or agent authority for an injected or cross-agent goal. The useful specifics: connectors act with the person's source-system permissions, and Team or Enterprise owners can restrict connector actions, which narrows what a poisoned tool can trigger. Anthropic's skill-review guidance explicitly covers scripts, adversarial instructions, MCP references, and tool invocations. In Managed Agents multi-agent sessions, referenced agents are pinned to versions resolved when the coordinator is created or updated, the same pinning idea that defends against post-approval swaps. Claude Code MCP configuration can be scoped and controlled through settings rather than left to individual repositories. Cowork and Claude's Office add-ins add cross-surface deputy risks. Remote Cowork can combine connected services inside an Anthropic-managed sandbox, while local Cowork can use browser and application authority on the desktop. The Office add-ins can work across Excel, PowerPoint, Word, and Outlook when cross-app access is enabled. Test whether untrusted content in one file or message can cause an action in another application under the user's authority. Claude Tag creates a direct shared-authority deputy. In a channel, everyone in scope can ask the same organization-provisioned service accounts to act, regardless of who requested the task. Test whether a low-trust channel member, Slack integration, watched channel, or poisoned repository can steer Claude into using a higher-value connection, and verify that Access-bundle inheritance does not silently widen the channel's authority. ### Anthropic documentation * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [Skills for enterprise](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/enterprise) * [Multi-agent sessions](https://platform.claude.com/docs/en/managed-agents/multi-agent) * [Claude Code MCP](https://code.claude.com/docs/en/mcp) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Work across Microsoft 365 apps with Claude](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps) * [How Claude Tag agent identity works](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) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI tool-poisoning review should cover ChatGPT app metadata, custom MCP tools, Apps SDK descriptors, Workspace Agents, Codex plugins/MCP servers, API tool definitions, and Agents SDK handoffs. Review what the tool says it does, what it can actually do, and whose authority it uses. Authority is the specific thing to check. App access and action control determine who can use a connected app and whether it can read only, take actions, or use a custom set of actions, so a poisoned description cannot expand an app past its assigned actions. Workspace Agent access tokens are distinct from platform and Compliance API credentials, and published workspace agents with agent-owned connections can expose data through the builder's credentials rather than end-user authentication, a confused-deputy shape worth modeling explicitly. Codex reaches MCP servers through its own configuration, which should be governed rather than ad hoc. ChatGPT Work and plugins widen the chain. A plugin may bundle skills, apps, app templates, and MCP servers, while the underlying app still acts with workspace and source-system permissions. Test whether instructions from a file, website, plugin skill, or connected source can redirect a Work task into a write, share, publication, scheduled run, or Computer Use action that the user did not intend. ### OpenAI documentation * [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) * [Workspace Agents](https://developers.openai.com/workspace-agents) * [Codex MCP](https://developers.openai.com/codex/mcp) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about agent-specific threats: tool poisoning and confused deputy ### What is tool poisoning? Tool poisoning is manipulation of tool metadata, descriptions, or outputs to steer an agent into unsafe tool use. A poisoned description can claim capabilities it lacks, tell the agent to call it for unrelated tasks, or smuggle instructions into results. A documented variant, the rug pull, swaps the description after approval so the reviewed tool and the running tool no longer match; pinning or hashing approved definitions is the control. ### What is a confused deputy in AI agents? It is an agent with legitimate access being tricked into using that access for an attacker's goal. MCP security guidance documents a concrete instance: a proxy server using a static client ID with a third-party authorization server can let an attacker replay a consent cookie and obtain authorization codes. The mitigation is obtaining user consent for each dynamically registered client. ### Why do multi-agent systems add risk? Agents may pass summaries or instructions to each other without preserving source trust and data boundaries. An instruction that arrives as another agent's finding can carry the same payload as an injected web page, with more implied credibility. Version pinning for referenced agents and restrictions on cross-agent policy changes limit the damage. ### How do service accounts affect confused deputy risk? Broad service accounts increase risk because the agent can act beyond the initiating user's real authority. The MCP token passthrough anti-pattern is the protocol-level version: a server that accepts tokens not issued for it lets callers borrow authority it was never granted. Scope identities per agent and per task, and reject tokens whose audience is not your server. ### How can teams test these threats? Create tests with poisoned tool descriptions, malicious tool results, low-privilege prompts, and cross-agent instruction passing. Add the documented MCP patterns: consent-cookie replay against OAuth proxies, tokens presented that were not issued for the server, session-ID guessing, and a post-approval description swap. Each test should record whether the deputy noticed, refused, or complied. ## 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 resilience testing, vulnerability handling, and incident response. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Inference Security, Monitoring, 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.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 * [5. Threats & Adversarial](/handbook/5.-threats-and-adversarial) * [2.2 MCP servers: securing the protocol](/handbook/2.-supply-chain-and-extensibility/2.2-mcp-servers-securing-the-protocol) * [1.5 Agent and non-human identity](/handbook/1.-identity-and-access/1.5-agent-and-non-human-identity) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk) * [5.7 Threat modeling AI systems](/handbook/5.-threats-and-adversarial/5.7-threat-modeling-ai-systems) # 5.5 Red-teaming AI systems A repeatable program to probe injection, exfiltration, destructive actions, permission abuse, tool misuse, and unsafe agent autonomy across your AI deployment. *Last reviewed: August 18, 2026* {% hint style="info" %} Red-team AI workflows by attacking the whole system: prompts, tools, data, identity, network, approvals, and logs. {% endhint %} ## What security teams need to know about red-teaming AI systems AI red teaming should move beyond jailbreak prompts. The test target is the workflow: what content the agent reads, which tools it can call, what data it can reach, and where outputs can go. Anchor the test catalog to public frameworks rather than inventing categories: MITRE ATLAS enumerates adversary techniques against AI-enabled systems, and the OWASP LLM Top 10 names the risk categories (prompt injection, sensitive information disclosure, supply chain, insecure plugin design, excessive agency) that findings should map to. A good program produces findings that map to controls. Each finding should say which chain worked, which control failed, and which owner can fix it. ## Common red-teaming AI systems security failures * Tests focus on model refusal instead of tool abuse. * The red team lacks realistic connectors or data classes. * Findings do not map to owners or controls. * The same test set is reused after the product changes. * No one retests after a mitigation. ## Red-teaming AI systems security controls checklist * Maintain a scenario catalog indexed to the system's threat model, OWASP LLM Top 10, MITRE ATLAS, and known product boundaries. * Test direct and indirect injection through documents, pages, email, code, retrieval, memory, tool results, and inter-agent messages. * Test exfiltration through connectors, URLs, browser actions, generated files, messages, publishing, and covert or encoded output. * Test poisoned tools, skills, plugins, hooks, templates, packages, models, retrieval data, and updates. * Test confused-deputy, cross-tenant, cross-workspace, shared-service-account, and permission-inheritance paths. * Test SSRF, internal network pivoting, metadata access, redirect handling, and local service access. * Test denial-of-wallet, recursion, runaway tool use, concurrency, storage, and timeout limits. * Test replay, duplicate action, stale approval, stop failure, and recovery behavior. * Run tests before pilot expansion and after material model, tool, policy, data, or architecture changes. * Use synthetic sensitive data and traceable markers. * Map each finding to an owner, blocking decision, remediation, evidence, and retest date. ## Minimum scenario catalog Cover at least one scenario for each of these paths: 1. untrusted content changes the agent's goal; 2. the agent retrieves data the requester should not receive; 3. a legitimate credential is used for the wrong principal or task; 4. a tool description or result changes after approval; 5. persistent memory or retrieval data affects a later run; 6. an agent reaches an internal or prohibited network destination; 7. a retry, replay, or race duplicates a consequential action; 8. work exceeds token, spend, duration, concurrency, or storage limits; 9. the user stops the task but downstream work continues; 10. required evidence is absent, delayed, redacted incorrectly, or attributed to the wrong identity. Record the expected control and evidence before executing the test. A red-team finding is incomplete if the team cannot state which production gate it blocks. ## Anthropic ### Overview Anthropic red-team plans should test Claude chat and remote Cowork, connectors, Desktop extensions, computer use, Office add-ins, Claude Code, API tools, Agent Skills, Managed Agents, and multi-agent messages. Include prompt leakage, cross-app context transfer, indirect injection, malicious tool output, unsafe file edits, connector abuse, and unattended-run drift. Anthropic's own guidance supplies test targets. The prompt-leak guardrail guidance treats prompt, tool, and system instruction exposure as adversarial-review material, so include leak cases alongside injection cases. The skill-review guidance calls out scripts, adversarial instructions, MCP references, network access, and tool invocations: a ready-made checklist for poisoned-skill test cases. Managed Agents sessions persist state server-side and run unattended, so give long-running sessions their own scenarios rather than reusing interactive-chat cases. For Claude Tag, test both identity modes. In channels, probe shared Access bundles, channel memory, watched channels, scheduled routines, allowed domains, and service-account attribution. In direct messages, test the user's personal connectors and attribution. Include a case where an attacker plants instructions before the scheduled routine runs and a case where a broad channel member tries to use a credential intended for a narrower team. ### Anthropic documentation * [Reduce prompt leak](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-prompt-leak) * [Skills for enterprise](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/enterprise) * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Use Claude Cowork safely](https://support.claude.com/en/articles/13364135-use-claude-cowork-safely) * [Work across Microsoft 365 apps](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps) * [How Claude Tag agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) * [Set up Claude Tag routines](https://claude.com/docs/claude-tag/users/proactivity) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI red-team plans should test Chat, Work, and Codex in the combined desktop app; Work on web and mobile; plugins and apps; Sites; Office-native agents; Workspace Agents; hosted agent mode; local browser and computer use; API tools; and Agents SDK workflows. Product-specific controls such as Work RBAC, Site publishing, app actions, and Codex approval profiles define the boundaries the red team should try to cross. OpenAI publishes two distinct resources that are easy to conflate. The red-teaming guide covers testing itself: prompts, tools, model behavior, and system-level safeguards. The safety-checks guidance is about gates: checks that can block deployment or expansion until they pass. Use the first to generate findings and the second to decide what a finding blocks, and keep the two feeding each other. ### OpenAI documentation * [Red teaming](https://developers.openai.com/api/docs/guides/red-teaming) * [Safety checks](https://developers.openai.com/api/docs/guides/safety-checks) * [Safety best practices](https://developers.openai.com/api/docs/guides/safety-best-practices) * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Creating and managing ChatGPT Sites](https://help.openai.com/en/articles/20001339) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about red-teaming AI systems ### What is AI red teaming? It is structured testing of AI workflows to find ways prompts, tools, data, and controls can fail. Unlike model-only jailbreak testing, it attacks the whole system: what the agent reads, what it can call, what it can reach, and where outputs go. The output is a set of findings mapped to controls and owners, not a list of clever prompts. ### What should AI red teams test? Test prompt injection, tool abuse, exfiltration, excessive agency, data leakage, and audit gaps. Index the catalog to MITRE ATLAS techniques and OWASP LLM Top 10 categories so coverage is checkable rather than anecdotal. Include the unglamorous cases, such as logging gaps and approval fatigue, alongside the flashy ones. ### How often should AI red-team tests run? Quarterly is a recommended starting point for high-risk workflows, adjusted to release tempo and risk appetite. Also test before major rollouts and after significant vendor or product changes, since a new tool, connector, or model can invalidate earlier results. Retesting after each mitigation is part of the cadence, not an extra. ### Should tests use real sensitive data? Use synthetic data that looks realistic. Real secrets or regulated records can leak through test logs, model context, or findings documents, turning the exercise into an incident. Seed synthetic records with markers so any later appearance is traceable to the test. ### What makes a good finding? A good finding includes the chain that worked, impact, evidence, the control that failed, an owner, the fix, and a retest date. Findings phrased as model behavior ("the model complied") age poorly; findings phrased as control gaps ("the egress allowlist did not cover this destination") get fixed. ## 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 resilience testing, vulnerability handling, and incident response. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Inference Security, Monitoring, and GRC guidance. | | 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 verification, validation, and evaluation evidence. | *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 * [5. Threats & Adversarial](/handbook/5.-threats-and-adversarial) * [5.7 Threat modeling AI systems](/handbook/5.-threats-and-adversarial/5.7-threat-modeling-ai-systems) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk) * [5.6 Incident response for AI system](/handbook/5.-threats-and-adversarial/5.6-incident-response-for-ai-system) * [7.2 Pilot design and success metrics](/handbook/7.-rollout-and-operations/7.2-pilot-design-and-success-metrics) # 5.6 Incident response for AI system An AI incident response runbook covering tokens, API keys, MCP grants, apps, connectors, automations, browser permissions, desktop access, and hooks. *Last reviewed: August 18, 2026* {% hint style="info" %} AI incidents need familiar IR discipline plus AI-specific containment: revoke tokens, disable tools, kill tasks, preserve prompts, and review outputs. {% endhint %} ## What security teams need to know about incident response for AI system AI incident response starts with the same fundamentals: scope, contain, preserve evidence, eradicate, recover, and communicate. The difference is the surface area. An AI incident may involve prompts, tool calls, connectors, MCP servers, browser actions, scheduled tasks, artifacts, API keys, and model outputs. The runbook should name each containment lever before the incident. ## Common incident response for AI system security failures * IR teams cannot revoke connector grants quickly. * Logs expire before the investigation begins. * Artifacts or scheduled tasks keep running after account containment. * The team rotates API keys but misses workload identity mappings. * The evidence plan assumes one audit feed covers every authentication path, and the incident used the path it does not cover. * Communications ignore customers or employees whose data appeared in outputs. ## Incident response for AI system security controls checklist * Create containment steps by surface: account, agent identity, connector, MCP server, plugin, hook, scheduled task, memory, knowledge source, artifact, API key, runtime, queue, and endpoint. * Preserve prompts, outputs, tool definitions and results, approvals, files, memory, retrieval sources, versions, spend, and telemetry before cleanup. * Stop active and queued work, then verify downstream actions have stopped. * Revoke or rotate credentials linked to the incident chain and invalidate cached sessions. * Block malicious destinations, tools, skills, packages, retrieval sources, and persistent memory. * Quarantine generated files, code, messages, sites, and other published artifacts. * Preserve a known-good version and define rollback or rebuild criteria. * Notify the provider when the incident involves platform behavior, a vulnerability, or data the provider may hold. * Test legal, privacy, customer, regulator, and law-enforcement notification decision paths. * Run a post-incident control review and add the scenario to red-team and detection coverage. ## Containment order 1. **Stop expansion:** pause tasks, schedules, queues, remote dispatch, publishing, and new sessions. 2. **Cut authority:** revoke agent and user sessions, OAuth grants, API keys, service accounts, and brokered credentials. 3. **Block the path:** disable the affected tool, connector, MCP server, skill, plugin, hook, memory, knowledge source, domain, or model route. 4. **Preserve evidence:** snapshot configuration and versions, export available records, and secure target-system and endpoint logs. 5. **Find outputs:** identify files, code, messages, tickets, transactions, sites, and shared links created by the incident. 6. **Recover deliberately:** restore a known-good configuration, rotate credentials, remove poisoned state, and validate controls before resuming. A user-visible stop button is not proof of containment. Verify that hosted tasks, child agents, browser actions, queued jobs, webhooks, and downstream systems have also stopped. ## Anthropic ### Overview Anthropic AI incident response should include disabling connectors, pausing Cowork and scheduled tasks, revoking OAuth grants or API keys, blocking desktop extensions or MCP servers, disabling Claude Code plugins, hooks, and skills, stopping Managed Agent runs, preserving prompts and tool results, and exporting available telemetry. Know the evidence and containment levers before the incident. Cowork is not currently captured in Anthropic audit logs, the Compliance API, or data exports; Team and Enterprise organizations need Cowork OpenTelemetry configured in advance. Claude Office add-ins are also outside the Compliance API and data exports, with custom Office-agent OpenTelemetry as the enterprise evidence path. Managed Agents keep server-side event history, and managed settings can restrict MCP servers, plugins, hooks, and permission rules organization-wide. For Claude Tag, containment can include removing the app from a channel, disabling DMs, narrowing member access, removing an Access bundle or repository grant, revoking the dedicated service account, and pausing routines. Preserve the Slack thread, channel memory, Audit view, optional Agent Proxy network-event export, and target-system logs. The Audit view does not contain a per-action record of every request and requester, so do not wait until an incident to test correlation. ### Anthropic documentation * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Code authentication](https://code.claude.com/docs/en/team) * [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](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) * [Review what Claude Tag has done](https://claude.com/docs/claude-tag/admins/audit) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI AI incident response should include revoking Work access where needed, pausing scheduled tasks and Workspace Agents, disabling affected plugins or apps, unpublishing Sites, revoking source-system grants, tightening desktop Work or Codex permission profiles, rotating API keys or workload identity mappings, preserving traces, and pulling governance or compliance exports. The evidence traps are documented. OpenAI says the Compliance API covers user messages and responses across Chat, Work, and Codex, but the Compliance Logs Platform does not capture files, actions, or tool calls. Those details need desktop, connector, target-system, repository, or API evidence. API-key-authenticated Codex usage still follows API organization settings rather than ChatGPT compliance exports. ### OpenAI documentation * [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) * [Compliance APIs for Enterprise Customers](https://help.openai.com/en/articles/9261474-compliance-apis-for-enterprise-customers) * [Codex Governance](https://developers.openai.com/codex/enterprise/governance) * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) * [Workload identity federation](https://developers.openai.com/api/docs/guides/workload-identity-federation) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Plugins in ChatGPT and Codex](https://help.openai.com/en/articles/20001256) * [Creating and managing ChatGPT Sites](https://help.openai.com/en/articles/20001339) ### Applicable Harmonic guides for OpenAI * [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) ## Frequently asked questions about incident response for AI system ### What is an AI security incident? It is an event where AI tools, prompts, agents, data, credentials, or outputs create unauthorized access, disclosure, action, or loss of control. That includes chains no human triggered directly, such as an injected agent posting data outward through an approved connector. Treat model outputs that expose someone else's data as incidents too, not just account compromises. ### What should be contained first? Contain active access paths: accounts, API keys, connectors, MCP servers, plugins, hooks, scheduled tasks, and shared artifacts. Automations deserve early attention because they keep running after a user account is contained. Revoke OAuth grants at the source system as well as inside the AI platform. ### What evidence should be preserved? Preserve prompts, outputs, tool calls, approvals, files, connector logs, endpoint logs, and audit exports. Pull compliance exports early, since retention windows may be shorter than the investigation. Record which surfaces have no platform-side evidence so gaps are documented rather than discovered later. ### How are AI incidents different from SaaS incidents? AI incidents often involve generated content and tool chains alongside user clicks or API calls. The actor may be an agent following injected instructions under a legitimate identity, which breaks the assumption that authenticated activity is intended activity. Scoping therefore includes what the model read, not just what the account did. ### What should happen after recovery? Close the loop on the controls that failed: update permission rules, connector scopes, and approval policies to block the chain that worked, and add the incident's technique to the red-team test set so the fix gets retested. Fill any evidence gaps the investigation exposed; an audit feed that did not cover the surface involved is a finding in itself. Then brief affected users on workflow changes, and record what the vendor was told and when. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports monitoring, serious-incident escalation, evidence preservation, and reporting. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports resilience testing, vulnerability handling, and incident response. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Inference Security, Monitoring, 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 incident learning, corrective action, and improvement. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA risk analysis, safeguard testing, and security-incident response. | *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 * [5. Threats & Adversarial](/handbook/5.-threats-and-adversarial) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) * [6.5 Routing AI telemetry to your SIEM](/handbook/6.-observability-audit-and-evidence/6.5-routing-ai-telemetry-to-your-siem) * [5.7 Threat modeling AI systems](/handbook/5.-threats-and-adversarial/5.7-threat-modeling-ai-systems) * [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security) # 5.7 Threat modeling AI systems A lightweight method to threat-model an AI workflow before enabling it, covering surface enumeration, trust boundaries, data flows, tools, and failure modes. *Last reviewed: August 18, 2026* {% hint style="info" %} An AI threat model is a map of an AI workflow that identifies data flows, trust boundaries, tools, identities, and abuse cases. Build it before pilot approval, then keep asking what the agent can read, decide, and do. {% endhint %} ## What security teams need to know about threat modeling AI systems Threat modeling an AI system should be lightweight enough to use before pilot approval. The output is a data-flow diagram, a control list, and a few abuse cases that matter. You do not need a new methodology. Use STRIDE to enumerate threats at each trust boundary, MITRE ATLAS to enumerate adversary techniques against AI-enabled systems, and the OWASP LLM Top 10 to seed abuse cases such as prompt injection and excessive agency. If your organization uses the NIST AI Risk Management Framework, the resulting risks and owners feed its GOVERN and MANAGE activities. The model should include human users, agents, tools, connectors, model endpoints, memory, retrieval, files, logs, and external destinations. ## Common threat modeling AI systems security failures * The diagram stops at the model API and ignores tools. * Prompt injection is listed as a risk but not tied to a data flow. * The threat model excludes logs, evals, and artifacts. * Agent identity is missing from the diagram. * Controls are listed without owners or evidence. ## Threat modeling AI systems security controls checklist * Map users, agents, models, tools, memory, retrieval stores, files, browsers, endpoints, queues, networks, logs, and outputs. * Mark identity, tenant, workspace, project, device, runtime, region, and downstream trust boundaries. * List what every principal can read, write, execute, publish, send, spend, and administer. * Model local, hosted, remote, scheduled, and fallback execution separately. * Write abuse cases for injection, exfiltration, excessive agency, confused deputy, tool-result spoofing, memory and data poisoning, SSRF, cross-tenant access, replay, and denial-of-wallet. * Record assumptions about provider controls and unsupported evidence. * Map each threat to prevention, detection, containment, recovery, owner, and test evidence. * Revisit the model after changes to models, tools, identity, data, memory, connectors, runtime, autonomy, or publishing. ## Model state, cost, and evidence as assets Traditional diagrams often stop at the model endpoint. Extend the diagram to persistent memory, embeddings and vector stores, evaluation and fine-tuning data, caches, traces, compliance exports, generated artifacts, queues, browser sessions, and connected-system records. Treat budget and evidence as security assets. An attacker may aim to exhaust spend or destroy attribution rather than steal data. Mark where token, rate, duration, concurrency, storage, and third-party costs are enforced, and where logs can be disabled, sampled, delayed, or attributed to a shared identity. For each consequential action, trace the chain from initiator to agent identity, model, tool, credential, target, approval, result, and evidence. Any missing link is a design gap that should be accepted, compensated for, or blocked before production. ## Anthropic ### Overview Anthropic threat models should map Claude web, Desktop, Mobile, Cowork remote and local execution, Claude Tag, Office add-ins, Code, Console/API, connectors, MCP, Agent Skills, and Managed Agents. Draw the trust boundary around tool execution, source-system identity, prompt files, skill scripts, desktop access, Slack channels and memory, cross-app transfers, and external actions. Draw two boundaries accurately. Managed Agents sessions persist state server-side and are not currently eligible for zero data retention or HIPAA BAA coverage, and the product is in beta. A Managed Agents deployment therefore places a stateful, Anthropic-hosted component in the diagram, with data-class limits regulated workflows must respect. Managed Agents can run in Anthropic-managed cloud sandboxes, isolated Linux containers with network access disabled by default, or in self-hosted sandboxes, which moves the execution boundary. Connectors act with the person's source-system permissions, so the source system's boundary, not Claude's, defines what a connector can reach. Draw Claude Tag channel work and direct messages as separate paths. Channel work crosses Slack, an Anthropic-hosted per-thread sandbox, Agent Proxy, a credential store, and service accounts in connected systems. Direct messages run under the user's Claude account and personal connectors. Those paths have different authority and attribution even though both begin with `@Claude`. ### Anthropic documentation * [Use connectors to extend Claude's capabilities](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Cloud sandbox reference](https://platform.claude.com/docs/en/managed-agents/cloud-sandboxes-reference) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Work across Microsoft 365 apps](https://support.claude.com/en/articles/13892150-work-across-microsoft-365-apps) * [How Claude Tag agent identity works](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) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI threat models should map Chat, Work, and Codex in the combined desktop app; cloud Work on web and mobile; plugins and apps; Sites; Office-native agents; Workspace Agents; Codex CLI, IDE, and cloud; API tools; and Agents SDK or Codex SDK services. Keep ChatGPT workspace controls, desktop or Codex managed configuration, and API project controls as separate control planes. Each plane has its own enforcement. ChatGPT RBAC covers workspace permissions such as apps, Codex, GPTs, projects, and canvas networking, with effective permissions taking the maximum across a user's roles, a detail that matters when modeling who can do what. Codex managed configuration controls approval policy, sandbox behavior, and MCP-related settings. Workspace Agent access tokens are distinct from platform and Compliance API credentials, so agent identities cross a boundary of their own. ### OpenAI documentation * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [Managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Workspace Agents](https://developers.openai.com/workspace-agents) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [ChatGPT desktop app](https://learn.chatgpt.com/docs/app) * [Creating and managing ChatGPT Sites](https://help.openai.com/en/articles/20001339) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about threat modeling AI systems ### What is an AI threat model? It is a map of an AI workflow that identifies data flows, trust boundaries, tools, identities, and abuse cases. It differs from a classic application threat model mainly in what counts as an actor: the model can be steered by content it reads, so untrusted data becomes an active participant. The output should be a diagram, a control list, and a handful of abuse cases that matter. ### What should be in an AI data-flow diagram? Include prompts, files, retrieval, connectors, tools, model calls, outputs, logs, memory, and external destinations. Draw the arrows for data returning from tools, not just data going in, because tool results are an instruction channel. Mark which identity each arrow uses: the user's, the agent's, or a service account's. ### Which threats should be considered first? Start with prompt injection, data exfiltration, excessive agency, confused deputy behavior, and audit gaps. These map directly to OWASP LLM Top 10 categories and recur across vendors and deployment models. STRIDE and MITRE ATLAS can then broaden the list once the top risks have owners. ### Who should join the threat-modeling session? Include security, product, platform, identity, data owner, and the team building or approving the workflow. The builder knows what the agent actually calls, the data owner knows what a leak would cost, and identity knows whose credentials each hop uses. A small session with those roles beats a large review without them. ### When should threat modeling happen? Do it before pilot, before production expansion, and after major changes to tools, data, or autonomy. A new connector, a jump in autonomy, or a switch to unattended runs each redraw trust boundaries and warrant a revisit. Keep the model lightweight enough that revisiting it is cheap. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports technical input to a fundamental-rights impact assessment. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports resilience testing, vulnerability handling, and incident response. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Inference Security, Monitoring, and GRC guidance. | | 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 AI risk identification and treatment planning. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA risk analysis, safeguard testing, and security-incident response. | *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 * [5. Threats & Adversarial](/handbook/5.-threats-and-adversarial) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk) * [5.4 Agent-specific threats: tool poisoning and confused deputy](/handbook/5.-threats-and-adversarial/5.4-agent-specific-threats-tool-poisoning-and-confused-deputy) * [7.1 Roll out by risk: the phased plan](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan) * [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) # 6. Observability, Audit & Evidence What security teams can and cannot see across AI platforms — compliance APIs, usage logs, OpenTelemetry, SIEM routing, investigation paths, and review cadence. *Last reviewed: August 18, 2026* {% hint style="info" %} You cannot govern what you cannot see. Every AI platform has audit blind spots — knowing exactly where each platform's coverage stops is what separates a real control from a false assumption. This section covers what you can see, how to route it, and how to use it. {% endhint %} ## Articles in this section 1. [6.1 The audit gap: what you can and can't see](/handbook/6.-observability-audit-and-evidence/6.1-the-audit-gap-what-you-can-and-cant-see) 2. [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility) 3. [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform) 4. [6.4 Analytics and usage APIs](/handbook/6.-observability-audit-and-evidence/6.4-analytics-and-usage-apis) 5. [6.5 Routing AI telemetry to your SIEM](/handbook/6.-observability-audit-and-evidence/6.5-routing-ai-telemetry-to-your-siem) 6. [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) 7. [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence) ## Frequently asked questions **What are the biggest audit gaps across enterprise AI platforms?**\ The largest gap is assuming one vendor API covers every surface. Coverage varies by product and changes over time. Core chat and administrative events may be available while local agent runs, browser or computer actions, tool arguments, desktop bridges, background tasks, or cross-app data flows are absent or exposed separately. Maintain a per-surface evidence matrix, generate a representative test event on each surface, and supplement vendor records with identity, endpoint, connector, repository, network, and runtime telemetry. **What is OpenTelemetry and why does it matter for AI security?**\ OpenTelemetry is a vendor-neutral framework for traces, metrics, and logs. An instrumented AI application or agent can emit model, agent, and tool spans along with latency, token usage, errors, and selected attributes. It does not automatically create visibility into a closed SaaS product, and prompt, output, and tool-argument content is opt-in or product-specific. Because those fields can contain secrets or personal data, filter or redact them and restrict telemetry access and retention before routing events to a SIEM. **Which compliance API gives me the most coverage for an AI security incident investigation?**\ No single compliance API provides complete incident coverage. Coverage differs by event type, content depth, retention, license, authentication path, and product surface. Test representative actions on every enabled surface, reconcile the resulting provider, identity, endpoint, runtime, network, repository, and target-system records, and document any investigation question the evidence cannot answer. **How do we know an AI telemetry pipeline is reliable?**\ Define expected events, delivery latency, completeness, schema version, timestamp requirements, retention, and reconciliation checks. Generate known test activity and compare the provider or runtime source count with the collector and SIEM count. Alert on silent source stoppage, parsing failures, clock drift, and unexplained sampling. ## Related handbook guidance * [AI Security Handbook](/) * [5.6 Incident response for AI system](/handbook/5.-threats-and-adversarial/5.6-incident-response-for-ai-system) * [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) # 6.1 The audit gap: what you can and can't see Every AI platform has blind spots, and knowing exactly what each platform’s logs miss is the difference between a real control and an assumption. *Last reviewed: August 18, 2026* {% hint style="info" %} Every AI platform has blind spots. A control is only real when you know what evidence proves it and what the logs miss. {% endhint %} ## The audit gap: what security teams need to know Audit coverage varies by product surface. Chat, API, coding agent, browser automation, desktop control, connectors, and hosted agents can all produce different evidence. Security teams should document what each log can answer. During an incident, vague audit expectations cost time. ## Common the audit gap security failures * The platform logs chat but not API-key automation. * A connector action appears in the SaaS log but not the AI log. * Desktop actions have endpoint evidence but no prompt context. * Compliance exports exclude a newer agent surface. * Retention windows expire before investigation. ## The audit gap security controls checklist * Create a surface-to-evidence map for each approved AI workflow. * Record what each log can and cannot answer. * Export critical logs beyond the vendor retention window where permitted. * Test audit coverage with pilot users before expansion. * Do not approve regulated workflows where required evidence is unavailable. ## Anthropic ### Overview Anthropic audit evidence splits by surface. The Claude for Enterprise Compliance API covers supported workspace chat activity, but Anthropic states that Cowork activity is not currently included in audit logs, the Compliance API, or data exports. Team and Enterprise customers can stream Cowork activity through OpenTelemetry instead. That stream can include prompts, tool and MCP calls, file paths, skills, plugin use, approvals, and errors, so it needs restricted storage and redaction. Claude's Microsoft 365 add-ins are also outside the Compliance API and data exports; their separate Office-agent OpenTelemetry feed is the main vendor telemetry path. Claude Code cloud execution runs in isolated VMs with scoped credentials and audit logging, while local Claude Code depends on OpenTelemetry and endpoint evidence configured in advance. Cowork also has two execution paths: remote sessions run in temporary Anthropic-managed sandboxes, while local files, apps, browser use, and computer use depend on the desktop. Endpoint detection tools cannot inspect the remote sandbox. Claude in Chrome actions still need target-system, browser, and endpoint evidence. Claude Tag has its own Audit view for scheduled work, saved memory, and optional hourly Agent Proxy network-event exports. Git and MCP traffic are not included in that network export, and the view does not provide a per-action record of every task and requester. Investigators still need the Slack thread, the dedicated service account's actions, and audit logs from each connected system. ### Anthropic documentation * [Claude Code authentication](https://code.claude.com/docs/en/team) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Claude in Chrome permissions guide](https://support.claude.com/en/articles/12902446-claude-in-chrome-permissions-guide) * [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) * [Access the Compliance API](https://support.claude.com/en/articles/13015708-access-the-compliance-api) * [Access audit logs](https://support.claude.com/en/articles/9970975-access-audit-logs) * [Review what Claude Tag has done](https://claude.com/docs/claude-tag/admins/audit) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI audit evidence follows the surface and authentication path. OpenAI's Work Admin FAQ says the Compliance API covers user messages and responses across Chat, Work, and Codex. It does not record Work files, actions, or tool calls. OpenAI's separate Compliance Logs Platform keeps 30 days of logs and also does not track files, actions, or tool calls. The Codex Compliance API covers ChatGPT-authenticated Codex use only; API-key-authenticated automation follows API organization settings instead. Work now runs in two materially different places. Work on the web and mobile runs in OpenAI's cloud, while Work in ChatGPT Desktop (Work / Codex) can operate on local files and apps under local Codex permissions and managed configuration. Local endpoint, filesystem, and downstream application logs remain necessary. ChatGPT Atlas is scheduled to retire on August 9, 2026, so treat its missing compliance feed as a migration issue rather than a durable control pattern. Retention still adds a clock to every gap, and the ChatGPT workspace and API Platform remain separate control planes. ### OpenAI documentation * [Compliance APIs for Enterprise Customers](https://help.openai.com/en/articles/9261474-compliance-apis-for-enterprise-customers) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) * [Chat and File Retention Policies in ChatGPT](https://help.openai.com/en/articles/8983778-chat-and-file-retention-policies-in-chatgpt) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) ### Applicable Harmonic guides for OpenAI * [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) ## Frequently asked questions about the audit gap ### What is the AI audit gap? It is the difference between what a team assumes it can see and what platform, endpoint, connector, and SIEM logs actually record. Concrete examples exist today: Cowork is outside Anthropic's Compliance API, OpenAI Work compliance records omit files and tool calls, and API-key-authenticated Codex activity does not appear in Codex Compliance API exports. Map these gaps before rollout. ### Which AI surfaces have different audit evidence? Chat, API, coding agents, browser agents, desktop control, connectors, scheduled tasks, and hosted agents can all differ. Even within one vendor the paths diverge: Claude Code cloud execution has audit logging while local runs depend on OpenTelemetry configuration, and ChatGPT workspace activity and API Platform usage sit on separate control planes. Map each surface separately rather than assuming one export covers the product family. ### What should an audit map include? For each surface, record the log source, key fields, retention window, owner, export path, known blind spots, and the investigation questions the source can answer. Note plan requirements too, since features like the ChatGPT Enterprise Compliance API are gated by plan. Keep the map versioned, because vendor releases change coverage. ### Can compliance APIs replace SIEM telemetry? No. Compliance APIs are one evidence source with documented exclusions. Cowork and Claude's Office agents need OpenTelemetry, OpenAI Work compliance records omit files, actions, and tool calls, and API-key Codex activity is missing from Codex exports. Runtime telemetry, endpoint logs, connector logs, and SaaS audit trails answer questions that conversation exports cannot, such as what a tool changed downstream. ### When should a workflow be blocked for audit reasons? Block or defer a workflow when required evidence for regulated data, write actions, or incident response is unavailable and no compensating control exists. A browser surface with no compliance feed handling regulated data is the canonical example. Record the gap, the decision, and the condition that would unblock it. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports logging coverage, known gaps, and evidence availability. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports monitoring, investigation, audit evidence, and incident reporting. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Monitoring 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 documented monitoring and audit gaps. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA audit controls, activity review, and investigation evidence. | *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 * [6. Observability, Audit & Evidence](/handbook/6.-observability-audit-and-evidence) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility) * [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform) * [6.4 Analytics and usage APIs](/handbook/6.-observability-audit-and-evidence/6.4-analytics-and-usage-apis) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) # 6.2 OpenTelemetry for AI runtime visibility How to use OpenTelemetry for AI runtime visibility across Work, Cowork, Codex, Claude Code, Copilot, Grok, and adjacent evidence sources. *Last reviewed: August 18, 2026* {% hint style="info" %} OpenTelemetry gives you visibility. It can feed alerting and investigations, but it does not block an agent action by itself. {% endhint %} ## The short version OTel, short for OpenTelemetry, is the common pipe for traces, logs, and metrics. In AI runtime security, it is useful because it can connect the user request, model call, tool call, approval decision, file access, connector call, error, and final outcome into one timeline. That makes OTel a **visibility** control. It helps you answer what happened, who initiated it, which runtime acted, which tool was called, what policy decision was made, and where the downstream action landed. It becomes a practical control only when you use it to drive detections, alerts, approvals, investigations, and response playbooks. OTel is also not vendor-specific. It is an open standard, and AI runtimes across the market are converging on it: Claude Cowork and Claude Code, OpenAI Codex, GitHub Copilot (enterprise-managed export for the VS Code extension and CLI), and xAI's Grok Build (its own exporter, emitting token, turn, tool call, and error metrics plus per-session OTLP log records) all ship OTel export today. That means one collector pipeline can serve every runtime you deploy, and OTel skills transfer across vendors. The main risk is content. Prompts, tool arguments, file names, file snippets, API responses, and connector payloads can contain secrets or regulated data. Do not stream everything into a broad SIEM index just because the vendor can export it. Put an OTel Collector or equivalent processing layer in the path, redact before ingestion, and keep raw content in a restricted evidence store only when you have a clear reason. ## What it gives you | Security value | What OTel gives you | What it does not give you | | -------------- | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | Visibility | Structured logs, traces, metrics, correlation IDs, timing, tool calls, errors, and sometimes prompts and file activity. | It does not stop the action while it is happening. | | Investigation | A timeline across prompt, model, tool, approval, target system, and result. | It does not replace endpoint, SaaS, Slack, GitHub, M365, browser, or network evidence. | | Detection | High-signal events for risky tools, denied actions, unusual connectors, data access, and policy drift. | It does not guarantee completeness unless you test source-to-SIEM delivery. | | Governance | Adoption, activity, policy outcome, and exception evidence. | It does not prove safe use unless the schema, retention, and redaction rules are documented. | ## OTel vs the Compliance API (Anthropic) Anthropic gives you two ways to see what Claude did, and they sit on different plans: OTel is available on both Team and Enterprise, while the Compliance API is Enterprise only. If you are on Team, OTel is your only feed, so treat it as such. If you are on Enterprise, the two answer different questions, and you should plan for both rather than pick one. **OTel is the wire. The Compliance API is the record.** OTel pushes structured events to your collector in real time as sessions run. The Compliance API is a pull interface over content Anthropic stores server-side: full session transcripts for Cowork and Claude Code, plus claude.ai chats, files, artifacts, and projects, retained for 6 years by default (or your configured retention period). Anthropic explicitly supports running both in parallel. | Dimension | OTel | Compliance API | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Model | Push. Real-time event stream to your OTLP collector. | Pull. Query stored content after the fact with a Compliance Access Key. | | Plan | Team and Enterprise. | Enterprise only. Session transcript endpoints are in beta. | | Content depth | Metadata by default. Prompt text, response text (60 KB cap), and tool inputs (\~4 KB cap) only when an admin enables them via `otlpContentCapture`. | Full reconstructed transcripts: prompts, assistant text, tool calls, and full tool results up to roughly 1 MiB per block. Thinking blocks, system prompts, and binary content are excluded from transcripts. | | Unique data | Token counts, estimated cost per request, execution durations, API errors and retries, and permission decisions with their source (config, hook, user). | Full tool result content, downloadable file and artifact binaries, claude.ai chat and project content, and hard-delete endpoints for chats, files, and projects (eDiscovery, legal hold, deletion requests). Sessions themselves are read-only. | | History | None. If your collector was not listening, the event is gone. | 6-year retrieval by default, walkable and resumable via cursors. | | Coverage | Any session on a configured client version. Requires the OTLP endpoint to be set before the session starts. | Does not capture Claude Code via Console API keys or Bedrock/Vertex, HIPAA-enabled orgs, or ZDR sessions. Local transcripts show only what reached the API, not on-device activity. | The practical split: route OTel into your SIEM for **detection and alerting** (approval denials, risky tool use, cost anomalies, telemetry source health), and treat the Compliance API as the **authoritative audit and retrieval layer** for investigations, eDiscovery exports, DLP review, and deletion obligations. Neither is a superset of the other: transcripts carry no token, cost, duration, or approval-decision data, and OTel carries no file binaries and no history. One trap to avoid: because OTel is metadata-only by default and the Compliance API captures transcripts server-side regardless, an Enterprise org that never enables `otlpContentCapture` still has full prompt and tool content sitting in the Compliance API. Retention, access, and legal review plans need to cover both paths. ## Product support | Product | OTel support | What security gets | Watch-outs | | ---------------- | ------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Claude Cowork | Yes for Team and Enterprise in the current documentation. | Prompts, tool and MCP calls, file access, skills and plugins, approval decisions, API requests, errors, and shared prompt identifiers. | Content capture (prompts, responses, tool inputs) is gated by the `otlpContentCapture` setting; validate what is enabled before routing to a broad index. Cowork and Claude Code sessions are also retrievable through Anthropic's Compliance API on Enterprise; see the section above. | | Claude Code | Yes. | Logs, metrics, and traces through environment variables or managed settings, with optional prompt and tool-detail logging. | Prompt content is off by default for a reason. Managed settings are the right enforcement layer for teams. | | Claude Tag | No OTel feed in the reviewed docs. | Use Tag Audit, Agent Proxy network events where enabled, Slack records, service-account logs, and connected-system logs. | Do not treat absence from the OTel collector as absence of Tag activity. | | ChatGPT Codex | Yes for local Codex configuration. | Runtime traces or logs from Codex local, useful for tool calls, approvals, errors, and local execution context where configured. | Codex user-level configuration matters. Raw prompt logging is an explicit opt-in and should stay off unless privacy and legal approve. | | ChatGPT Work | No native hosted Work OTel feed in the reviewed guides. | Use ChatGPT Compliance Logs for prompts and responses, workspace analytics, endpoint telemetry, connector logs, source-system audit logs, and Codex OTel where Work uses local Codex-adjacent execution. | Compliance Logs may not include files, actions, or tool calls. Hosted Work and local Codex need separate evidence plans. | | Grok Build (xAI) | Yes, via its own OTel exporter. | Metrics under the `ai.xai.grok_code` meter scope covering token usage, turns, tool calls, errors, and startup timings, plus structured per-session events as OTLP log records. | Nothing is emitted unless both the `GROK_EXTERNAL_OTEL` master switch and at least one exporter are configured. Verify the feed exists before assuming coverage. | | GitHub Copilot | Yes, enterprise-managed export for the VS Code Chat extension and Copilot CLI. | Centrally mandated OTLP endpoint, protocol, service name, resource attributes, and exporter headers through enterprise settings. | Coverage is scoped to the surfaces GitHub documents; other Copilot surfaces need their own evidence plan. | ## How to use it technically Put a collector between the AI runtime and the destination. That gives you one place to normalize fields, redact content, route high-risk events, and detect broken sources. A practical OTel pipeline has five parts: 1. **Runtime exporter.** Configure Claude Code, Claude Cowork, Codex, Copilot, Grok Build, or another runtime to export telemetry to an OTLP endpoint. 2. **Collector.** Receive OTLP over HTTP or gRPC. Use processors to redact, drop, transform, batch, and route events. 3. **Restricted evidence store.** Keep sensitive prompt or tool content here only if the business, legal, and privacy teams agree it is needed. 4. **SIEM or data lake.** Send normalized metadata, high-risk events, and approved redacted fields for broad search and detection. 5. **Correlation layer.** Join OTel events with endpoint, IdP, GitHub, Slack, M365, browser, DLP, network, and source-system logs. For Claude Code, the technical switch usually starts with telemetry enabled and OTLP exporters configured. A simple pattern is: {% code collapsedlinecount="10" %} ```bash CLAUDE_CODE_ENABLE_TELEMETRY=1 OTEL_LOGS_EXPORTER=otlp OTEL_TRACES_EXPORTER=otlp OTEL_METRICS_EXPORTER=otlp OTEL_EXPORTER_OTLP_ENDPOINT=https://otel-collector.example.com ``` {% endcode %} Use managed settings to distribute this for enterprise users, and keep prompt and tool-content flags disabled unless you have a redaction and retention design. For Claude Cowork, configure OTel from the organization Cowork settings and send it to a standard OTel Collector. Validate whether prompts and tool parameters are included before connecting it to a shared logging destination. For Codex, configure OTel in the user-level Codex configuration, not only in a repo-local file. Treat prompt logging as a separate data decision. The safe default is metadata first, prompt content later only if approved. ## Minimum AI event schema Normalize vendor events into one schema. You do not need every field on day one, but you need the same shape across products. | Field group | Minimum fields | | ----------- | ------------------------------------------------------------------------------------------------------------------- | | Event | Event type, schema version, event time, ingestion time, source, environment. | | Identity | User, group, agent or service identity, tenant or workspace, project. | | Execution | Product, surface, local or hosted runtime, task ID, trace ID, parent task, model, policy version. | | Action | Tool or capability, target system, target object, argument classification, approval requirement, approval decision. | | Outcome | Result, error, retry, duration, token count, spend, stop reason, cancellation state. | | Evidence | Redaction state, source record ID, downstream record ID, retention class. | Keep raw prompts out of the shared schema by default. Store hashes, classifications, token counts, prompt IDs, or restricted links when that is enough. ## How to use it as a practitioner Start with the questions a security team needs to answer during rollout: * Who is using Work, Cowork, Code, Codex, and Tag? * Which tasks touched local files, browser sessions, connectors, Slack, M365, GitHub, or production systems? * Which actions required approval, and which were denied? * Which MCP servers, plugins, skills, hooks, and browser sessions appeared in the trace? * Did a scheduled or unattended task do anything that would have required a human in a live session? * Can an investigator connect the AI event to the downstream SaaS, endpoint, repository, or ticket record? Build dashboards around those answers, not around generic token charts. Good first dashboards are: high-risk tool use, approvals and denials, connector reads and writes, file access by data class, sandbox mode distribution, network egress attempts, scheduled tasks, prompt-content logging status, and telemetry source health. Then test the pipeline with canary actions. Run a safe denied read, a safe blocked network request, a safe approved file edit, a safe connector read, and a safe tool failure. Confirm each event appears at the runtime, collector, destination, and investigation view. Repeat this after product upgrades, collector changes, schema changes, and new policy releases. ## Redaction stance The collector should remove or transform sensitive content before broad export. Use OpenTelemetry processors, including redaction or transform processors where appropriate, to drop sensitive attributes, mask secrets, and route high-risk records to a narrower destination. Redaction after SIEM ingestion is too late. At that point, the content has already been stored, indexed, searched, and possibly copied into alerts. A clean starting policy is: * Store prompt text only in a restricted evidence store, and only for approved groups or incident workflows. * Send prompt IDs, hashes, classifications, model names, and tool names to the SIEM. * Drop secret-like values from tool arguments before indexing. * Keep file contents out of telemetry unless there is a specific, documented investigation need. * Alert on telemetry configuration drift, source silence, collector errors, and unexpected prompt-content logging. ## What to avoid * Do not assume Compliance Logs, OTel, endpoint logs, and connector logs contain the same events. They rarely do. * Do not sample away approval, denial, file access, connector write, hook, or sandbox-denial events. * Do not use one retention rule for every field. Metadata and prompt content usually need different retention and access. * Do not treat a clean OTel dashboard as proof of clean AI use until you have tested source completeness. * Do not let agents edit their own telemetry configuration or collector routing. ## Sources and related guidance * [Securing ChatGPT Work: A Practitioner's Guide](https://www.harmonic.security/resources/securing-chatgpt-work-a-practitioners-guide) * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) * [Monitor Claude Cowork activity with OpenTelemetry](https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry) * [Cowork monitoring reference (OTel events and attributes)](https://claude.com/docs/cowork/monitoring) * [Anthropic Compliance API: retrieve session transcripts](https://platform.claude.com/docs/en/manage-claude/compliance-sessions) * [Anthropic Compliance API: retrieve and delete chats, files, and projects](https://platform.claude.com/docs/en/manage-claude/compliance-content-data) * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) * [Codex configuration reference](https://developers.openai.com/codex/config-reference) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex) * [Grok Build OpenTelemetry monitoring (SigNoz)](https://signoz.io/docs/grok-build-observability/) * [Enterprise-managed OpenTelemetry export for VS Code and CLI (GitHub changelog)](https://github.blog/changelog/2026-07-08-enterprise-managed-opentelemetry-export-for-vs-code-and-cli/) * [OpenTelemetry Collector processors](https://opentelemetry.io/docs/collector/components/processor/) * [OpenTelemetry Collector redaction processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/redactionprocessor/README.md) ## Related handbook guidance * [6. Observability, Audit & Evidence](/handbook/6.-observability-audit-and-evidence) * [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform) * [6.5 Routing AI telemetry to your SIEM](/handbook/6.-observability-audit-and-evidence/6.5-routing-ai-telemetry-to-your-siem) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) * [2.6 AI hooks: inference controls and lifecycle automation](/handbook/2.-supply-chain-and-extensibility/2.6-ai-hooks-inference-controls-and-lifecycle-automation) # 6.3 Compliance APIs by platform The programmatic audit endpoint per vendor, what each one returns, and exactly where each one stops. *Last reviewed: August 18, 2026* {% hint style="info" %} Compliance APIs are evidence sources, not complete visibility. Know the endpoint, the retention window, and the missing surfaces before an incident. {% endhint %} ## Compliance APIs by platform: what security teams need to know AI compliance APIs can export audit logs, conversations, files, or activity records depending on the vendor and plan. They are useful for investigations, eDiscovery, and control evidence. The mistake is treating a compliance API as complete coverage. API-key automation, desktop control, browser automation, connectors, or new agent features may have separate evidence paths. ## Common compliance APIs by platform security failures * The endpoint is enabled after an incident rather than before. * Exports omit the surface involved in the workflow. * The team lacks permission to request or retrieve data quickly. * Prompt content is exported without redaction planning. * Records are not correlated with connector and endpoint logs. ## Compliance APIs by platform security controls checklist * Document endpoint, plan requirement, fields, retention, limits, and owner. * Test exports during pilot with known activity. * Correlate compliance exports with SIEM, endpoint, SaaS, and network logs. * Protect exported content as sensitive evidence. * Keep a source gap list for surfaces the API does not cover. ## Anthropic ### Overview Anthropic exposes several distinct evidence paths rather than one export. Claude for Enterprise includes a Compliance API for supported workspace activity. Anthropic explicitly excludes Cowork activity from audit logs, the Compliance API, and data exports. Team and Enterprise customers can stream Cowork events through OpenTelemetry instead. Claude's Microsoft 365 add-ins are also outside the Compliance API and data exports, with a separate Office-agent OpenTelemetry path. Claude Code cloud execution provides audit logging in isolated VMs, local Claude Code depends on OpenTelemetry and endpoint evidence, and Managed Agents expose session events and webhooks. Managed Agents is in beta and sessions are not currently eligible for zero data retention or HIPAA BAA coverage. Console/API retention behavior, including zero-data-retention options, is documented separately. Claude Tag should be mapped as a separate evidence plane, not assumed to flow through the Enterprise Compliance API. Its Audit view covers routines, memory, and optional Agent Proxy network events, while action attribution appears in Slack and each connected service. Preserve those records and document the gap: there is no per-action Claude Tag audit row for every task and requester. ### Anthropic documentation * [Claude Code authentication](https://code.claude.com/docs/en/team) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Code data usage](https://code.claude.com/docs/en/data-usage) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [API and data retention](https://platform.claude.com/docs/en/manage-claude/api-and-data-retention) * [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) * [Configure OpenTelemetry for Claude's Office agents](https://support.claude.com/en/articles/14447276-configure-a-custom-opentelemetry-collector-for-office-agents) * [Access the Compliance API](https://support.claude.com/en/articles/13015708-access-the-compliance-api) * [Access audit logs](https://support.claude.com/en/articles/9970975-access-audit-logs) * [Review what Claude Tag has done](https://claude.com/docs/claude-tag/admins/audit) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI's Enterprise Compliance API covers user messages and responses across Chat, Work, and Codex. The broader ChatGPT API also exposes workspace conversations, GPTs, users, and workspace memories, with documented read and delete permissions. Coverage stops short of complete agent telemetry: OpenAI says Work files, actions, and tool calls are not tracked in the Compliance API or the 30-day Compliance Logs Platform. Canvas events are also not yet supported. The Codex Compliance API covers ChatGPT-authenticated Codex activity only; API-key-authenticated usage follows API organization settings and does not appear in Compliance API exports. Work on the web and mobile runs in the cloud, while Work and Codex on desktop can act on local files and apps. Those local actions need Codex telemetry, endpoint evidence, and downstream system logs. ChatGPT Atlas is scheduled to retire on August 9, 2026, so organizations should preserve any required Atlas evidence while migrating. ### OpenAI documentation * [Compliance APIs for Enterprise Customers](https://help.openai.com/en/articles/9261474-compliance-apis-for-enterprise-customers) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) * [Chat and File Retention Policies in ChatGPT](https://help.openai.com/en/articles/8983778-chat-and-file-retention-policies-in-chatgpt) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) * [Data controls in the OpenAI platform](https://developers.openai.com/api/docs/guides/your-data) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Reference table: compliance APIs by platform This table summarizes the documented endpoints as of the last review date. Verify plan requirements and coverage against current vendor documentation before relying on a row. | Platform | API or export | Plan requirement | Coverage | Documented exclusions and caveats | | ----------------------------------------------- | -------------------------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- | | Claude chat (web, desktop, mobile) | Claude for Enterprise Compliance API | Claude for Enterprise | Supported workspace evidence for enterprise oversight | Verify individual event types; downstream SaaS activity needs its own evidence | | Claude Cowork | OpenTelemetry | Team and Enterprise | Prompts, tool and MCP calls, file access, skills, plugins, approvals, errors | Not in audit logs, Compliance API, or data exports; remote execution is invisible to endpoint detection tools | | Claude for Excel, PowerPoint, Word, and Outlook | Office-agent OpenTelemetry plus Microsoft 365 logs | Eligible Claude and Microsoft 365 plans | Prompts, tools, file references, user identity, and downstream Office activity | Not in Anthropic audit logs, Compliance API, or data exports; custom retention does not apply to add-in inputs and outputs | | Claude Code (cloud execution) | Cloud execution audit logging | Cloud execution environment | Isolated-VM runs with scoped credentials | Local runs depend on OpenTelemetry monitoring and endpoint evidence | | Claude Managed Agents | Session event streams and webhooks | Beta (managed-agents header required) | Session and event history for agent runs | Sessions persist server-side; not currently ZDR- or HIPAA-BAA-eligible | | ChatGPT Chat and Work | Enterprise Compliance API | Enterprise only | User messages and responses across Chat and Work; broader workspace conversation and GPT records | Work files, actions, and tool calls are not tracked; canvas events are not yet supported | | Codex | Codex Compliance API and governance exports | Codex Enterprise | ChatGPT-authenticated Codex activity records | API-key-authenticated Codex usage excluded; it follows API organization settings | | ChatGPT Atlas, until retirement | None | Not applicable | Not applicable | No Compliance API feed; scheduled to retire August 9, 2026 | ## Frequently asked questions about compliance APIs by platform ### What is a compliance API for AI platforms? It is a vendor endpoint that exports audit, activity, conversation, or file records for eDiscovery, DLP, and SIEM integration. The ChatGPT Enterprise Compliance API and the Claude for Enterprise Compliance API are the main examples, and Codex Enterprise adds a coding-agent path. Every endpoint has exclusions. Anthropic excludes Cowork and Office-agent activity, while OpenAI excludes Work files, actions, and tool calls. ### Do compliance APIs show every AI action? No. Coverage varies by product surface, plan, and authentication path. Cowork and Claude's Office agents require OpenTelemetry rather than the Compliance API. OpenAI Work messages are covered, but files, actions, and tool calls are not. Codex excludes API-key automation. Keep a written gap list next to the endpoint documentation. ### What should be tested before rollout? Run known activity through the pilot workflow and confirm which parts appear: users, prompts, files, tools, approvals, and downstream actions. A successful conversation export does not prove that the file or tool call was captured. Test the delete path too if you plan to rely on it, and time retrieval with the permissions responders actually hold. ### How should exports be protected? Treat them as sensitive evidence, because they can contain full prompts, files, outputs, memories, and personal data. Restrict access to the compliance integration credentials, store exports in a controlled evidence system rather than a broad log index, and apply your existing eDiscovery handling rules. ### What should be documented? Document endpoint, owner, plan requirement, access process, fields, retention, blind spots, and the investigation playbook that uses each source. The reference table on this page is a starting skeleton; keep your copy dated, because vendor coverage changes. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports access to platform logs and compliance evidence. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports monitoring, investigation, audit evidence, and incident reporting. | | 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA audit controls, activity review, and investigation evidence. | *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 * [6. Observability, Audit & Evidence](/handbook/6.-observability-audit-and-evidence) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility) * [6.5 Routing AI telemetry to your SIEM](/handbook/6.-observability-audit-and-evidence/6.5-routing-ai-telemetry-to-your-siem) * [4.4 Retention and Zero Data Retention](/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) # 6.4 Analytics and usage APIs Adoption, cost, and usage telemetry help spot shifts in AI behavior, tool adoption, connector usage, and spend anomalies. *Last reviewed: August 18, 2026* {% hint style="info" %} Usage telemetry shows how AI adoption is changing. It also points to risk shifts, such as new tools, new models, or sudden API growth. {% endhint %} ## Analytics and usage APIs: what security teams need to know Analytics and usage APIs help teams understand adoption, cost, model use, and workflow shifts. They can also reveal security signals when usage moves from approved chat to API keys, coding agents, or cloud runs. Usage data is not enough for investigations, but it is useful for review cadence and risk prioritization. ## Common analytics and usage APIs security failures * Cost spikes are treated only as finance issues. * Usage shifts to a new surface without security review. * Model or tool adoption changes after a vendor release. * API usage grows under a personal or unknown project owner. * Analytics dashboards are not exported or reviewed. ## Analytics and usage APIs security controls checklist * Track usage by product surface, project, model, user group, and environment. * Review cost and volume anomalies with security context. * Compare approved users against active usage. * Watch for shifts from chat to API, browser, desktop, or coding agents. * Use usage data to prioritize control reviews. ## Anthropic ### Overview Anthropic documents two dedicated Claude Code analytics dashboards. Team and Enterprise plans get a dashboard at claude.ai/analytics/claude-code with usage metrics, GitHub-integrated contribution metrics, and CSV export, viewable by Admins and Owners; contribution metrics are unavailable under Zero Data Retention. Claude Console (API) customers get a separate dashboard at platform.claude.com/claude-code showing usage, spend estimates, and per-user team insights, gated by the UsageView permission — a useful way to give reviewers analytics access without broader Console rights. Beyond the Claude Code dashboards, Claude Enterprise analytics provides product-specific views across Claude chat, Claude Code, and Cowork, and the Analytics API can break down usage and cost by product, model, context window, or region. Compare custom-role grants against observed activity, and watch for shifts to local MCP, Office agents, scheduled Managed Agent runs, and Claude Tag. Claude Tag adds organization and per-channel spend limits, threshold alerts, and a per-channel spend breakdown. Channel work bills to the organization, while direct messages bill to the individual's Claude account. Keep that split in usage reviews so a quiet organization channel does not hide personal DM usage, and vice versa. ### Anthropic documentation * [Track team usage with analytics (Claude Code)](https://code.claude.com/docs/en/analytics) * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [Monitor Claude Cowork activity with OpenTelemetry](https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry) * [Configure OpenTelemetry for Claude's Office agents](https://support.claude.com/en/articles/14447276-configure-a-custom-opentelemetry-collector-for-office-agents) * [Claude Enterprise consumption guide](https://support.claude.com/en/articles/14782391-claude-enterprise-consumption-guide) * [What is Claude Tag?](https://support.claude.com/en/articles/15594475-what-is-claude-tag) ## OpenAI ### Overview Codex Enterprise exposes analytics dashboards and an Analytics API alongside its Compliance API. In ChatGPT Enterprise, the Analytics Viewer role grants analytics access without broader administration rights. OpenAI's Global Admin analytics now spans adoption and credit use across Chat, Work, and Codex, so those surfaces should be broken out rather than blended into a single ChatGPT count. On the API Platform, key usage can be monitored on the usage page, and separate projects can isolate staging from production with different rate and spend limits. Group adoption metrics by surface and execution location. Work on web and mobile runs in the cloud; Work and Codex in the new desktop app can use local files and applications; Codex also remains available through CLI, IDE, web, and cloud clients. Each path has different controls and evidence. ### OpenAI documentation * [Codex governance](https://developers.openai.com/codex/enterprise/governance) * [Managing members, seat types, roles and access in ChatGPT Enterprise](https://help.openai.com/en/articles/8266401-managing-members-seat-types-roles-and-access-in-chatgpt-enterprise) * [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) ### Applicable Harmonic guides for OpenAI * [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) ## Frequently asked questions about analytics and usage APIs ### What do AI usage APIs show? They show adoption, volume, cost, model use, project activity, and surface shifts, with depth varying by provider and plan. OpenAI offers cross-surface analytics for Chat, Work, and Codex, Codex Enterprise adds an Analytics API, and Claude Code has Team/Enterprise and Console dashboards with CSV export. None is an investigation-grade audit log. ### Are usage APIs audit logs? No. They measure activity but usually lack the prompt, tool-call, and approval detail investigations need — that lives in compliance APIs, OpenTelemetry, and endpoint evidence. Use analytics to decide where to look, then switch to audit sources to answer what happened. ### What usage anomalies matter? Watch for cost spikes, new projects, unusual model use, unexpected API growth, and usage outside approved groups. A shift in surface matters most: a team whose usage moves from workspace chat to API keys or unattended runs has changed its evidence path, not just its bill. ### Can usage APIs detect shadow AI? They can surface strong leads. API usage growing under an unknown or personal project owner, spend appearing outside managed organizations, and active users who are not in the approved group are all shadow-AI signals visible in usage data. Confirming and attributing the activity still requires identity, network, or endpoint evidence, so treat analytics as the tripwire rather than the proof. ### Who should review usage data? Platform, security, finance, and business owners should review it together, because the same spike can be a budget problem, a rollout success, or an exfiltration signal. Give reviewers scoped access — ChatGPT Enterprise has an Analytics Viewer role and the Claude Console dashboard is gated by the UsageView permission — so reporting does not require admin rights. ## 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.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Monitoring and GRC guidance. | | G.8 ISO/IEC 42001 AI management system | This article supports ISO/IEC 42001 AIMS preparation through objectives, measures, and performance evidence. | ## Related handbook guidance * [6. Observability, Audit & Evidence](/handbook/6.-observability-audit-and-evidence) * [6.1 The audit gap: what you can and can't see](/handbook/6.-observability-audit-and-evidence/6.1-the-audit-gap-what-you-can-and-cant-see) * [6.5 Routing AI telemetry to your SIEM](/handbook/6.-observability-audit-and-evidence/6.5-routing-ai-telemetry-to-your-siem) * [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence) * [7.2 Pilot design and success metrics](/handbook/7.-rollout-and-operations/7.2-pilot-design-and-success-metrics) # 6.5 Routing AI telemetry to your SIEM How to get compliance APIs, usage logs, and runtime telemetry into the SOC with starter detections for AI-specific events. *Last reviewed: August 18, 2026* {% hint style="info" %} Telemetry is useful only when it reaches the people who respond. Normalize AI events, redact sensitive content, and write detections that match real workflows. {% endhint %} ## What security teams need to know about routing AI telemetry to your SIEM AI telemetry often arrives from several places: platform APIs, OpenTelemetry, endpoint logs, connector logs, proxy logs, and hosted-agent services. The SIEM should join these signals without turning prompts into uncontrolled data stores. AI telemetry reaches a SIEM over three transports: polling compliance and analytics APIs, collector export from OpenTelemetry-instrumented runtimes, and push delivery through event streams or webhooks from hosted agent services. Most programs need at least two of the three. Start with detections that map to control failures. Examples include sandbox escalation, denied secret reads, new connector scopes, unexpected egress, and external write actions after untrusted content. ## Common routing AI telemetry to your SIEM security failures * Prompt content is sent to a broad log index without redaction. * Vendor logs and endpoint logs use different identities. * Detections fire without an owner or runbook. * Tool-call data is too verbose to search during an incident. * High-risk denied actions are not ingested. ## Routing AI telemetry to your SIEM security controls checklist * Normalize identities, surfaces, runtimes, models, policies, tools, approvals, targets, outcomes, and correlation IDs. * Redact or restrict prompts, outputs, tool parameters, file paths, and connector payloads before broad ingestion. * Preserve source identifiers so analysts can retrieve restricted evidence when authorized. * Build detections from approved threat scenarios and expected control behavior. * Monitor repeated denied reads, new connector grants, tool-definition drift, unusual destinations, persistent-memory changes, cross-tenant identifiers, runaway usage, failed stops, and telemetry silence. * Baseline by cohort, agent, project, task type, destination, time, and cost rather than only total usage. * Test detections with representative events and verify attribution to the initiating user and acting identity. * Attach every detection to an owner, severity rule, investigation query, containment step, and review cadence. ## Starter detection library | Detection | Signal to correlate | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Sensitive-path probing | Repeated denied reads, secret-scanner hits, file paths, and subsequent tool or network activity | | New or widened authority | Connector grant, role change, service-account scope, new MCP server, plugin, skill, hook, or agent version | | Tool or instruction drift | Hash or version change after approval, new tool schema, changed destination, or unsigned update | | Injection-to-action chain | Untrusted content followed by privileged retrieval, external write, publishing, or credential use | | Internal network reach | Metadata, loopback, private address, management socket, unusual DNS, redirect, or callback destination | | Memory or retrieval poisoning | New persistent memory, knowledge-source update, unusual author, changed labels, or later cross-user effect | | Denial of wallet | Token, tool, retry, duration, concurrency, storage, or third-party cost above task and cohort baseline | | Stop or revocation failure | Cancellation followed by tool, queue, child-agent, webhook, or target-system activity | | Evidence degradation | Source silence, ingestion delay, parser error, schema drift, clock drift, unexpected sampling, or attribution loss | Use detections to answer a response question. An alert without a way to identify the task, authority, target, output, and containment control will not help during an incident. ## Anthropic ### Overview Anthropic routing combines pull and push. Claude Code emits OpenTelemetry, Claude Code cloud execution produces audit logs, and Managed Agents expose event streams and webhooks. Cowork and Claude's Microsoft 365 add-ins need their own OpenTelemetry collectors because Anthropic does not include those surfaces in the Compliance API or data exports. These feeds can carry full prompts, tool parameters, file paths or URLs, and user identity, so route them through a restricted collector and redact before broad SIEM ingestion. Permission and approval events are strong starter detections. Claude Code deny rules take precedence over ask and allow rules, and Cowork telemetry can record approvals. Alert on repeated denials against secret paths, network tools, or cross-app actions. Normalize user, surface, agent or session, tool, target system, approval state, credential type, and data class before events land in shared indexes. Claude Tag adds an optional hourly JSON export of Agent Proxy network events rather than the same OpenTelemetry feed. It omits Git and MCP traffic, so ingest it as one partial source and join it with Slack threads, Claude Tag routine and memory records, and target-system audit logs under the dedicated service-account identity. ### Anthropic documentation * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) * [Configure permissions](https://code.claude.com/docs/en/permissions) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Monitor Claude Cowork activity with OpenTelemetry](https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry) * [Configure OpenTelemetry for Claude's Office agents](https://support.claude.com/en/articles/14447276-configure-a-custom-opentelemetry-collector-for-office-agents) * [Review what Claude Tag has done](https://claude.com/docs/claude-tag/admins/audit) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI routing starts with two polled sources. The ChatGPT Enterprise Compliance API delivers messages and responses across Chat, Work, and Codex, and Codex governance exports deliver ChatGPT-authenticated Codex activity. API-key-authenticated Codex use is excluded. Neither the Compliance API nor OpenAI's 30-day Compliance Logs Platform records Work files, actions, or tool calls. Codex can additionally export runtime logs through OpenTelemetry when an exporter is configured in the user-level `~/.codex/config.toml`. Codex approval events are the best starter detection. Approval policies generate explicit approve and deny decisions, so a spike in denied requests, or a session moving to dangerous full access, is worth an alert. For Work actions, join message records to endpoint, plugin, connected-app, and target-system logs. Keep redaction close to collection so prompts, files, and secrets do not become SIEM data spills. ### OpenAI documentation * [Compliance APIs for Enterprise Customers](https://help.openai.com/en/articles/9261474-compliance-apis-for-enterprise-customers) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) * [Agent approvals & security](https://developers.openai.com/codex/agent-approvals-security) * [Config Reference (Codex)](https://developers.openai.com/codex/config-reference) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about routing AI telemetry to your SIEM ### What AI telemetry belongs in a SIEM? Send metadata for prompts, model calls, tool calls, approvals, denials, connectors, egress, and identity events. Prioritize the low-volume, high-signal streams first — approval and denial decisions, sandbox changes, and connector grants — before ingesting verbose tool-call traces that are expensive to store and hard to search. ### Should full prompts go into the SIEM? Usually not by default. Use redaction, hashing, or restricted evidence storage unless full content is required for a specific investigation class, and make the decision explicitly — Codex, for example, only exports raw prompts when an opt-in flag is set. A broad index full of prompts is itself a data-spill risk. ### What are good starter detections? Ground detections in events the platforms actually emit. Codex approval denials and Claude Code permission denials are explicit policy-enforcement records, and both are worth alerting on when they spike or touch secrets paths. Add sandbox escalation, new connector scopes, external writes after untrusted content, and unexpected network destinations as the next tier. ### How should identities be normalized? Map user, agent, API key, service account, device, and project identifiers into one investigation view before you need it. Vendor logs and endpoint logs rarely share an identity scheme, and API keys in particular need a documented human owner or the trail stops at the key. ### Who owns AI detections? Security owns detection quality: the rules, their tuning, and their false-positive budget. Platform and app owners hold the runbooks for product-specific response, because containment steps differ between a workspace chat, a coding agent, and a hosted agent run. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports incident detection and escalation. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports monitoring, investigation, audit evidence, and incident reporting. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Monitoring 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.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA audit controls, activity review, and investigation evidence. | *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 * [6. Observability, Audit & Evidence](/handbook/6.-observability-audit-and-evidence) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility) * [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) * [5.6 Incident response for AI system](/handbook/5.-threats-and-adversarial/5.6-incident-response-for-ai-system) # 6.6 Evidence by surface and investigation paths Which log answers which question, per AI surface — the reference table you reach for during an AI security incident. *Last reviewed: August 18, 2026* {% hint style="info" %} During an incident, the first question is where the evidence lives. Build the surface map before you need it. {% endhint %} ## What security teams need to know about evidence by surface and investigation paths Each AI surface leaves a different evidence trail. Chat may have workspace audit events. API usage may have organization logs. Coding agents may have local files, terminal history, and provider traces. Browser and desktop actions may require endpoint or browser evidence. An investigation path should say which logs answer which question and which gaps require user interview, endpoint capture, or vendor support. ## Common evidence by surface and investigation paths security failures * Investigators start with the wrong log source. * A surface is approved before its evidence path is tested. * Local agent files are overwritten before preservation. * Connector logs and AI logs are not correlated. * API-key activity lacks user attribution. ## Evidence by surface and investigation paths security controls checklist * Create a table of surface, source, owner, retention, key fields, and gaps. * Test each evidence path during pilot. * Preserve local files, transcripts, approvals, and tool logs where relevant. * Correlate AI events with SaaS, endpoint, proxy, and identity logs. * Record evidence gaps as rollout blockers for regulated workflows. ## Test the evidence path For each surface, script a small set of actions: sign in, read approved data, attempt a denied read, grant a connector, call a tool, approve and deny an action, create an output, cancel work, revoke access, and delete the resulting data where supported. Record the expected provider, identity, endpoint, runtime, network, repository, and target-system events. Compare expected and actual records, timestamps, identities, correlation IDs, content visibility, and retention. Treat missing or unattributable evidence as a documented gap with a compensating control, not as “not applicable.” Repeat the reconciliation after major releases, schema changes, collector changes, licensing changes, new authentication paths, and incidents. Preserve the test cases so audit coverage can be revalidated rather than rediscovered. ## Anthropic ### Overview Anthropic investigation paths start with the surface. For supported Claude chat activity in an Enterprise workspace, start with the Compliance API. Do not use that path for Cowork. Anthropic says Cowork is outside audit logs, the Compliance API, and data exports. Team and Enterprise investigators should start with Cowork OpenTelemetry, then correlate remote session records or local desktop evidence with target-system logs. Endpoint tools cannot inspect the remote Cowork sandbox. Claude's Microsoft 365 add-ins also need their separate Office-agent OpenTelemetry feed plus Microsoft 365 audit logs. For Claude Code, split by execution mode: cloud execution has audit logging in isolated VMs, while local runs depend on OpenTelemetry, local transcripts, and endpoint evidence. For Managed Agents, pull the session event history and webhook-delivered events. Claude in Chrome actions are recorded mainly in the target systems the extension touched, so correlate SaaS audit trails with the admin site controls, role grants, browser evidence, and endpoint logs. For Claude Tag channel work, start with the Slack thread and Claude Tag Audit view, then pivot to the service account in each connected system. Add the optional Agent Proxy network export if enabled, but account for its Git and MCP exclusions. For direct messages, follow the user's Claude account and personal connectors rather than the channel's agent identity. ### Anthropic documentation * [Claude Code authentication](https://code.claude.com/docs/en/team) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Claude in Chrome permissions guide](https://support.claude.com/en/articles/12902446-claude-in-chrome-permissions-guide) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [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) * [Configure OpenTelemetry for Claude's Office agents](https://support.claude.com/en/articles/14447276-configure-a-custom-opentelemetry-collector-for-office-agents) * [Access the Compliance API](https://support.claude.com/en/articles/13015708-access-the-compliance-api) * [Access audit logs](https://support.claude.com/en/articles/9970975-access-audit-logs) * [Review what Claude Tag has done](https://claude.com/docs/claude-tag/admins/audit) * [How Claude Tag agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI investigation paths split by surface, execution location, and authentication. The Enterprise Compliance API covers user messages and responses across Chat, Work, and Codex, but it does not record Work files, actions, or tool calls. Work on web and mobile runs in the cloud. Work and Codex in ChatGPT Desktop (Work / Codex) can act on local files and applications, so preserve Codex telemetry, local thread and filesystem evidence, endpoint records, plugin and app logs, and target-system audit events. Codex evidence also depends on authentication. ChatGPT-authenticated activity appears in the Codex Compliance API and governance exports. API-key-authenticated runs are excluded and follow API organization settings, so their trail starts with API usage records and endpoint evidence. ChatGPT agent mode runs on a hosted virtual computer, making conversation and confirmation records useful but insufficient without connected-app and downstream SaaS logs. ChatGPT Atlas has no Compliance API feed and is scheduled to retire on August 9, 2026; preserve required endpoint and browser evidence during migration. ### OpenAI documentation * [Compliance APIs for Enterprise Customers](https://help.openai.com/en/articles/9261474-compliance-apis-for-enterprise-customers) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) * [Introducing ChatGPT agent](https://openai.com/index/introducing-chatgpt-agent/) * [Production best practices](https://developers.openai.com/api/docs/guides/production-best-practices) ### Applicable Harmonic guides for OpenAI * [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) ## Reference table: evidence by surface Primary evidence is where an investigation should start; secondary evidence corroborates or fills detail; the known gap is what neither will show. Verify rows against current vendor documentation before relying on them. | Surface | Primary evidence | Secondary evidence | Known gap | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | ChatGPT Chat (Enterprise) | Enterprise Compliance API (messages and responses; broader conversation, GPT, user, and memory records) | Workspace settings, IdP logs, connected-app logs | Canvas events not yet supported | | ChatGPT Work, web or mobile | Enterprise Compliance API messages and responses | Connected-app and target-system logs | Files, actions, and tool calls are not tracked by Compliance API or Compliance Logs Platform | | ChatGPT Work or Codex, desktop | Compliance records plus Codex governance or OpenTelemetry where available | Local thread and filesystem evidence, endpoint, plugin, app, and target-system logs | Local actions span several evidence systems; cloud Work threads do not appear in desktop Work at launch | | Codex, ChatGPT-authenticated | Codex Compliance API and governance exports | Local logs, repo and worktree history, endpoint evidence | Covers ChatGPT-authenticated activity only | | Codex, API-key-authenticated | API organization usage records | Endpoint evidence: terminal history, local Codex logs, repo history | Not in Compliance API exports; attribution stops at the key without an owner registry | | ChatGPT Atlas, until August 9, 2026 | Endpoint and browser evidence | Downstream SaaS logs, proxy logs | No Compliance API feed; surface is retiring | | ChatGPT agent mode | Conversation record and confirmation prompts | Downstream SaaS and connector logs | Hosted virtual computer leaves little local evidence | | Claude chat, web, desktop, mobile (Enterprise) | Enterprise workspace evidence, including Compliance API | Connector and downstream SaaS logs | Verify event coverage for the workflow | | Claude Cowork, remote | Cowork OpenTelemetry and session context | Target-system, identity, and network logs | Not in audit logs, Compliance API, or data exports; endpoint tools cannot inspect the remote sandbox | | Claude Cowork, local desktop | Cowork OpenTelemetry | Local files, endpoint, browser, connector, and target-system logs | Desktop must be online for local access; evidence is distributed | | Claude Office agents | Office-agent OpenTelemetry | Microsoft 365 audit logs and file history | Not in Anthropic audit logs, Compliance API, or data exports | | Claude Code, local | OpenTelemetry monitoring, local transcripts | Repo history, endpoint logs | Telemetry must be configured before the incident | | Claude Code, cloud execution | Cloud execution audit logs | Scoped credential logs, repo history | Different evidence path from local runs; map both | | Claude Managed Agents | Session event streams, webhooks, event history | Downstream SaaS logs | Beta; sessions persist server-side and are not ZDR-eligible | | Claude in Chrome | Target-system (SaaS) audit logs | Admin allowlist/blocklist configuration, role grants, browser evidence | Actions recorded mainly where they land, not in a central export | ### Worked example: API-key Codex CLI An employee pastes a customer record into a Codex CLI session authenticated with an API key. Nothing appears in the Codex Compliance API, because it covers ChatGPT-authenticated use only. The pivot: identify which API organization and project owns the key, pull usage records from the API Platform usage page to time-box the activity, then collect endpoint evidence from the device — terminal history, local Codex logs, and worktree state. The prerequisite this exposes is attribution: if keys are not mapped to human owners before the incident, step one fails. ## Frequently asked questions about evidence by surface and investigation paths ### Where is AI investigation evidence stored? It depends on the surface. Evidence can sit in compliance APIs, OpenTelemetry, cloud execution logs, session histories, endpoint files, connector and SaaS logs, browser evidence, and Microsoft 365 audit records. Cowork and Claude's Office agents are clear examples where telemetry must replace the expected compliance export. ### What is a surface-to-evidence map? It is a table that maps each AI surface to the records an investigation would pull, in order. A row typically reads like: Codex with an API key — primary evidence is API organization usage records, secondary is terminal history and local logs on the endpoint, and the known gap is that nothing appears in Compliance API exports. Build one row per approved surface and test each during pilot. ### Why is API-key activity hard to investigate? A key identifies a project or service account, not a person, so the trail stops unless key ownership was registered in advance. It also skips the strongest logging path: API-key-authenticated Codex use is excluded from Compliance API exports. Owner registration and usage tracking are the compensating controls. ### What evidence should be preserved first? Preserve the volatile and overwritable material first: local transcripts, worktrees, terminal history, and approval records on the endpoint, since agents routinely overwrite their own state. Then capture prompts, outputs, tool calls, connector logs, and credential events from platform sources, which are subject to retention windows rather than immediate loss. ### How should gaps be handled? Document each gap, decide whether the workflow can proceed, and add compensating controls where needed. Endpoint logging and SaaS audit trails cover some missing vendor detail, but they cannot inspect Anthropic's remote Cowork sandbox or reconstruct an unlogged OpenAI Work tool call. For regulated data, treat a missing required evidence path as a rollout blocker. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports investigation evidence and proof of deployer controls. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports monitoring, investigation, audit evidence, and incident reporting. | | G.4 Colorado AI Act and the US state patchwork | Conditional: for covered Colorado ADMT, this supports version, decision, complaint, and retention evidence. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Monitoring 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 audit-ready evidence paths and traceability. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA audit controls, activity review, and investigation evidence. | *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 * [6. Observability, Audit & Evidence](/handbook/6.-observability-audit-and-evidence) * [6.1 The audit gap: what you can and can't see](/handbook/6.-observability-audit-and-evidence/6.1-the-audit-gap-what-you-can-and-cant-see) * [6.5 Routing AI telemetry to your SIEM](/handbook/6.-observability-audit-and-evidence/6.5-routing-ai-telemetry-to-your-siem) * [5.6 Incident response for AI system](/handbook/5.-threats-and-adversarial/5.6-incident-response-for-ai-system) * [4.6 Cross-app data flow and live artifacts](/handbook/4.-data-protection-and-residency/4.6-cross-app-data-flow-and-live-artifacts) # 6.7 Continuous review cadence The monthly, weekly, and quarterly rhythm that keeps AI security controls from drifting as tools and capabilities evolve. *Last reviewed: August 18, 2026* {% hint style="info" %} AI controls drift because vendors ship quickly and users find new paths. A review cadence keeps policy close to reality. {% endhint %} ## Continuous review cadence: what security teams need to know AI security is not a one-time rollout task. New models, connectors, agent modes, browser features, data controls, and audit endpoints can change the risk of an approved workflow — and vendors also retire surfaces, which can invalidate policies and pilots built on them. Cadence gives teams a rhythm: weekly alerts, monthly analytics, quarterly access and red-team reviews, and immediate review after incidents or major releases. ## Common continuous review cadence security failures * Controls are reviewed only during annual audit. * Vendor releases add features that bypass old policy assumptions. * Exceptions never expire. * Usage shifts to a new surface without owner review. * Red-team findings are not retested. ## Continuous review cadence security controls checklist * Review SIEM alerts weekly for high-risk surfaces. * Review usage, spend, and adoption monthly. * Review high-risk roles, connectors, MCP servers, plugins, and exceptions quarterly. * Retest red-team findings after fixes. * Trigger review after incidents, vendor releases, deprecation announcements, new data classes, and new write actions. ## Anthropic ### Overview Anthropic continuous review should revisit custom roles, connector permissions, Claude Code managed settings, MCP allowlists, plugin, skill and hook inventories, Managed Agent definitions, scheduled deployments, Cowork execution modes, Office add-ins, data retention, and monitoring coverage. Unattended automation deserves its own review line. Cowork scheduled tasks run remotely by default, but tasks that need local folders or desktop applications run locally and require the desktop to remain available. Team and Enterprise admins control scheduled tasks through the Cowork admin toggle. Re-review when a new Claude surface, connector, or automation path enters production. Cowork now spans web, desktop, and mobile, with remote sessions that follow the user across devices and local capabilities that still depend on desktop. Review telemetry whenever that boundary changes. Cowork and Claude's Office agents currently sit outside the Compliance API and data exports, so any logging change should trigger an evidence-map review. Add Claude Tag to the cadence: review connected Slack workspaces, member restrictions, allowed channels and DMs, service accounts, Access-bundle inheritance, domains, repositories, saved memory, spend limits, routines, and optional network-event exports. Re-run the review when a channel changes audience or classification, because the same shared credentials become available to every member in scope. ### Anthropic documentation * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Scheduled deployments](https://platform.claude.com/docs/en/managed-agents/scheduled-deployments) * [Schedule recurring tasks in Claude Cowork](https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [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) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) * [Review what Claude Tag has done](https://claude.com/docs/claude-tag/admins/audit) * [Set up Claude Tag routines](https://claude.com/docs/claude-tag/users/proactivity) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI's July 2026 release changed the control map at once. ChatGPT Desktop (Work / Codex) combines Chat, Work, and Codex, and existing Codex desktop installations update into it. The App Directory became the Plugin Directory, and plugins can package skills, apps, and app templates. ChatGPT Atlas is scheduled to retire on August 9, 2026. Each change warrants a policy, deployment, support, and evidence review. Recurring review should cover ChatGPT RBAC and action controls, Work web and mobile permissions, local Codex clients and managed desktop configuration, plugins and connected apps, Sites publishing, Computer Use, governance exports, and scheduled tasks. OpenAI documents web and mobile Work as a cloud surface and desktop Work as a local-capable surface. Review both control planes, and re-review when users move among Chat, Work, Codex, the API Platform, and external applications. ### OpenAI documentation * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [Apps in ChatGPT](https://help.openai.com/en/articles/11487775-apps-in-chatgpt) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Scheduled tasks](https://learn.chatgpt.com/docs/automations) * [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) * [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) ### Applicable Harmonic guides for OpenAI * [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) ## Frequently asked questions about continuous review cadence ### How often should AI controls be reviewed? Use weekly alert review, monthly usage review, quarterly access and extension review, and event-driven review after incidents or major vendor changes. The event-driven trigger matters most in practice, because vendor deprecations and renames arrive on the vendor's calendar, not yours. ### What should be reviewed monthly? Review usage, spend, new surfaces, adoption shifts, and policy exceptions. Monthly review is where surface drift shows up first — usage moving from chat to coding agents, API keys, or scheduled automations — while the shift is still small enough to govern. ### What should be reviewed quarterly? Review roles, connectors, MCP servers, plugins, skills, red-team results, and high-risk workflows. Include unattended automation inventories such as scheduled agent deployments, Cowork scheduled tasks, and ChatGPT scheduled tasks. Check whether each runs remotely or needs a local desktop, and whether its owner and permissions are still valid. ### What triggers an out-of-cycle review? Incidents, vendor releases, deprecation announcements, new data classes, new write actions, new connectors, and audit gaps. The July 2026 ChatGPT desktop consolidation changed installation, local access, plugin packaging, and product naming together. Atlas retirement on August 9, 2026 adds a dated migration trigger. Anthropic's expansion of Cowork across web, desktop, and mobile similarly changes where work runs and where evidence lives. ### Who owns the cadence? Security should own the rhythm: the calendar, the trigger list, and the escalation path when a review finds drift. Platform, identity, compliance, and business owners own their control evidence, because they are the ones who can actually re-verify a role grant or a connector scope. ## 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.2 EU AI Act obligations for deployers | Conditional: for an in-scope high-risk system, this supports ongoing monitoring and reassessment after material change. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports monitoring, investigation, audit evidence, and incident reporting. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Monitoring 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 periodic review, corrective action, and continual improvement. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA audit controls, activity review, and investigation evidence. | *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 * [6. Observability, Audit & Evidence](/handbook/6.-observability-audit-and-evidence) * [6.4 Analytics and usage APIs](/handbook/6.-observability-audit-and-evidence/6.4-analytics-and-usage-apis) * [7.2 Pilot design and success metrics](/handbook/7.-rollout-and-operations/7.2-pilot-design-and-success-metrics) * [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security) * [7.1 Roll out by risk: the phased plan](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan) # 7. Rollout & Operations How to deploy AI tools safely by risk phase, design pilots, measure adoption and control effectiveness, and maintain AI governance over time. *Last reviewed: August 18, 2026* {% hint style="info" %} How you deploy AI tools determines whether your controls actually apply to real users or only to a pilot group you forgot to widen. This section covers phased rollout, pilot design, evidence-backed approval, operational ownership, and safe exit when a tool, vendor, or workflow is retired. {% endhint %} ## Articles in this section 1. [7.1 Roll out by risk: the phased plan](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan) 2. [7.2 Pilot design and success metrics](/handbook/7.-rollout-and-operations/7.2-pilot-design-and-success-metrics) 3. [7.3 The security team checklist](/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist) 4. [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) ## Frequently asked questions **What is the right order to deploy AI security controls?**\ Start with an inventory, an owner, a risk classification, and a managed-identity baseline. Configure data, tool, runtime, and logging controls before enabling high-risk capabilities, then pilot with a limited cohort and expand only after the evidence meets defined criteria. SSO and SCIM are important for managed seats, but they do not govern personal accounts, API keys, or every local agent. Pair identity controls with tenant, browser, endpoint, and developer controls, and do not leave observability until the end. **How do I know my AI security controls are actually working?**\ Use representative accounts, roles, devices, and product surfaces. Test both allowed and denied paths, including sign-in, paste or upload, tool calls, network access, approval prompts, log generation, and revocation. Record the expected and actual result for each test and require that evidence for the go or no-go decision. A control is not fully deployed until you have seen it apply to the intended identity and confirmed that the event reaches the expected investigation path. **How often should we review our AI security controls?**\ Use a risk-based cadence. Triage high-confidence alerts continuously or weekly, and review usage, access, and policy drift monthly. Revisit permissions, integrations, the threat model, and incident evidence at least quarterly for high-risk deployments. Red-team agent and tool paths before launch and again when material capabilities change. Trigger an out-of-cycle review after a major product release, new connector, model or tool enablement, control failure, or security incident. **What should an AI exit plan cover?**\ Define how to disable access, stop active work, revoke identities and connectors, transfer ownership, export required records, delete provider and downstream data, remove published artifacts, preserve investigation evidence, and confirm that billing and unattended tasks have ended. Test the disable path before production, not only during offboarding. ## Related handbook guidance * [AI Security Handbook](/) * [Security Team Checklist](/start-here/security-team-checklist) * [Governance & Frameworks](/reference/governance-and-frameworks) * [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence) # 7.1 Roll out by risk: the phased plan Four phases from inventory and ownership through pilot, controlled expansion, and steady-state operations — the sequence that avoids governance gaps. *Last reviewed: August 18, 2026* {% hint style="info" %} Do not start with a feature tour. Start with inventory, owners, pilot controls, evidence, and clear gates for wider rollout. {% endhint %} ## What security teams need to know about roll out by risk: the phased plan AI rollout works best in phases. Phase 0 inventories tools and owners. Phase 1 pilots with narrow groups and data classes. Phase 2 expands by use case. Phase 3 moves into steady operations. The point of phases is evidence. Before widening, prove that identity, DLP, connector, runtime, and audit controls work for a real user doing real work. Phasing is also how NIST AI RMF governance becomes operational: each gate assigns ownership and oversight before autonomy and data exposure widen. ## Phases and gates Each phase has an objective, entry criteria, exit evidence, and an owner. Exit evidence is the gate: the rollout does not advance until the evidence exists and has been reviewed. **Phase 0: Inventory and baseline** * Objective: know every AI tool, account path, owner, and data class in scope before anything new is enabled. * Entry criteria: executive sponsor named; a single accountable rollout owner assigned. * Exit evidence: tool and owner inventory published; SSO enforced for every approved surface with password login disabled (see 1.1, SSO and SCIM for AI platforms); shadow accounts identified and queued for remediation (see 1.4, Shadow account remediation and managed-account consolidation). * Owner: security lead, with identity and IT asset owners contributing. **Phase 1: Controlled pilot** * Objective: prove that controls and evidence paths work for a small cohort doing real work. * Entry criteria: pilot cohort, use cases, data classes, and blocked uses defined; go/no-go criteria agreed before launch (see 7.2, Pilot design and success metrics). * Exit evidence: DLP alerts generated and triaged during the pilot (see 4.1, DLP for GenAI); every enabled connector has a logged approval in the intake register (see 2.7, The supply-chain review workflow); audit records reconciled against the pilot roster (see 6.1, The audit gap, and 6.3, Compliance APIs by platform). * Owner: security lead, with the pilot business owner and support lead contributing. **Phase 2: Expansion by use case** * Objective: widen access group by group and use case by use case, not by enthusiasm. * Entry criteria: pilot gate passed; support and incident paths staffed (see 5.6, Incident response for AI systems); pilot exceptions closed or given owners and expiry dates. * Exit evidence: each new group passes the same identity, data, runtime, and audit checks as the pilot (see 7.3, The security team checklist); telemetry from newly enabled surfaces lands in the SIEM (see 6.5, Routing AI telemetry to your SIEM). * Owner: platform or IT owner for enablement, with security signing each gate. **Phase 3: Steady-state operations** * Objective: run AI surfaces as a normal operational service with owners and cadence. * Entry criteria: expansion complete for the approved scope; review cadence and owners assigned (see 6.7, Continuous review cadence). * Exit evidence: first quarterly access and usage review completed; unattended and scheduled agent runs have named owners, scoped credentials, and log review (see 3.6, Scheduled and background tasks). * Owner: security operations, with platform and compliance contributing. Two gate rules apply across all phases. First, regulated data classes need their own gate: hold regulated data off any surface whose retention posture is not proven for that class (see 4.4, Retention and Zero Data Retention). Vendor example (Anthropic): Claude Managed Agents is in beta, and its sessions persist state server-side and are not currently eligible for zero data retention or HIPAA BAA coverage, so a phase gate should keep regulated data classes off Managed Agents until that eligibility changes. Second, an exception is a gate outcome, not a workaround: every exception needs an owner and an expiry date. ## Common roll out by risk: the phased plan security failures * The rollout starts with broad enablement and retrofits controls later. * A pilot succeeds on productivity but fails on evidence. * User groups expand before support and incident paths are ready. * Exceptions become permanent access. * The operating cadence is not assigned to owners. ## Roll out by risk: the phased plan security controls checklist * Run Phase 0 inventory before enabling new products, surfaces, or execution paths. * Pilot with known users, data classes, workflows, owners, and prohibited uses. * Define go, hold, and stop gates for identity, data, supply chain, runtime, threats, evidence, and support. * Train pilot users on allowed data, approvals, connectors, incident reporting, and output review. * Measure control effectiveness, audit completeness, support load, cost, incidents, and exceptions. * Expand by group and use case, not by enthusiasm. * Assign steady-state owners, review cadence, support, incident response, and budget before expansion. * Maintain a tested rollback and exit plan for every production deployment. ## Exit and rollback gate Before production, document how the organization will: * disable new access and stop active, scheduled, remote, and queued work; * revoke users, agent identities, API keys, service accounts, OAuth grants, and connectors; * transfer or retire agent, project, repository, skill, plugin, and artifact ownership; * export records needed for legal, audit, investigation, and business continuity; * delete prompts, files, memory, knowledge sources, indexes, caches, generated artifacts, and downstream copies; * remove public links, published sites, messages, code changes, and application integrations; * verify that billing, credits, webhooks, schedules, and background tasks have ended; and * restore the previous approved tool, model, configuration, or workflow. Exercise the disable and revocation path during the pilot. A contract termination checklist is not a technical exit test. ## Anthropic ### Overview Anthropic rollout gates map onto Enterprise controls, but Cowork needs separate gates for remote and local execution. Remote sessions run in Anthropic-managed sandboxes and can follow a user across web, desktop, and mobile. Local folders, applications, browser use, and computer use depend on the desktop and its endpoint controls. Custom roles can scope the pilot cohort, while connector permissions and Claude Code managed settings control integrations and coding-agent behavior. Gate Cowork observability before expansion. Anthropic excludes Cowork from audit logs, the Compliance API, and data exports, so a Team or Enterprise pilot should prove OpenTelemetry collection and downstream-log correlation. Gate Managed Agents separately because the product is in beta and its sessions are not currently eligible for zero data retention or HIPAA BAA coverage. Scheduled deployments and Cowork scheduled tasks belong in Phase 3 with named owners, scoped credentials, and log review. Roll Claude Tag out as a shared service identity, not as an ordinary Slack bot. Start in a private channel with the member restriction enabled, one low-risk Access bundle, narrow domains, dedicated service accounts, spend limits, and tested audit correlation. Add broader channels, write-capable connections, repositories, and routines only after the previous phase has an owner and evidence path. ### 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-claude-s-capabilities) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Scheduled deployments](https://platform.claude.com/docs/en/managed-agents/scheduled-deployments) * [Use Claude Cowork on web, desktop, and mobile](https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile) * [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) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) * [Review what Claude Tag has done](https://claude.com/docs/claude-tag/admins/audit) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI rollout gates split across ChatGPT workspace policy, Work cloud controls, local Codex managed configuration, and API organization settings. ChatGPT Desktop (Work / Codex) presents Chat, Work, and Codex together, but the control planes do not collapse with the interface. Web and mobile Work use workspace controls and cloud execution. Desktop Work and Codex can act on local files and applications under local Codex permissions and managed configuration. Pilot them separately. RBAC and app action controls can stage access by cohort. The Plugin Directory now covers plugins that may package skills, apps, and app templates, so plugin review belongs in the supply-chain gate. For exit evidence, verify known gaps rather than assuming a successful message export proves complete visibility. OpenAI's Compliance API covers messages and responses across Chat, Work, and Codex, but not Work files, actions, or tool calls. API-key-authenticated Codex automation also needs its own evidence path. ### 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) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) * [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) ### Applicable Harmonic guides for OpenAI * [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) ## Frequently asked questions about roll out by risk: the phased plan ### What is a risk-based AI rollout? A risk-based rollout expands AI access only after controls and evidence are proven for each use case and data class. Instead of enabling a platform for everyone at once, it moves through phases: inventory, pilot, expansion, and operations, with a gate between each. The gate is evidence, not opinion: identity, data, runtime, and audit controls must be shown working for real users before the next group is enabled. ### What should Phase 0 include? Phase 0 is inventory and baseline. List every AI tool in use or requested, the account paths people use to reach them, the owners, the data classes involved, the connectors already enabled, and the audit sources available. It should also close the identity basics: SSO enforced, shadow accounts found, and a single accountable rollout owner named (see 1.1 and 1.4). ### What makes a good pilot gate? A good gate is a short list of verifiable checks, each backed by evidence. For example: SSO enforced for the pilot cohort, DLP alerts generated and triaged during the pilot, every connector approval logged in the intake register, and audit records reconciled against the pilot roster. If a check cannot produce evidence, the gate fails, and that is the gate doing its job. ### When should rollout stop? Stop expanding when a control fails for the next group: identity gaps, untriaged DLP alerts, connectors enabled without approval, runtime approvals bypassed, or audit records that cannot be reconciled. Pause, fix, re-verify against the gate, then resume. A rollout that cannot stop is enablement, not governance. ### Who should own rollout? Name a single accountable owner, typically the CISO or the security lead who chairs the AI governance group, who owns the phase plan, the gates, and the decision to advance or stop. Identity, platform and IT, compliance, business owners, and support all contribute checks and evidence to each gate. Accountability itself should not be shared: diffuse ownership is how gates get skipped. ## 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.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies and GRC guidance. | | G.8 ISO/IEC 42001 AI management system | This article supports ISO/IEC 42001 AIMS preparation through risk-based implementation and governance gates. | *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) * [7.2 Pilot design and success metrics](/handbook/7.-rollout-and-operations/7.2-pilot-design-and-success-metrics) * [7.3 The security team checklist](/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) * [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security) # 7.2 Pilot design and success metrics What a good AI security pilot looks like, how to select cohorts, and how to know whether controls worked before widening rollout. *Last reviewed: August 18, 2026* {% hint style="info" %} A good pilot tests controls as well as usefulness. Measure productivity, policy fit, support load, and evidence quality before expansion. {% endhint %} ## What security teams need to know about pilot design and success metrics Pilots often measure whether users like the tool. That is useful, but security needs more. A pilot should test whether the approved workflows stay inside the intended controls. Choose users who represent the eventual rollout, but keep the first cohort small enough to support. Include at least one workflow that touches real operational constraints, such as connectors, code, or sensitive internal data. ## Common pilot design and success metrics security failures * The pilot cohort is too friendly to reveal misuse. * Success is measured only by user satisfaction. * No one checks whether DLP and audit logs captured the work. * Support tickets are ignored as rollout signals. * Go/no-go criteria are decided after the pilot ends. ## Pilot design and success metrics security controls checklist * Define pilot use cases, users, data classes, allowed actions, prohibited uses, and execution paths in advance. * Train users and publish a clear support and incident-reporting route. * Measure productivity, control hits, cost, support load, incidents, exceptions, telemetry quality, and audit completeness. * Test joiner, mover, leaver, device-loss, revocation, exception, stop, rollback, and exit paths. * Collect feedback on confusing approvals, blocked actions, output review, and workaround behavior. * Include skeptical and non-expert users, not only enthusiasts. * Set quantitative go, hold, and stop criteria before launch. * Assign owners for every defect and require closure or explicit risk acceptance before expansion. ## Pilot metrics Agree a small set of metrics before launch. Each metric needs a definition, a data source, and a go/no-go threshold. The data sources map to the observability pages: compliance APIs (see 6.3, Compliance APIs by platform), analytics and usage APIs (see 6.4, Analytics and usage APIs), and SIEM routing (see 6.5, Routing AI telemetry to your SIEM). Where runtime tools emit OpenTelemetry signals, route them through your collector so denials and usage land beside the rest of the telemetry. | Metric | Definition | Data source | Example go/no-go threshold | | -------------------------------- | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Active adoption | Share of the pilot cohort using the tool in a given week | Workspace analytics and usage APIs (see 6.4) | At least 60% weekly active by week 4, or the cohort was wrong | | Blocked sensitive prompts | DLP alerts raised on pilot traffic | DLP alerts routed to the SIEM (see 6.5; 4.1, DLP for GenAI) | 100% of alerts triaged within 2 business days; repeat-offender rate falling | | Denied tool and permission calls | Approval or permission denials in agent runtimes | Runtime telemetry and logs in the SIEM (see 6.5) | Every denial reviewed; no unexplained week-over-week spike | | Connector approval coverage | Share of connectors and apps in use that have a logged intake approval | Intake register reconciled against compliance API records (see 6.3; 2.7, The supply-chain review workflow) | 100%; any unapproved connector in use is a no-go | | Evidence coverage | Share of planned event types with a tested evidence path, including documented gaps | Compliance API, OpenTelemetry, endpoint, app, and target-system records reconciled against scripted pilot actions (see 6.3 and 6.6) | 100% of required event types either captured and attributable or blocked from production | | Support load | Tickets per pilot user per week | Ticket queue tagged for the pilot | Falling trend by week 3; no unresolved control-confusion themes | | Incidents and exceptions | Security incidents and policy exceptions opened during the pilot | IR tracker and exception register (see 5.6, Incident response for AI systems) | Zero unresolved high-severity incidents; every exception has an owner and expiry date | | Telemetry delivery | Required event types arrive within the defined latency and completeness objective | Source-to-collector-to-SIEM reconciliation (see 6.2 and 6.6) | No missing high-value events; unexplained loss or attribution failure is a no-go | | Exit readiness | Active work, identities, connections, artifacts, and data can be stopped or removed | Technical exit exercise and deletion evidence (see 7.1 and 5.6) | Stop and revocation complete within the agreed objective; known exceptions accepted | | User readiness | Users understand permitted data, approvals, output review, and incident reporting | Training completion plus scenario check | Required cohort completes training and passes the scenario check | | Output quality | Sampled task outputs reviewed against acceptance criteria you define | Your own evaluation harness plus reviewer sampling | Acceptance rate meets the bar agreed before launch | Build quality measurement on your own evaluation harness rather than a vendor-hosted one. Vendor note (OpenAI): OpenAI documents its hosted Evals platform as deprecated, with the platform going read-only on October 31, 2026, so a 2026 pilot should not build its quality gate on it. ## Anthropic ### Overview Anthropic pilots need a surface-specific instrument panel. Claude Code analytics dashboards provide adoption and contribution measures, while Claude Code monitoring provides runtime telemetry. Cowork requires a separate OpenTelemetry test because Anthropic does not include Cowork activity in audit logs, the Compliance API, or data exports. Script remote and local Cowork actions, then confirm that prompts, tool calls, file access, approvals, and downstream changes can be reconstructed without relying on endpoint tools to inspect the remote sandbox. Scope the cohort with identity. Assign the pilot population a group whose custom role enables only the surfaces under test, whether that is chat, Claude Code, Cowork, Office add-ins, or connectors. If the pilot uses Zero Data Retention, use a productivity measure other than Claude Code contribution metrics, which are unavailable under ZDR. For a Claude Tag pilot, measure active channels, requesters, task completion, per-channel spend, routines created, blocked requests, and connected-system actions. Validate that the Slack thread, Audit view, optional network events, and service-account logs can reconstruct representative tasks. Claude Tag retains memory and transcripts and is unavailable under ZDR, so it needs its own eligibility check rather than inheriting the Claude Code pilot decision. ### Anthropic documentation * [Track team usage with analytics](https://code.claude.com/docs/en/analytics) * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [Monitor Claude Cowork activity with OpenTelemetry](https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [What is Claude Tag?](https://support.claude.com/en/articles/15594475-what-is-claude-tag) * [Review what Claude Tag has done](https://claude.com/docs/claude-tag/admins/audit) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI pilots should separate Chat, Work cloud, desktop Work, local Codex clients, and API-key automation. ChatGPT Desktop (Work / Codex) puts Chat, Work, and Codex in one interface, but web and mobile Work run in OpenAI's cloud while desktop Work can use local files and applications. OpenAI's Compliance API covers messages and responses across Chat, Work, and Codex, but not Work files, actions, or tool calls. Script those events and prove the endpoint, plugin, connected-app, and target-system evidence paths. Codex Enterprise adds analytics dashboards, an Analytics API, and a Compliance API for ChatGPT-authenticated activity. API-key-authenticated automation still needs API organization records and endpoint evidence. Keep Chat convenience metrics separate from Work, Codex, and API autonomy metrics. For output quality, use your own evaluation harness because the hosted Evals platform is deprecated. ### OpenAI documentation * [Compliance APIs for Enterprise Customers](https://help.openai.com/en/articles/9261474-compliance-apis-for-enterprise-customers) * [Codex governance](https://developers.openai.com/codex/enterprise/governance) * [ChatGPT Work and Codex](https://help.openai.com/en/articles/20001275) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [Working with evals](https://developers.openai.com/api/docs/guides/evals) — deprecated; OpenAI is retiring the hosted Evals platform, so treat this page as transition-period reference only ### Applicable Harmonic guides for OpenAI * [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) ## Frequently asked questions about pilot design and success metrics ### What should an AI pilot measure? Measure six things: productivity and adoption, control effectiveness such as DLP hits and denied calls, connector approval coverage, support load, audit completeness, and incidents or exceptions. Define each metric and its threshold before launch, because criteria decided after the pilot ends always pass. The Pilot metrics table above is a starting set to adapt. ### Who should be in the pilot? Choose users from the real target groups, across different job functions, risk levels, and technical comfort. Avoid a cohort made only of enthusiasts: friendly pilots hide misuse, confusing approvals, and workaround behavior that will surface at scale. Include at least one user whose workflow touches a sensitive data class, so the DLP and approval paths actually get exercised. ### How long should a pilot run? Run long enough to see repeat work, edge cases, and one full operational cycle — typically several weeks for workforce tools. A useful endpoint test: the pilot has covered at least one joiner-mover-leaver cycle, one access review, and one exercised incident-response path. If none of those happened, the pilot measured enthusiasm, not operations. ### What are guardrail metrics? Guardrail metrics show whether controls worked, as distinct from whether users were productive. Examples: blocked sensitive prompts triaged, denied tool calls reviewed, connector approvals logged, and audit records complete for the cohort. A pilot that reports only satisfaction and time saved has not tested security. ### What should block expansion? Block expansion if controls fail for the pilot cohort, support volume is unmanageable, audit logs are incomplete or cannot be attributed, or users rely on prohibited workarounds to get work done. Workarounds are the strongest signal: they mean the approved path does not fit the workflow, and scaling the rollout will scale the workaround with it. ## 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.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies and GRC guidance. | | G.8 ISO/IEC 42001 AI management system | This article supports ISO/IEC 42001 AIMS preparation through objectives, validation criteria, and measurement during controlled deployment. | *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) * [7.1 Roll out by risk: the phased plan](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan) * [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence) * [5.5 Red-teaming AI systems](/handbook/5.-threats-and-adversarial/5.5-red-teaming-ai-systems) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) # 7.3 The security team checklist A keep-it-by-your-desk checklist across identity, runtime, browser, desktop, supply chain, cloud, data, and audit controls. {% hint style="info" %} Use this checklist at intake, the pilot gate, expansion approval, and recertification. A control passes only when it has a named owner, reproducible evidence, and a current test date. {% endhint %} *Last reviewed: August 18, 2026* ## What security teams need to know about the AI security checklist This is the evidence-backed version of the launch checklist. Adapt the required rows to the deployment model, data class, and risk tier in [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix). A skipped row needs a documented rationale. An exception needs an owner and expiry date. Run the checklist again after an incident, a material vendor or architecture change, a new data class, a change in ownership, or an expansion in autonomy. ## AI security checklist evidence record Keep these fields with every control decision: | Field | Required entry | | -------------- | ----------------------------------------------------------------------------------------------- | | Applies? | Yes or no, with a reason when the control does not apply | | Status | Pass, fail, exception, or not tested | | Owner | One accountable person or function | | Evidence | Link to an export, policy, log sample, test result, contract term, or other reproducible record | | Last tested | Date the control was last verified, not only configured | | Exception | Risk owner, compensating controls, approval, and expiry date | | Review trigger | Next scheduled review and any event that forces an earlier review | ## Common AI security checklist failures * The checklist is completed once and never recertified. * Rows are marked as passed without evidence or a recent test. * Chat, coding agents, desktop agents, hosted agents, and API applications are assessed as if they have the same control plane. * A provider-wide setting is assumed to cover every surface and authentication path. * Exceptions have no accountable owner or expiry date. * Incident responders cannot revoke the agent, connector, credential, task, and published output separately. ## AI security controls checklist ### Governance & rollout | Check | Typical owner | Minimum evidence | Handbook | | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | -------------------------------------------- | -------- | | Every AI product, surface, deployment model, authentication path, and environment is in the inventory | AI governance lead | Inventory export or register | 7.1, 7.4 | | Each entry records a business owner, technical owner, risk tier, permitted data classes, and deployment model | AI governance lead | Completed inventory fields | 7.1, 7.4 | | Approved and prohibited uses are documented by cohort, surface, data class, and action type | Security + legal | Approved-use standard and user communication | 7.1 | | The pilot gate verifies the required controls and records a go, hold, or stop decision | Security lead | Pilot test record and sign-off | 7.2 | | Expansion requires evidence that pilot defects are closed or accepted | Security lead + business owner | Remediation tracker and expansion approval | 7.2 | | Security, identity, endpoint, data, platform, legal, procurement, and incident-response responsibilities are assigned | AI governance lead | Current RACI | 7.1, 7.3 | | Exceptions record a risk owner, compensating controls, approval, and expiry date | Security lead | Exception register | 7.3 | | User training covers permitted data, approvals, connectors, output review, and incident reporting before access is granted | AI governance lead + security | Training record and scenario check | 7.1, 7.2 | | A tested exit plan covers stopping work, revoking access, ownership transfer, export, deletion, artifacts, schedules, and billing | AI governance lead + platform | Exit exercise and deletion evidence | 7.1, 5.6 | | Controls are recertified at least quarterly and after incidents, major vendor changes, new data classes, autonomy changes, or ownership changes | Control owners | Review calendar and completed review records | 6.7 | ### Identity | Check | Typical owner | Minimum evidence | Handbook | | --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- | -------------------------------------------------- | -------- | | Managed user surfaces use SSO where supported; unsupported login paths and exceptions are recorded | Identity lead | IdP configuration and authentication test | 1.1 | | SCIM or a documented joiner, mover, and leaver process removes access within the agreed service level | Identity lead | Provisioning configuration and deprovisioning test | 1.1 | | Roles or groups restrict high-risk capabilities such as code execution, agents, connectors, browser use, publishing, and administration | Identity lead + security | Role export and sampled entitlement review | 1.2 | | Personal-account use is blocked where tenant restrictions are supported; other surfaces have a tested detection and remediation path | IT + network security | Restriction configuration or detection test | 1.3 | | Shadow accounts, unmanaged organizations, and accounts on verified domains are discovered and consolidated or removed | Identity lead | Discovery results and remediation log | 1.4 | | Agents and other non-human identities have dedicated identities, named owners, narrow scopes, and revocation paths | Platform engineering | Non-human identity inventory and revocation test | 1.5 | | API keys, service accounts, workspace tokens, and project credentials are inventoried, vaulted, scoped, and rotated | Platform engineering | Credential inventory and rotation record | 1.6 | | Human approval is required before autonomous systems perform actions outside the approved baseline | Security + business owner | Approval policy and sampled allow or denial events | 1.7 | ### Supply chain & extensibility | Check | Typical owner | Minimum evidence | Handbook | | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------- | -------------------------------------------------------- | -------- | | Every enabled connector or app has an intake approval recording owner, scopes, data classes, actions, and connected system | Security + app owner | Intake register entry and scope export | 2.1, 2.7 | | Local and remote MCP servers are inventoried, authenticated where applicable, and reviewed before enablement | Platform engineering | Server inventory and assessment | 2.2 | | An MCP gateway or equivalent managed restrictions enforce the approved server and tool policy | Platform engineering | Gateway or managed-policy export and blocked-server test | 2.3 | | Skills and instruction bundles are reviewed for hidden instructions, tool use, data access, and update behavior | Security | Review record with content hash or version | 2.4 | | Plugins, marketplaces, and extensions are restricted to approved sources and reviewed after material updates | Security + endpoint | Allowlist and versioned review record | 2.5 | | Hooks and lifecycle scripts are inventoried; untrusted, unsigned, or unowned scripts are blocked | Platform engineering | Hook inventory and execution-policy test | 2.6 | | The supply-chain register records the owner, source, version, permissions, review date, and next review trigger | Security | Complete supply-chain register | 2.7 | | Signed packages, trusted distribution channels, version pinning, and update behavior are verified where supported | Endpoint + platform engineering | Signature or provenance check and update test | 2.8 | | SaaS agent builders are reviewed for templates, connections, collaboration, publishing, and agent transfer or deletion | Security + app owner | Builder configuration and publishing test | 2.9 | | Hosted-agent frameworks, SDKs, models, tools, containers, and other dependencies have owners and an advisory and update process | Platform engineering | Dependency inventory and update record | 2.10 | ### Runtime, sandbox & autonomy | Check | Typical owner | Minimum evidence | Handbook | | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------- | ------------------------------------------------------ | -------- | | The isolation model is documented for each local and hosted execution path | Platform engineering | Architecture note and configuration export | 3.1 | | Coding-agent sandbox and approval settings are centrally enforced where the provider supports managed configuration | Platform engineering | Managed configuration and sampled client check | 3.1, 3.2 | | Writes, commands, network actions, credential use, and other high-impact actions require approval beyond the approved baseline | Security | Approval policy and allow or denial events | 1.7, 3.2 | | Network egress is denied or restricted by default according to risk, and allowed destinations are owned and tested | Network security | Egress policy and test result | 3.3 | | Browser and internet access are enabled only for approved cohorts and sensitive internal sites have additional protection | Security + endpoint | Role policy, site controls, and blocked-site test | 3.4 | | Computer-use and desktop-control capabilities are disabled unless required; enabled workflows have action boundaries and endpoint controls | Security + endpoint | Capability policy and action test | 3.5 | | Scheduled and background tasks have narrow identities, bounded runtime, rate and spend limits, stop conditions, and reviewable outputs | Platform engineering | Task configuration and stop-control test | 3.6 | | Remote dispatch, mobile triggers, remote sessions, and SSH paths are authenticated, attributable to an initiator, and revocable | Platform engineering + identity | Authentication path, event sample, and revocation test | 3.7 | | Local filesystem access is limited to approved roots; sensitive, home, credential, and cloud-synced paths are denied unless required | Endpoint + security | Path policy and denied-access test | 3.8 | | Hosted triggers are authenticated and protected against replay; the control plane is outside the agent's writable runtime | Platform engineering | Trigger tests and architecture evidence | 3.9 | | Hosted agents use task-scoped, short-lived credentials issued through a broker or vault where feasible | Platform engineering + identity | Credential policy and active-run revocation test | 3.9, 4.7 | | Hosted-agent workloads isolate tenants and tasks, use managed secrets, restrict egress, and limit spend, rate, duration, and actions | Platform engineering | Runtime configuration and boundary tests | 3.9 | | Hosted tasks have a tested kill switch that stops work and revokes active credentials, sessions, and downstream access | Platform engineering + IR | Kill-switch exercise record | 3.9, 5.6 | ### Data protection & residency | Check | Typical owner | Minimum evidence | Handbook | | ------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | ---------------------------------------------------- | -------- | | Every approved surface has a tested DLP enforcement or evidence path; exclusions and unsupported paths are documented | Data protection | Test prompts, alerts, and coverage matrix | 4.1 | | Data classes are mapped to allowed products, surfaces, connectors, actions, and deployment models | Data protection | Class-to-tool matrix | 4.2 | | Processing, storage, support, log, backup, and subprocessor regions are verified for each surface and plan | Compliance + privacy | Contract terms, settings, and regional test evidence | 4.3 | | Retention is configured per surface; regulated data is limited to surfaces with a proven retention posture | Compliance | Retention export and deletion test | 4.4 | | Zero Data Retention eligibility and exclusions are recorded by endpoint, feature, and session type | Compliance + platform engineering | Provider terms and endpoint configuration | 4.4 | | Training and data-use terms are confirmed for each product, plan, workspace, and authentication path | Compliance | Contract, admin setting, or provider term | 4.5 | | Knowledge bases, embeddings, vector stores, memory, fine-tuning and evaluation datasets, caches, backups, and exports have lifecycle owners | Data protection + platform | AI data-store inventory and lifecycle records | 4.4 | | Source permission changes and deletion requests propagate to retrieval indexes, generated artifacts, and downstream copies or gaps are documented | Data protection + app owner | Permission and deletion propagation tests | 4.4, 4.6 | | Cross-app transfers, generated files, live artifacts, links, publishing, and downstream sharing are in the data-flow review | Data protection + app owner | Data-flow diagram and sharing test | 4.6 | | Secrets and credentials are blocked or scrubbed from prompts, tool parameters, logs, traces, and agent configuration | Security engineering | Secret-scanning and redaction test results | 4.7 | ### Threats & incident response | Check | Typical owner | Minimum evidence | Handbook | | --------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------- | ----------------------------------------- | -------- | | Prompt-injection scenarios have been exercised against untrusted content and connected tools | Security testing | Test report and remediation record | 5.1 | | Exfiltration through connectors, tools, files, URLs, browser actions, and generated artifacts has been tested | Security testing + data protection | Exfiltration test report | 5.2 | | Vulnerabilities and supply-chain advisories for enabled clients, SDKs, extensions, servers, and runtimes are tracked and remediated | Vulnerability management | Advisory and patch record | 5.3 | | Memory poisoning, data poisoning, spoofed tool results, SSRF, replay, approval races, and denial-of-wallet are covered in design review and testing | Security architecture + testing | Threat model and abuse-case tests | 5.4, 5.5 | | Tool poisoning, identity confusion, permission inheritance, and confused-deputy scenarios are covered in design review and testing | Security architecture | Design review and abuse-case tests | 5.4 | | High-risk workflows are red-teamed before expansion and after material changes | Security testing | Scoped red-team report | 5.5 | | The incident runbook covers revoking users, agent identities, connectors, credentials, remote tasks, sessions, and published artifacts | IR lead | Current runbook and containment checklist | 5.6 | | Incident responders have exercised the containment path and can identify required evidence by surface | IR lead + security operations | Tabletop or technical exercise record | 5.6, 6.6 | | Each material workflow has a current threat model covering data, identity, tools, runtime, users, outputs, and trust boundaries | Security architecture | Approved threat model | 5.7 | ### Observability, audit & evidence | Check | Typical owner | Minimum evidence | Handbook | | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | -------------------------------------------------- | -------- | | Audit coverage and known gaps are documented per product, surface, authentication path, and execution location | Security operations | Coverage matrix and tested event samples | 6.1 | | Telemetry uses a versioned schema with normalized timestamps, source identifiers, correlation IDs, model and policy versions, targets, and outcomes | Security operations + platform engineering | Schema and representative event samples | 6.2 | | Delivery latency, completeness, source health, sampling, clock drift, parser failures, and retention are measured and reconciled | Security operations | Telemetry SLO and reconciliation report | 6.2, 6.6 | | Agent telemetry records the required identifiers, actions, approvals, tool activity, outcomes, and errors | Security operations + platform engineering | Telemetry schema and event samples | 6.2 | | Prompt, response, and tool-content capture follows a documented content, redaction, access, and retention policy | Security operations + privacy | Collector configuration and redaction test | 6.2 | | All available audit and compliance sources are collected; coverage, retention, and exclusions are tested and recorded | Security operations | Collection configuration and reconciliation report | 6.3 | | Usage, adoption, model, token, task, and spend analytics are reviewed for anomalies and unowned activity | FinOps + security operations | Review report and follow-up record | 6.4 | | SIEM detections are selected from approved threat scenarios, tested with representative events, and linked to response runbooks | Security operations | Detection test and runbook link | 6.5 | | Every enabled surface has a tested evidence path for the investigation questions it must answer | Security operations + compliance | Scripted-action reconciliation report | 6.6 | | Review records show quarterly recertification and out-of-cycle reviews after defined trigger events | AI governance lead | Review history | 6.7 | ## Anthropic checklist implementation notes Inventory Anthropic surfaces separately: Claude Web, Claude Mobile, Claude Desktop (Chat / Cowork / Code), Claude Code, Claude Design, Claude in Chrome, Claude Tag, Claude for Microsoft 365, and the Anthropic API & Agent Platform. They can share an organization but differ in endpoint exposure, execution location, available controls, and evidence. Within Claude Desktop (Chat / Cowork / Code): * **Chat** uses the managed Claude workspace and connector policy, while the desktop installation adds endpoint, local file, local MCP, and extension considerations. * **Cowork** may run remote research tasks or use local folders, apps, browser actions, and computer use. Record the execution path for each approved workflow. Anthropic currently excludes Cowork and its Microsoft 365 add-ins from audit logs, the Compliance API, and data exports, so test the available OpenTelemetry feed and downstream application evidence before production. * **Code** brings the Claude Code agent into the desktop. Apply local repository, shell, filesystem, network, approval, and managed-settings controls in addition to desktop deployment controls. Claude Code also runs through the CLI, IDE integrations, and hosted or remote workflows where enabled. Treat each path separately: * **CLI and IDE:** local operating-system identity, repository trust, shell, filesystem, credentials, MCP servers, hooks, sandboxing, and egress are the primary boundaries. * **Desktop Code:** the same local agent risks apply, plus app deployment, updates, local extensions, and desktop permissions. * **Hosted or remote tasks:** review remote environment isolation, secrets, repository access, egress, retention, spend, task termination, and server-side logs. * **Remote dispatch:** preserve initiator attribution and test session and task revocation. Claude Design should appear in the product inventory when enabled, with its input assets, generated outputs, sharing behavior, retention, and audit evidence reviewed. Claude Tag belongs in the hosted-agent column, including Slack scope, service accounts, Access bundles, retained memory, spend limits, Agent Proxy egress, and evidence across Claude, Slack, and connected systems. Managed Agents belongs under the Anthropic API & Agent Platform; apply API project, SDK, dependency, hosted-runtime, retention, and observability controls rather than creating a separate workforce-app category. ### 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) * [Getting started with local MCP servers on Claude Desktop](https://support.claude.com/en/articles/10949351-getting-started-with-local-mcp-servers-on-claude-desktop) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Configure Claude Code permissions](https://code.claude.com/docs/en/permissions) * [Claude Code security](https://code.claude.com/docs/en/security) * [Claude Code data usage](https://code.claude.com/docs/en/data-usage) * [Claude Code monitoring](https://code.claude.com/docs/en/monitoring-usage) * [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) * [Configure OpenTelemetry for Claude's Office agents](https://support.claude.com/en/articles/14447276-configure-a-custom-opentelemetry-collector-for-office-agents) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [API and data retention](https://platform.claude.com/docs/en/manage-claude/api-and-data-retention) * [Restrict where Claude Tag operates](https://claude.com/docs/claude-tag/admins/restrict-access) * [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 checklist implementation notes Inventory OpenAI as ChatGPT Web, ChatGPT Mobile, ChatGPT Desktop (Work / Codex), Codex, and the OpenAI API Platform. Keep the ChatGPT workspace, local Codex clients, Codex cloud, and API organization or project controls separate even when the same person uses them. Within ChatGPT Desktop (Work / Codex): * **Work** is an agentic workspace that can research, create files and sites, use connected apps, and, where enabled, interact with the local computer. Review connected-app scopes, local permissions, browser or computer-use boundaries, generated artifacts, publishing, and the gap between message evidence and action evidence. * **Codex** runs coding-agent workflows from the desktop. Apply repository trust, sandbox, approvals, filesystem, network, MCP, plugin, hook, and managed-configuration controls. Codex also runs in the CLI, IDE extension, web or cloud tasks, and remote workflows: * **CLI and IDE:** local repository, shell, filesystem, credentials, MCP, hooks, sandbox, approvals, and egress are the main boundaries. * **Desktop Codex:** add desktop deployment, update, local application, plugin, and endpoint controls. * **Web or cloud tasks:** review environment isolation, repository access, cloud secrets, egress, retention, spend, task termination, and hosted evidence. * **Remote dispatch:** preserve initiator attribution and test task, session, and credential revocation. For the OpenAI API Platform, inventory organizations, projects, service accounts, API keys, model and tool access, data controls, rate and spend limits, and logs. Treat the Responses API and Agents SDK as application and hosted-agent components. Agent Builder is a low-code builder in transition and is scheduled for shutdown on November 30, 2026; new and migrated workflows need an owned target architecture and migration date. 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 does not appear in ChatGPT Compliance API exports. Keep a separate evidence row for each path. ### 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) * [Computer Use](https://learn.chatgpt.com/docs/computer-use) * [Chat and file retention policies in ChatGPT](https://help.openai.com/en/articles/8983778-chat-and-file-retention-policies-in-chatgpt) * [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) ## Frequently asked questions about the AI security checklist ### When should the checklist run? Run it at intake, the pilot gate, production expansion, and quarterly recertification. Run it earlier after incidents, material vendor or architecture changes, new data classes, autonomy changes, or ownership changes. ### Should every row be required? No. The deployment model, data class, and risk tier determine which rows apply. A skipped row needs a rationale. A required control that is not met needs a time-bounded exception or a rollout stop. ### What counts as evidence? Prefer reproducible evidence: configuration exports, policy files, event samples, reconciliation reports, contract terms, and test results. Screenshots and attestations are fallbacks when the provider offers no export, and they should be reviewed more often. ### Who maintains the checklist? One security owner should maintain the checklist structure. Identity, platform, endpoint, data, privacy, legal, procurement, incident response, and business owners remain accountable for the evidence in their domains. ## 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.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.8 ISO/IEC 42001 AI management system | This article supports ISO/IEC 42001 AIMS preparation through readiness evidence for operating the management system. | *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) * [7.1 Roll out by risk: the phased plan](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) * [G.6 Write an AI Acceptable Use Policy that holds up](/reference/governance-and-frameworks/g.6-write-an-ai-acceptable-use-policy-that-holds-up) * [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence) # 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). 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) * [7.3 The security team checklist](/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist) * [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) * [G.5 SANS Critical AI Security Guidelines mapping](/reference/governance-and-frameworks/g.5-sans-critical-ai-security-guidelines-mapping) * [1.2 RBAC across AI platforms](/handbook/1.-identity-and-access/1.2-rbac-across-ai-platforms) # Governance & Frameworks Frameworks, regulations, and program-level guidance for enterprise AI security - covering NIST AI RMF, NIST CSF 2.0, EU AI Act, DORA, ISO 42001, acceptable use policy, and ownership models. *Last reviewed: August 18, 2026* {% hint style="info" %} Effective AI governance ties policy to controls, owners, and evidence. Use this section to translate the handbook's technical controls into the frameworks used by auditors, regulators, legal teams, and executives. {% endhint %} The handbook tells security teams what to control across identity, supply chain, runtime, data, threats, observability, and rollout. These reference pages connect those controls to common frameworks, regulations, ownership models, and policy records. Start with G.1 if you need one crosswalk for the whole program. Start with G.6 and G.7 if the immediate problem is that employees are already using AI tools and nobody owns the rules. Start with G.2, G.3, G.4, or G.9 when legal or compliance is asking how a specific regulation affects AI deployment. ## Articles in this section 1. [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) 2. [G.2 EU AI Act obligations for deployers](/reference/governance-and-frameworks/g.2-eu-ai-act-obligations-for-deployers) 3. [G.3 DORA and AI resilience in financial services](/reference/governance-and-frameworks/g.3-dora-and-ai-resilience-in-financial-services) 4. [G.4 Colorado AI Act and the US state patchwork](/reference/governance-and-frameworks/g.4-colorado-ai-act-and-the-us-state-patchwork) 5. [G.5 SANS Critical AI Security Guidelines mapping](/reference/governance-and-frameworks/g.5-sans-critical-ai-security-guidelines-mapping) 6. [G.6 Write an AI Acceptable Use Policy that holds up](/reference/governance-and-frameworks/g.6-write-an-ai-acceptable-use-policy-that-holds-up) 7. [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security) 8. [G.8 ISO/IEC 42001 AI management system](/reference/governance-and-frameworks/g.8-iso-iec-42001-ai-management-system) 9. [G.9 HIPAA controls for AI systems handling PHI](/reference/governance-and-frameworks/g.9-hipaa-controls-for-ai-systems-handling-phi) ## How to use this section Use these pages as reference material, not legal advice. They help security teams prepare evidence and work with legal, compliance, privacy, procurement, and platform owners. Counsel should confirm scope, deadlines, and legal duties for each use case. For each AI workflow, keep four records: * Use case: what the AI system does, who uses it, and whose data or rights it may affect. * Control posture: which handbook controls apply and which exceptions were approved. * Owner: who is accountable for the system, the vendor, the data, and incident response. * Evidence: settings exports, logs, risk assessments, test results, approvals, and review dates. ## Frequently asked questions ### What is the difference between NIST AI RMF and NIST CSF 2.0 for AI security? NIST AI RMF is built for AI risk across the AI lifecycle. It gives teams a language for governance, context mapping, measurement, and risk management. NIST CSF 2.0 is the broader cybersecurity framework used to organize cyber risk outcomes across Govern, Identify, Protect, Detect, Respond, and Recover. Use AI RMF to describe the AI-specific risk program, then use CSF 2.0 to connect it to the rest of security reporting. ### Do deployers have obligations under the EU AI Act? Yes. Once the relevant high-risk provisions apply, deployers have duties around following instructions for use, assigning competent human oversight, monitoring operation, keeping relevant logs, escalating risks and serious incidents, and informing affected people when covered high-risk systems support decisions about them. Article 27 also requires a fundamental rights impact assessment for specified deployers and uses. ### Where should an AI governance program start? Start with ownership and inventory. Name the accountable business owner, security owner, data owner, platform owner, and incident-response owner for each approved AI surface. Then map each workflow to the control matrix and decide what evidence proves the controls are working. ### What is the fastest way to put an AI acceptable use policy in place? Use the G.6 template as a baseline, but do not stop at a policy document. Pair the policy with tenant restrictions, SSO, approved-tool lists, data handling rules, connector review, and a reporting path for incidents and exceptions. ### Which framework should we use if we only pick one? Start with NIST AI RMF when the goal is to organize AI risk across the lifecycle. Add NIST CSF 2.0 to connect cybersecurity controls to the wider security program. If the organization wants a certifiable management system, evaluate ISO/IEC 42001. ## Further reading The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page. * [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) * [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework) * [NIST AI RMF Generative AI Profile](https://doi.org/10.6028/NIST.AI.600-1) * [Regulation (EU) 2024/1689, Artificial Intelligence Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng) * [European Commission AI Act implementation overview](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) * [Regulation (EU) 2022/2554, Digital Operational Resilience Act](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) * [Colorado SB26-189, Automated Decision-Making Technology](https://leg.colorado.gov/bills/SB26-189) * [SANS Critical AI Security Guidelines](https://github.com/sans-community/ai-guidelines) * [HHS summary of the HIPAA Security Rule](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html) * [ISO/IEC 42001:2023](https://www.iso.org/standard/42001) ## Related handbook guidance * [AI Security Handbook](/) * [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) * [G.6 Write an AI Acceptable Use Policy that holds up](/reference/governance-and-frameworks/g.6-write-an-ai-acceptable-use-policy-that-holds-up) * [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) # G.1 Map your controls to NIST AI RMF and CSF 2.0 The backbone mapping every AI security control family to NIST AI RMF GOVERN, MAP, MEASURE, and MANAGE and NIST CSF 2.0 functions. *Last reviewed: August 18, 2026* {% hint style="info" %} Use NIST AI RMF to explain AI-specific risk work. Use NIST CSF 2.0 to connect that work to the rest of cybersecurity. The same evidence should support both. {% endhint %} NIST AI RMF and NIST CSF 2.0 answer different questions. NIST AI RMF organizes AI risk work into GOVERN, MAP, MEASURE, and MANAGE. It covers risks to individuals, organizations, and society, including model behavior, human oversight, transparency, bias, lifecycle decisions, and context-specific harms. NIST CSF 2.0 asks whether the organization is managing cybersecurity risk across Govern, Identify, Protect, Detect, Respond, and Recover. It is useful when the control is part of normal security operations: identity, asset inventory, logging, incident response, vendor risk, data protection, or resilience. For AI security, use them together. Connect AI governance to security operations without reducing the broader AI risk program to cybersecurity alone. ## The short mapping This is a practical emphasis map, not an official NIST crosswalk. Most control families support more functions and categories than the table shows. | Handbook domain | NIST AI RMF fit | NIST CSF 2.0 fit | Evidence to keep | | ---------------------------------- | -------------------- | ------------------------- | ----------------------------------------------------------------------------------- | | Identity and access | GOVERN, MANAGE | GOVERN, IDENTIFY, PROTECT | SSO settings, SCIM configuration, RBAC exports, owner list, access review records | | Supply chain and extensibility | MAP, MEASURE, MANAGE | GOVERN, IDENTIFY, PROTECT | Connector intake records, MCP allowlists, plugin review notes, vendor risk records | | Runtime, sandbox, and autonomy | MAP, MEASURE, MANAGE | PROTECT, DETECT | Sandbox policy, approval settings, egress rules, test logs, exception records | | Data protection and residency | MAP, MEASURE, MANAGE | GOVERN, IDENTIFY, PROTECT | Data-flow maps, DLP policies, retention settings, ZDR scope, residency evidence | | Threats and adversarial testing | MAP, MEASURE, MANAGE | DETECT, RESPOND | Threat models, red-team reports, prompt-injection tests, abuse-case catalog | | Observability, audit, and evidence | MEASURE, MANAGE | DETECT, RESPOND, RECOVER | Compliance API exports, telemetry, SIEM detections, evidence reconciliation reports | | Rollout and operations | GOVERN, MANAGE | GOVERN, IDENTIFY | Pilot gates, risk acceptance, review cadence, control owners, exception register | ## How to apply NIST AI RMF Use AI RMF GOVERN for the program layer: * Who owns AI security policy? * Who approves a new AI system or AI feature? * Which roles have authority to accept residual risk? * How are AI incidents escalated? * How are legal, privacy, data, HR, procurement, and security involved? Use AI RMF MAP for context: * What AI surface is being used: chat, coding agent, browser agent, hosted agent, API app, or low-code builder? * What data can enter the system? * What can the system read, write, execute, or send externally? * Who is affected by the system's output? * Which vendors, tools, connectors, model endpoints, and logs are in the workflow? Use AI RMF MEASURE for testing and evidence: * Has the team tested prompt injection, data leakage, tool misuse, and permission boundaries? * Are results measured against acceptance criteria? * Are logs complete enough to investigate a failure? * Are outputs and decisions sampled after deployment? * Are controls tested after vendor feature changes? Use AI RMF MANAGE for treatment: * Which risks are mitigated, accepted, transferred, or avoided? * Which controls are required before pilot? * Which controls are required before production? * Which incidents trigger suspension or rollback? * Which review cadence applies after launch? ## How to apply NIST CSF 2.0 Use CSF GOVERN for policy, accountability, and third-party risk: * AI acceptable use policy * AI risk appetite * Approved tool catalog * Procurement gates * Vendor and connector ownership * Review cadence Use CSF IDENTIFY for inventory and dependency mapping: * AI systems and surfaces * Users, agents, service accounts, and API keys * Data classes and data flows * Connectors, MCP servers, plugins, skills, packages, and model providers * Compliance and telemetry sources Use CSF PROTECT for preventive controls: * SSO, SCIM, RBAC, tenant restrictions * DLP and data classification * Egress controls and sandbox settings * Approval policies * Secrets handling * Allowlists for connectors and extensions Use CSF DETECT for monitoring: * Audit logs * Compliance API exports * Runtime telemetry * SIEM detections * Usage analytics * Alerts for policy bypass and anomalous AI activity Use CSF RESPOND for incidents: * AI incident runbooks * Vendor escalation paths * Evidence preservation * Revocation of tokens, connectors, and agent sessions * User and legal notification workflow Use CSF RECOVER for restoration: * Rollback of agent definitions, plugins, and model configuration * Credential rotation * Data exposure follow-up * Lessons learned * Control updates after incidents ## Minimum evidence pack For each approved AI workflow, keep: * Owner record: business owner, security owner, platform owner, data owner, incident owner. * System record: purpose, users, vendor, deployment model, data classes, connected tools. * Control record: required handbook controls, exceptions, compensating controls, approval date. * Test record: prompt-injection tests, exfiltration tests, permission tests, logging tests. * Monitoring record: logs collected, retention, SIEM routing, review cadence. * Change record: vendor changes, enabled features, model changes, connector changes, policy updates. ## Common NIST AI RMF and CSF 2.0 control mapping security failures * The team maps controls to a framework after rollout instead of using the mapping during intake. * AI RMF is owned by legal or compliance while the technical controls are owned somewhere else. * CSF reporting says controls exist, but the evidence does not show that they apply to AI surfaces. * The matrix treats chat, coding agents, and hosted agents as one deployment model. * The team tests the model output but not tool calls, connectors, local files, or logs. ## Frequently asked questions about NIST AI RMF and CSF 2.0 control mapping ### Should every AI use case get a full NIST AI RMF assessment? No. Scale the assessment to the risk. Low-risk internal chat may need inventory, data rules, and logging evidence. A production agent with write access, customer data, or employment decisions needs a full context map, control review, testing record, and named risk acceptance. ### Does NIST CSF 2.0 cover AI-specific risks? It covers many security outcomes that AI systems need, but it does not give enough AI-specific detail by itself. Pair it with AI RMF and the handbook control matrix. ### Where does the NIST AI RMF Generative AI Profile fit? Use the Generative AI Profile when the system relies on generative AI, including LLM-based agents, synthetic content, retrieval-augmented generation, or tool use directed by a generative model. It makes generative-AI risks and suggested actions more concrete. ### Who should own the mapping? Security should maintain the cybersecurity control mapping, with compliance support. The accountable business owner should own the use-case risk decision. Legal and privacy should review regulatory mappings, and platform teams should own evidence for technical settings and telemetry. ## Applicable handbook articles Coverage is intentionally broad because this page combines the AI RMF's lifecycle risk functions with CSF 2.0 cybersecurity outcomes. Each linked article supplies implementation evidence; the table is not an official one-to-one NIST crosswalk. | Handbook area | Applicable articles | Why they apply | | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | 1. Identity & access |

1.1 SSO & SCIM for AI platforms
1.2 RBAC across AI platforms
1.3 Tenant restrictions: blocking personal accounts
1.4 Domain claiming: bringing shadow accounts into enterprise
1.5 Agent and non-human identity
1.6 API keys and service accounts governance
1.7 Human-in-the-loop and approval policies

| Supports AI RMF accountability and human configuration of controls, plus CSF PR.AA identity, authentication, and access outcomes. | | 2. Connectors, extensions & supply chain |

2.1 Connectors and apps: the integration backbone
2.2 MCP servers: securing the protocol
2.3 MCP gateways and allowlisting
2.4 Analyzing skills for risk
2.5 Plugins and marketplaces
2.6 Hooks and lifecycle scripts
2.7 The supply-chain review workflow
2.8 Signing and packaging
2.9 SaaS agent-building supply-chain
2.10 Hosted-agent framework dependencies

| Supports AI RMF third-party risk and CSF GV.SC, ID.AM, and PR.PS supply-chain, asset, and platform-security outcomes. | | 3. Runtime, sandboxing & autonomy |

3.1 Sandbox and isolation models
3.2 Approval policies and least-privilege autonomy
3.3 Network egress control
3.4 Internet access and browser automation
3.5 Computer Use / desktop control risks
3.6 Scheduled and background tasks
3.7 Remote access, dispatch and SSH
3.8 File and filesystem access controls
3.9 Central hosted-agent runtime hardening

| Supports AI RMF testing and risk treatment, plus CSF PR.PS, PR.IR, and DE.CM protection, resilience, and monitoring outcomes. | | 4. Data protection |

4.1 DLP for GenAI
4.2 Data classification for AI prompts and outputs
4.3 Data residency and regional inference
4.4 Retention and Zero Data Retention
4.5 Training opt-out and data usage
4.6 Cross-app data flow and live artifacts
4.7 Secrets and credential hygiene in prompts and tools

| Supports AI RMF context, privacy, and data-risk work, plus CSF ID.AM and PR.DS data inventory and protection outcomes. | | 5. Threats & adversarial testing |

5.1 Prompt injection: the connective risk
5.2 Data exfiltration via tools and connectors
5.3 Supply chain attacks and notable CVEs
5.4 Agent-specific threats: tool poisoning and confused deputy
5.5 Red-teaming AI systems
5.6 Incident response for AI systems
5.7 Threat modeling AI systems

| Supports AI RMF risk identification, testing, evaluation, verification, and validation, plus CSF ID.RA, DE.AE, and RS outcomes. | | 6. Observability, audit & evidence |

6.1 The audit gap: what you can and can't see
6.2 OpenTelemetry for AI runtime
6.3 Compliance APIs by platform
6.4 Analytics and usage APIs
6.5 Routing AI telemetry to your SIEM
6.6 Evidence by surface and investigation paths
6.7 Continuous review cadence

| Supports AI RMF measurement and monitoring, plus evidence for CSF Detect, Respond, and Recover outcomes. | | 7. Rollout & operations |

7.1 Roll out by risk: the phased plan
7.2 Pilot design and success metrics
7.3 The security team checklist
7.4 The vendor-neutral control matrix

| Supports AI RMF GOVERN and MANAGE activities, plus CSF Govern and ID.IM improvement outcomes. | ## Further reading The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page. * [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework). AI RMF 1.0 remains the current published framework; NIST states that a revision is in progress. * [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework) * [NIST AI RMF Generative AI Profile, NIST AI 600-1](https://doi.org/10.6028/NIST.AI.600-1) ## Related handbook guidance * [Governance & Frameworks](/reference/governance-and-frameworks) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) * [5.7 Threat modeling AI systems](/handbook/5.-threats-and-adversarial/5.7-threat-modeling-ai-systems) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths) * [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security) # G.2 EU AI Act obligations for deployers EU AI Act obligations for enterprise deployers, including classification, human oversight, monitoring, logging, transparency, and evidence. *Last reviewed: August 18, 2026* {% hint style="info" %} The EU AI Act gives deployers their own duties. Once the relevant high-risk provisions apply, those duties cover use according to instructions, human oversight, monitoring, logs, notices, and, for specified deployers and uses, fundamental rights impact assessment. {% endhint %} This page is for organizations that buy, configure, integrate, or operate AI systems. Under the EU AI Act, an organization can be a deployer even when it did not build the model or system. Article 25 can treat a distributor, importer, deployer, or other third party as a provider when it puts its name or trademark on a high-risk system, makes a substantial modification, or changes the intended purpose in a way that makes the system high-risk. Legal should determine the role for each use case. ## Start with classification Classify each AI use case before deciding what obligations apply. | Question | Why it matters | | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | Is the system prohibited under Article 5? | Prohibited practices are not allowed once the relevant provisions apply. | | Is the system high-risk under Article 6 or Annex III? | High-risk systems trigger the main deployer obligations. | | Does the system make or support decisions about natural persons? | Notice and fundamental-rights questions become more important. | | Is the organization only using the system, or modifying it substantially? | Substantial modification can change the legal role. | | Does the use involve employees, customers, students, patients, applicants, borrowers, insureds, or public-service recipients? | These are common affected-person categories for high-risk review. | ## Deployer obligations for high-risk AI systems For high-risk AI systems, deployers should prepare to show that they: * Use the system according to the provider's instructions for use. * Assign human oversight to people with appropriate competence, training, authority, and support. * Monitor system operation based on the instructions for use. * If use according to the instructions may present a risk under Article 79, suspend use and notify the provider or distributor and the relevant market-surveillance authority without undue delay. * Report serious incidents through the provider, importer, distributor, and relevant authority path required by Article 26. * Keep automatically generated logs under the deployer's control for at least six months, unless another applicable law sets a different period. * Use relevant and sufficiently representative input data when the deployer controls input data. * Inform workers and worker representatives before putting a high-risk AI system into service in the workplace, where applicable. * Inform affected natural persons when an Annex III high-risk AI system makes or assists decisions about them. * Cooperate with competent authorities. Treat this as a control checklist, not a paperwork exercise. A deployer who cannot show logs, oversight assignment, and monitoring evidence will struggle to prove the system is governed. ## Fundamental rights impact assessment Article 27 requires a fundamental rights impact assessment before first use for specified high-risk systems and deployers. It covers bodies governed by public law, private entities providing public services, and deployers of the creditworthiness and life or health-insurance systems listed in Annex III points 5(b) and 5(c). The article excludes the critical-infrastructure systems in Annex III point 2 from this requirement. A practical assessment should include: * The business process where the AI system will be used. * The intended purpose and frequency of use. * The categories of people and groups affected. * The specific risks of harm in that context. * The human oversight measures used. * Measures to use if the identified risks materialize, including internal governance and complaint mechanisms. * The relationship to any data protection impact assessment. If a DPIA already covers some items, do not duplicate work. Link it and add the AI-specific pieces: intended purpose, model behavior, oversight, affected groups, monitoring, and escalation. ## Transparency and notice Article 26 requires deployers of Annex III high-risk systems to inform natural persons when the system makes or assists in a decision about them. Other transparency duties may apply to chatbots, emotion recognition, biometric categorization, deepfakes, and certain AI-generated public-interest text. Match the notice to the applicable article and use case. Notices should say: * The AI system is being used. * The decision or process it supports. * The deployer responsible for the use. * The type of data used. * How a person can request more information, correction, review, or escalation when applicable. Do not let the vendor own this alone. The provider can supply instructions, but the deployer knows the local context, affected people, and decision process. ## Timeline to track The base regulation and the 2026 amendment process need to be read together: * The Act entered into force on August 1, 2024. * Chapters I and II, including AI literacy and prohibited practices, have applied since February 2, 2025. * Governance rules and obligations for general-purpose AI models have applied since August 2, 2025. * Most remaining provisions apply from August 2, 2026, including several Article 50 transparency duties. * The original regulation set August 2, 2027 for high-risk systems covered by Article 6(1), which are systems tied to regulated products. * On May 7, 2026, the European Parliament and Council reached a political agreement on the AI Omnibus. The Commission says the agreed timeline moves Annex III high-risk rules to December 2, 2027 and product-embedded high-risk rules to August 2, 2028. The Omnibus dates reflect the political agreement reported by the Commission. Confirm the final adopted text and Official Journal publication before treating them as settled legal deadlines. ## Common EU AI Act obligations for deployers security failures * The team assumes the provider owns all EU AI Act obligations. * The system is classified once and never reclassified after a feature or workflow change. * Human oversight is assigned to people who lack authority to stop the system. * Logs exist in the vendor platform but are not retained or accessible to the deployer. * A DPIA exists, but it does not cover AI-specific context, affected groups, or oversight. * Notices say "AI may be used" but do not explain the specific decision process. ## EU AI Act obligations for deployers security controls checklist * Classify each AI use case by risk tier and legal role. * Record whether the organization is deployer, provider, distributor, importer, or more than one. * Keep provider instructions for use with the system record. * Assign trained human oversight with authority to intervene. * Test monitoring, logging, and incident escalation before production. * Prepare affected-person notices where required. * Run a fundamental rights impact assessment when Article 27 applies. * Reassess after substantial modification, new data classes, new affected groups, or new automation. ## Frequently asked questions about EU AI Act obligations for deployers ### Do internal enterprise AI tools count? They can. The Act applies to deployers established or located in the EU. It can also apply to a provider or deployer outside the EU when output produced by the system is used in the EU. Internal use is not a general exemption. ### Is a chatbot high-risk? Not by default. Classification turns on the AI system's intended purpose and use. A drafting chatbot may fall outside the high-risk categories, while a system that materially supports employment, education, credit, insurance, public benefits, or another Annex III decision may be high-risk. ### Can vendor documentation satisfy deployer obligations? It helps, but it is not enough. The deployer must document local use, input data, oversight, monitoring, logs, notices, and incidents. ### What should security own? Security should own technical control evidence: identity, logs, DLP, connectors, runtime controls, incident response, and monitoring. Legal, privacy, HR, compliance, and the business owner should own legal classification and affected-person obligations. ## Applicable handbook articles *This table applies only when the organization is acting as a deployer and the EU AI Act duties described on this page apply to the system.* This mapping is deliberately limited to the deployer duties described on this page. It does not import provider obligations or turn every prudent AI security control into an EU AI Act requirement. | Handbook area | Applicable articles | Why they apply | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | 1. Identity & access | 1.7 Human-in-the-loop and approval policies | Human oversight and authority. | | 2. Connectors, extensions & supply chain | 2.7 The supply-chain review workflow | Provider instructions, system-version intake, and material-change control. | | 3. Runtime, sandboxing & autonomy |

3.2 Approval policies and least-privilege autonomy
3.9 Central hosted-agent runtime hardening

| Human intervention, suspension, and runtime monitoring. | | 4. Data protection |

4.2 Data classification for AI prompts and outputs
4.4 Retention and Zero Data Retention

| Input-data relevance and retention of deployer-controlled logs for at least six months. | | 5. Threats & adversarial testing |

5.6 Incident response for AI systems
5.7 Threat modeling AI systems

| Incident duties and technical input to rights-impact review. | | 6. Observability, audit & evidence |

6.1 The audit gap: what you can and can't see
6.2 OpenTelemetry for AI runtime
6.3 Compliance APIs by platform
6.5 Routing AI telemetry to your SIEM
6.6 Evidence by surface and investigation paths
6.7 Continuous review cadence

| Logging, monitoring, investigation, and evidence availability. | ## Further reading The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page. * [Regulation (EU) 2024/1689, Artificial Intelligence Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng), especially Articles 2, 25, 26, 27, 50, and 113 * [European Commission AI Act implementation overview](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) * [European Commission guidance for providers and deployers of high-risk systems](https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-high-risk-systems). The page identifies the July 2026 material as draft guidance and reports the May 2026 political agreement on timing. ## Related handbook guidance * [Governance & Frameworks](/reference/governance-and-frameworks) * [4.4 Retention and Zero Data Retention](/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention) * [1.7 Human-in-the-loop and approval policies](/handbook/1.-identity-and-access/1.7-human-in-the-loop-and-approval-policies) * [6.3 Compliance APIs by platform](/handbook/6.-observability-audit-and-evidence/6.3-compliance-apis-by-platform) * [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security) # G.3 DORA and AI resilience in financial services ICT risk management, third-party risk, operational resilience testing, and incident reporting applied to AI vendors, agents, and model-hosting platforms under DORA. *Last reviewed: August 18, 2026* {% hint style="info" %} For financial services, AI security is also ICT resilience. If an AI tool can affect a critical or important function, treat the vendor, agent runtime, connectors, telemetry, and incident path as part of the DORA control environment. {% endhint %} DORA has applied since January 17, 2025 to the financial entities listed in Article 2 and to their management of ICT risk. It also establishes EU oversight for designated critical ICT third-party providers. AI systems are not a separate DORA category, but enterprise AI commonly depends on ICT services such as model APIs, cloud infrastructure, agent sandboxes, SaaS connectors, identity providers, logging systems, and data stores. The entity's regulated status and the service provided determine scope. Legal and compliance should confirm whether DORA applies before the team treats this page as a requirements checklist. Include DORA in the review when an AI workflow could affect an in-scope financial entity's ability to deliver, protect, investigate, or recover a service. ## DORA areas that matter for AI | DORA area | AI security interpretation | | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | ICT risk management | AI systems, agent runtimes, connectors, and model APIs belong in the ICT risk framework when they support financial operations. | | ICT-related incident management and reporting | AI incidents may involve data leakage, unavailable AI-supported workflows, compromised connectors, or agent misuse. | | Digital operational resilience testing | AI controls need testing: prompt injection, tool misuse, fallback process, logging, recovery, and vendor outage scenarios. | | ICT third-party risk | AI vendors, model platforms, cloud sandboxes, telemetry vendors, and connector providers may be ICT third-party service providers. | | Information sharing | Threat intelligence for prompt injection, AI supply-chain compromise, and vendor incidents should feed normal cyber sharing processes. | ## Classify the AI workflow Before approving an AI system in a DORA-regulated environment, record: * The financial service or business process supported. * Whether the workflow touches a critical or important function. * The AI deployment model: chat, coding agent, browser/desktop agent, hosted agent, API app, or low-code builder. * The vendor and all material ICT dependencies. * The data classes involved. * Whether the system can write, transact, notify customers, alter records, or trigger downstream workflows. * The fallback process if the AI system, model provider, connector, or logging path fails. ## Third-party risk questions for AI vendors Ask AI vendors and platform owners: * What services process prompts, files, embeddings, tool calls, logs, and traces? * Where are those services hosted? * Which subcontractors or subprocessors are involved? * What retention settings apply to prompts, files, logs, traces, and abuse-monitoring records? * How are incidents reported to customers? * What audit evidence is available? * Can the organization export logs quickly during an incident? * How does the vendor support exit, portability, and deletion? * Which features are excluded from compliance exports or retention controls? * Which services and subcontractors must appear in the DORA register of information? The vendor's AI trust documentation is useful, but DORA review needs operational facts: service dependencies, resilience, incident timing, contract terms, audit rights, and exit plans. ## Resilience tests for AI systems At minimum, test: * Vendor outage: users can continue the critical process without the AI tool. * Connector failure: the system fails closed and does not retry into unsafe states. * Logging failure: the workflow pauses or flags degraded evidence before high-risk actions. * Prompt injection: untrusted content cannot cause unauthorized disclosure or action. * Credential exposure: secrets in prompts, files, and agent environments are blocked or detected. * Agent runaway: approval gates and stop controls work. * Data residency and retention: evidence matches the approved data class. * Incident response: security can revoke tokens, disable connectors, preserve evidence, and notify the right parties. ## Incident handling AI incidents in financial services may look like ordinary ICT incidents, data incidents, or operational resilience events. Do not route them only to the AI program owner. Examples: * An agent sends customer data to an unapproved connector. * A model provider outage breaks a customer-service workflow that depends on AI triage. * A coding agent commits a credential or changes a payment workflow. * A prompt-injection chain causes a browser or desktop agent to act in a signed-in session. * A compliance API gap prevents timely investigation of AI activity. For each approved AI workflow, document whether an event could meet the DORA criteria for a major ICT-related incident, qualify as a personal data breach, trigger another sector reporting duty, or fall into more than one category. When an incident is classified as major under DORA, Commission Delegated Regulation (EU) 2025/301 sets the reporting clock: the initial notification is due as early as possible, within four hours after classification and no later than 24 hours after awareness; the intermediate report is due within 72 hours after the initial notification; and the final report is due within one month after the intermediate or latest updated intermediate report. Build these deadlines into the incident runbook rather than relying on the AI vendor's notification process. ## Common DORA and AI resilience in financial services security failures * The AI vendor is reviewed as a productivity tool even though it supports a critical process. * The contract covers the SaaS app but not model APIs, sandboxes, telemetry, or connectors. * The team tests model quality but not operational fallback. * Incident response cannot retrieve prompt, file, tool, or trace evidence quickly. * Exit planning ignores prompt history, embeddings, fine-tuning data, agent state, and logs. * A low-code agent builder lets business teams create new ICT dependencies without DORA review. ## DORA and AI resilience in financial services security controls checklist * Add AI systems and agent runtimes to the ICT inventory when they support financial operations. * Mark whether each AI workflow supports a critical or important function. * Review AI vendors as ICT third parties when applicable. * Test outage, fallback, logging, connector failure, prompt injection, and credential exposure. * Define incident classification paths for AI-related events. * Keep evidence of vendor due diligence, resilience tests, control settings, and review dates. * Reassess after new connectors, new agent autonomy, new data classes, or vendor feature releases. ## Frequently asked questions about DORA and AI resilience in financial services ### Does DORA apply to every AI tool used by a financial institution? Not in the same way. First confirm that the organization is an in-scope financial entity. Then assess the function and dependency. Low-risk drafting tools still need normal security controls, while tools supporting critical or important functions require stronger resilience, contract, testing, register, and exit evidence. ### Are AI model providers ICT third-party service providers? They can be. If the model provider, API, hosted agent platform, or AI SaaS tool supports a regulated financial process, treat it as an ICT dependency and review the contract, resilience, incident, and exit requirements. ### What makes an AI incident a DORA concern? An event becomes a DORA reporting concern when it is an ICT-related incident and meets the applicable classification criteria for a major incident. Route suspected cases through the ICT incident process promptly so the regulated entity can classify the event and meet the reporting clock. ### Who should own DORA alignment for AI? The regulated entity owns compliance. Security, operational resilience, procurement, legal, and the AI platform owner should share the evidence. The AI vendor cannot own the regulated entity's resilience program. ## Applicable handbook articles *This table applies only to a DORA-regulated entity and an AI workflow within its ICT risk environment.* DORA is technology-neutral and applies across an in-scope entity's ICT risk environment. These links identify practical controls for AI capabilities used in that environment; only the articles for features and surfaces actually present in the system apply. The links are not article-by-article statements of legal equivalence. | Handbook area | Applicable articles | Why they apply | | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | 1. Identity & access |

1.1 SSO & SCIM for AI platforms
1.2 RBAC across AI platforms
1.3 Tenant restrictions: blocking personal accounts
1.4 Domain claiming: bringing shadow accounts into enterprise
1.5 Agent and non-human identity
1.6 API keys and service accounts governance
1.7 Human-in-the-loop and approval policies

| Supports access and identity lifecycle controls for an in-scope ICT environment. | | 2. Connectors, extensions & supply chain |

2.1 Connectors and apps: the integration backbone
2.2 MCP servers: securing the protocol
2.3 MCP gateways and allowlisting
2.4 Analyzing skills for risk
2.5 Plugins and marketplaces
2.6 Hooks and lifecycle scripts
2.7 The supply-chain review workflow
2.8 Signing and packaging
2.9 SaaS agent-building supply-chain
2.10 Hosted-agent framework dependencies

| When these surfaces are used, supports ICT asset, dependency, third-party, acquisition, and change control. | | 3. Runtime, sandboxing & autonomy |

3.1 Sandbox and isolation models
3.2 Approval policies and least-privilege autonomy
3.3 Network egress control
3.4 Internet access and browser automation
3.5 Computer Use / desktop control risks
3.6 Scheduled and background tasks
3.7 Remote access, dispatch and SSH
3.8 File and filesystem access controls
3.9 Central hosted-agent runtime hardening

| When these surfaces are used, supports secure and resilient operation, containment, continuity, and recovery. | | 4. Data protection |

4.1 DLP for GenAI
4.2 Data classification for AI prompts and outputs
4.3 Data residency and regional inference
4.4 Retention and Zero Data Retention
4.6 Cross-app data flow and live artifacts
4.7 Secrets and credential hygiene in prompts and tools

| Supports confidentiality, integrity, classification, location, retention, data-flow, and secrets controls. | | 5. Threats & adversarial testing |

5.1 Prompt injection: the connective risk
5.2 Data exfiltration via tools and connectors
5.3 Supply chain attacks and notable CVEs
5.4 Agent-specific threats: tool poisoning and confused deputy
5.5 Red-teaming AI systems
5.6 Incident response for AI systems
5.7 Threat modeling AI systems

| Supports cyber-risk assessment, resilience testing, vulnerability handling, and incident response. | | 6. Observability, audit & evidence |

6.1 The audit gap: what you can and can't see
6.2 OpenTelemetry for AI runtime
6.3 Compliance APIs by platform
6.5 Routing AI telemetry to your SIEM
6.6 Evidence by surface and investigation paths
6.7 Continuous review cadence

| Supports logging, detection, investigation, audit evidence, and reassessment. | | 7. Rollout & operations |

7.1 Roll out by risk: the phased plan
7.2 Pilot design and success metrics
7.3 The security team checklist
7.4 The vendor-neutral control matrix

| Supports pre-production approval, testing, controlled change, and operational readiness. | ## Further reading The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page. * [Regulation (EU) 2022/2554, Digital Operational Resilience Act](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) * [Commission Delegated Regulation (EU) 2025/301 on major ICT-related incident reporting](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng) * [ESMA DORA implementation and policy requirements](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora) ## Related handbook guidance * [Governance & Frameworks](/reference/governance-and-frameworks) * [4.3 Data residency and regional inference](/handbook/4.-data-protection-and-residency/4.3-data-residency-and-regional-inference) * [5.6 Incident response for AI system](/handbook/5.-threats-and-adversarial/5.6-incident-response-for-ai-system) * [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence) * [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security) # G.4 Colorado AI Act and the US state patchwork Colorado’s 2026 ADMT law, consequential-decision disclosures, consumer rights, and the emerging multi-state AI regulation picture. *Last reviewed: August 18, 2026* {% hint style="info" %} Colorado's current statute is the Automated Decision-Making Technology Act (Colorado AI Act), enacted as SB26-189 in May 2026. It replaces the SB24-205 framework and takes effect on January 1, 2027. Do not use the old June 30, 2026 checklist. {% endhint %} Colorado SB26-189 repeals and reenacts the provisions created by SB24-205. The current law focuses on automated decision-making technology that materially influences consequential decisions. It requires technical documentation, consumer notices, data-correction and human-review rights, and record retention. The Attorney General is developing rules before the January 1, 2027 effective date. Use this page for security and evidence planning. Legal should confirm scope, exemptions, and the final rules for each use case. ## Start with the current definitions The law defines automated decision-making technology, or ADMT, as technology that processes personal data and uses computation to generate output used to make, guide, or assist a decision about an individual. A covered ADMT materially influences a consequential decision. The covered domains are: * Education enrollment or opportunity. * Employment or an employment opportunity that may create an employer-employee relationship. * The lease or purchase of residential real estate in Colorado. * Financial or lending services. * Insurance, including underwriting, pricing, coverage, claims, and access to benefits. * Healthcare services. * Essential government services and public benefits. The statute excludes several routine technologies and uses. Examples include specified cybersecurity and infrastructure tools, low-stakes administrative processes, and tools used only to summarize, organize, translate, draft, route, or present information for human review. A natural-language tool can also fall outside the ADMT definition when it is not intended for consequential decisions and is governed by an acceptable use policy that prohibits that use. Classification depends on actual design, marketing, configuration, contracts, and use. A general drafting assistant should not be treated as covered merely because it uses AI. The same tool needs a new review if a team begins using its scores, rankings, recommendations, classifications, predictions, or other inferences to influence a consequential decision. ## Developer duties Starting January 1, 2027, a developer of covered ADMT must give deployers understandable technical documentation that includes: * Intended uses and known harmful or inappropriate uses. * Categories of data, including personal data, used to train the system, to the extent known. * Known limitations, risks, and circumstances in which the system should not be used. * Instructions for appropriate use, monitoring, and meaningful human review where applicable. * Information reasonably necessary for deployer notices and disclosures. * Notice of material updates, substantial modifications, and relevant changes to intended use, limitations, or risk mitigation. Developers must keep records reasonably necessary to show compliance for at least three years. The records include system version identifiers, change logs, documentation, and material-update notices. ## Deployer duties and consumer rights Before using covered ADMT to materially influence a consequential decision, a deployer must provide clear and conspicuous notice to the affected consumer. A prominent public notice can satisfy this requirement when it is reasonably accessible at the point of interaction. If the decision produces an adverse outcome, the deployer must provide a plain-language disclosure within 30 days. The disclosure must describe the decision and the ADMT's role, explain how to request additional information, and explain the consumer's rights. After an adverse outcome, a consumer may request: * The personal data used in the decision and correction of factually incorrect or materially inaccurate personal data. * Meaningful human review and reconsideration, to the extent commercially reasonable. The statute defines meaningful human review as review by a trained person who can approve, modify, or override the decision, considers relevant primary evidence, does not default to the system output, and has enough information to understand the output and its principal factors. Deployers must keep records reasonably necessary to show compliance for at least three years after the consequential decision. The law also contains sector-specific provisions and exemptions, including provisions for credit, education, insurance, healthcare, and systems regulated by the FDA. Legal should map those provisions before the team builds a separate notice or appeal process. ## Enforcement and rulemaking The Colorado Attorney General has exclusive authority to enforce the new disclosure and consumer-rights provisions through the Colorado Consumer Protection Act. The law creates no new private right of action. It does not make compliance a defense to other state or federal law. The Attorney General must clarify post-adverse-outcome disclosures and consumer-rights procedures by rule before January 1, 2027. The rulemaking was in a pre-rulemaking stage in July 2026. Treat templates and workflows as provisional until the final rules are published. Colorado also enacted HB26-1263, Conversational Artificial Intelligence Service Operator Requirements, signed May 29, 2026 and effective January 1, 2027. It applies to covered conversational AI service operators and includes protections for minors, interaction disclosures, account and privacy tools, and response protocols for self-harm content. Do not combine those duties with the ADMT checklist without first determining which law applies. ## What security teams should prepare For each potentially covered workflow, keep: * The business process and covered domain. * The system's intended, marketed, configured, contracted, and actual use. * The model, system version, and material-update history. * The personal data and other inputs used. * The decision path and the role of the ADMT output. * The point-of-interaction notice and adverse-outcome disclosure workflow. * The personal-data request and correction workflow. * The human reviewer, training record, authority, and reconsideration procedure. * The developer documentation and any withheld-information notice. * Compliance records and retention dates. * The legal owner and date of the latest rulemaking review. ## The wider US state patchwork State AI requirements now span several kinds of law. Track at least: * Automated or AI-assisted consequential decisions. * Employment and hiring tools. * Insurance and financial-services models. * Privacy, profiling, and automated-decision rights. * Chatbots and protections for minors. * Deepfakes and synthetic media. * Healthcare and licensed professional services. * Frontier-model reporting and safety requirements. * State consumer-protection enforcement and rulemaking. Maintain one internal system of record for systems, use cases, decisions, data, owners, notices, rights requests, and evidence. Add a jurisdiction table to each covered workflow instead of creating a separate inventory for every law. ## Common Colorado AI Act and the US state patchwork security failures * The compliance plan still follows SB24-205 after SB26-189 replaced it. * The inventory records the vendor but not the system version or decision use. * A drafting tool is repurposed for ranking or recommendation without reclassification. * The notice appears only after an adverse outcome instead of at the point of interaction. * Human review exists on paper, but the reviewer cannot change the decision. * The team keeps model documentation but cannot reproduce which version influenced a decision. * Legal and security build workflows before checking the Attorney General's final rules. ## Colorado AI Act and the US state patchwork security controls checklist * Identify ADMT used in a covered domain. * Decide whether the output materially influences a consequential decision. * Record exclusions and the facts supporting them. * Obtain developer documentation before production use. * Prepare point-of-interaction and adverse-outcome notices. * Build personal-data access, correction, human-review, and reconsideration workflows. * Retain required records for at least three years. * Reclassify after material updates or changes in use. * Track Colorado rulemaking through the January 1, 2027 effective date. ## Frequently asked questions about Colorado AI Act and the US state patchwork ### Does ordinary employee use of a chatbot fall under this law? Usually not when the tool only drafts, summarizes, organizes, translates, routes, or presents information for human review. Review again if the tool begins producing an inference that materially influences a covered consequential decision. ### Does the law require an impact assessment and annual review? Those were prominent features of the superseded SB24-205 structure. SB26-189 replaced that framework with documentation, notice, consumer-rights, and record-retention requirements. Other laws or internal risk policy may still require an impact assessment or periodic review. ### Can a framework such as NIST AI RMF satisfy the law? A framework can help organize controls and evidence, but SB26-189 does not make framework compliance a legal defense. The statute expressly says compliance does not excuse noncompliance with other applicable law. ### What should the team do first? Find systems that influence covered decisions, record their versions and data, and determine whether the influence is material. Then obtain developer documentation and design the notice, correction, and human-review workflows with counsel. ## Applicable handbook articles *This table applies only when the system is covered ADMT used for a consequential decision under the Colorado requirements described on this page.* This mapping is limited to duties in the enacted Colorado law discussed on this page. It does not add controls based on possible future Attorney General rules. | Handbook area | Applicable articles | Why they apply | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- | | 1. Identity & access | 1.7 Human-in-the-loop and approval policies | Meaningful human review. | | 2. Connectors, extensions & supply chain | 2.7 The supply-chain review workflow | Developer documentation, intended use, system-version intake, and material-update handling. | | 3. Runtime, sandboxing & autonomy | 3.2 Approval policies and least-privilege autonomy | Human reconsideration and override authority. | | 4. Data protection |

4.2 Data classification for AI prompts and outputs
4.4 Retention and Zero Data Retention
4.6 Cross-app data flow and live artifacts

| Personal-data accuracy, decision-path explanation, and three-year record retention. | | 6. Observability, audit & evidence | 6.6 Evidence by surface and investigation paths | Evidence needed to demonstrate compliance with the enacted duties. | | 7. Rollout & operations | 7.4 The vendor-neutral control matrix | The use-case inventory and technical control record. | ## Further reading The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page. * [Colorado SB26-189, Automated Decision-Making Technology](https://leg.colorado.gov/bills/SB26-189), including the enacted bill summary and signed act * [Colorado HB26-1263: Conversational Artificial Intelligence Service Operator Requirements](https://leg.colorado.gov/bills/HB26-1263) * [Colorado Attorney General automated decision-making and chatbot rulemaking page](https://coag.gov/ai/) ## Related handbook guidance * [Governance & Frameworks](/reference/governance-and-frameworks) * [G.2 EU AI Act obligations for deployers](/reference/governance-and-frameworks/g.2-eu-ai-act-obligations-for-deployers) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) * [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security) * [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence) # G.5 SANS Critical AI Security Guidelines mapping How the handbook controls map to the SANS Critical AI Security Guidelines for a practitioner-first cross-check. *Last reviewed: August 18, 2026* {% hint style="info" %} The SANS community repository identifies version 1.1, published in April 2025, as the current public version. It organizes the guidance into Access Controls, Data Protection, Deployment Strategies, Inference Security, Monitoring, and Governance, Risk, Compliance. {% endhint %} This page maps the handbook to the SANS categories and to the practitioner questions security teams usually ask when they read AI security guidance: * Do we know which AI tools are being used? * Are users on managed accounts? * Is sensitive data blocked or monitored? * Are connectors, plugins, MCP servers, and agents reviewed? * Can agents act without approval? * Are prompts, files, tool calls, and outputs logged? * Have we tested prompt injection and exfiltration? * Do we know who owns incidents and exceptions? ## How to use this page Use the mapping during intake and quarterly review. During intake: * Mark the deployment model. * Mark the data classes. * Select the applicable controls. * Assign owners. * Record the evidence required before pilot and production. During review: * Check whether the tool still matches the original deployment model. * Check whether new connectors, agents, browser control, desktop control, or code execution were enabled. * Check whether evidence still exists and is recent. * Check whether incidents, user complaints, or vendor changes require a stronger posture. ## Additional practitioner cross-checks The SANS guidance also calls out model protection, augmentation data, model hosting choices, public model risk, prompt and output filtering, focused functionality, API abuse monitoring, model registries, and AI bill-of-materials tracking. The handbook should cover those items through the controls above plus the more detailed pages on supply chain, runtime, data protection, threat modeling, and evidence. ## Suggested minimum posture For workforce chat: * SSO and managed accounts. * Approved tool list. * Data classification guidance. * DLP where available. * Retention and training-use review. * Audit exports or clear evidence gap. For coding agents: * Managed identity. * Repository trust model. * Sandbox and approval policy. * MCP, plugin, skill, hook, and dependency review. * Secrets protection. * SIEM routing for command, denial, and tool events. For browser or desktop agents: * Explicit cohort approval. * Endpoint and browser controls. * Connector and signed-in session review. * Approval for sensitive write actions. * Prompt-injection tests against untrusted content. * Evidence map that includes endpoint, browser, SaaS, and AI platform logs. For hosted agents and API apps: * Agent identity and scoped credentials. * Tool allowlist. * Egress controls. * Runtime logging and tracing. * Abuse-case testing. * Kill switch and token revocation. * Vendor resilience and incident evidence. ## Common SANS Critical AI Security Guidelines mapping security failures * The team says it follows SANS guidance but cannot point to system-level evidence. * The inventory lists AI vendors but not connectors, agents, or model APIs. * Prompt injection is tested only in chat, not in tool-using workflows. * A policy bans sensitive data but no DLP, logging, or review confirms it. * Security owns the policy while business teams publish low-code agents without review. * Exceptions do not expire. ## SANS Critical AI Security Guidelines mapping security controls checklist * Map every guideline to a handbook control and evidence artifact. * Keep deployment models separate. * Require evidence before production, not after an incident. * Re-run the mapping after major vendor feature releases. ## Frequently asked questions about SANS Critical AI Security Guidelines mapping ### Why include this page if the handbook already maps to NIST and ISO? SANS guidance is written for practitioners who need to secure AI deployments, not only report a management-system posture. NIST and ISO explain program structure. This mapping turns the SANS categories into the specific handbook pages and evidence a team can act on. ### Should this page cite OWASP and MITRE instead? OWASP and MITRE are better for threat and abuse-case coverage. This page is broader: access, data, deployment, inference, monitoring, and governance. Keep OWASP and MITRE in the threat-modeling and red-team pages, and use this page for the SANS control cross-check. ### What is the most important evidence item? The inventory. Without a current AI inventory, the team cannot know which controls, owners, logs, or notices apply. ## Applicable handbook articles This handbook crosswalk maps the public SANS v1.1 control objectives to the most relevant handbook articles and example evidence. It is not an official SANS mapping. | Handbook area | Applicable articles | SANS coverage and example evidence | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1. Identity & access |

1.1 SSO & SCIM for AI platforms
1.2 RBAC across AI platforms
1.3 Tenant restrictions: blocking personal accounts
1.5 Agent and non-human identity
1.6 API keys and service accounts governance
1.7 Human-in-the-loop and approval policies

| Access Controls: authentication, authorization, least privilege, and accountable user, agent, and API access. Evidence includes identity settings, role exports, access reviews, and key inventories. | | 2. Connectors, extensions & supply chain |

2.1 Connectors and apps: the integration backbone
2.2 MCP servers: securing the protocol
2.3 MCP gateways and allowlisting
2.7 The supply-chain review workflow
2.8 Signing and packaging
2.10 Hosted-agent framework dependencies

| Deployment Strategies, Inference Security, and GRC: integration allowlists, package integrity, dependency review, and AI bills of materials. Evidence includes approved integration inventories, review records, signatures, and dependency records. | | 3. Runtime, sandboxing & autonomy |

3.1 Sandbox and isolation models
3.2 Approval policies and least-privilege autonomy
3.3 Network egress control
3.4 Internet access and browser automation
3.8 File and filesystem access controls
3.9 Central hosted-agent runtime hardening

| Deployment Strategies and Inference Security: sandboxing, egress, external functions, file access, and hosted-runtime boundaries. Evidence includes sandbox policy, egress rules, tool restrictions, and runtime configuration. | | 4. Data protection |

4.1 DLP for GenAI
4.2 Data classification for AI prompts and outputs
4.3 Data residency and regional inference
4.4 Retention and Zero Data Retention
4.5 Training opt-out and data usage
4.6 Cross-app data flow and live artifacts
4.7 Secrets and credential hygiene in prompts and tools

| Data Protection: classification, DLP, hosting, retention, provider training use, data flows, and secrets. Evidence includes data rules, provider settings, flow diagrams, and secrets scans. | | 5. Threats & adversarial testing |

5.1 Prompt injection: the connective risk
5.2 Data exfiltration via tools and connectors
5.3 Supply chain attacks and notable CVEs
5.4 Agent-specific threats: tool poisoning and confused deputy
5.5 Red-teaming AI systems
5.6 Incident response for AI systems
5.7 Threat modeling AI systems

| Inference Security, Monitoring, and GRC: injection, leakage, supply-chain and agent threats, testing, incident response, and threat modeling. Evidence includes threat models, test reports, detections, and incident records. | | 6. Observability, audit & evidence |

6.1 The audit gap: what you can and can't see
6.2 OpenTelemetry for AI runtime
6.4 Analytics and usage APIs
6.5 Routing AI telemetry to your SIEM
6.6 Evidence by surface and investigation paths
6.7 Continuous review cadence

| Monitoring and GRC: audit coverage, runtime telemetry, API-usage monitoring, SIEM detections, evidence paths, and review. Evidence includes log samples, alerts, detection rules, and review records. | | 7. Rollout & operations |

7.1 Roll out by risk: the phased plan
7.2 Pilot design and success metrics
7.3 The security team checklist
7.4 The vendor-neutral control matrix

| Deployment Strategies and GRC: risk-based rollout, pilots, readiness checks, and control documentation. Evidence includes inventory, risk decisions, gate approvals, exceptions, and review minutes. | ## Further reading The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page. * [SANS Critical AI Security Guidelines repository](https://github.com/sans-community/ai-guidelines). The repository still identified v1.1 as current when checked on July 14, 2026, even though its README lists an older planned date for the next publication. * [SANS Critical AI Security Guidelines v1.1](https://github.com/sans-community/ai-guidelines/blob/current-version/SANS_Critical_AI_Security_Guidelines_v1.1.md) * Related control sources: [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework), [NIST CSF 2.0](https://www.nist.gov/cyberframework), [OWASP Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/), and [MITRE ATLAS](https://atlas.mitre.org/). ## Related handbook guidance * [Governance & Frameworks](/reference/governance-and-frameworks) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) * [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) * [5.7 Threat modeling AI systems](/handbook/5.-threats-and-adversarial/5.7-threat-modeling-ai-systems) * [7.3 The security team checklist](/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist) # G.6 Write an AI Acceptable Use Policy that holds up A reusable AUP template covering approved tools, data classes, personal accounts, connectors, agents, coding tools, mobile apps, and incident duties. *Last reviewed: August 18, 2026* {% hint style="info" %} An AI acceptable use policy should tell employees what they can use, what data they can enter, what actions need approval, and what to do when something goes wrong. It should match the controls security can actually enforce. {% endhint %} This page gives a policy template. Adapt it with legal, HR, privacy, compliance, and works-council review where required. ## Draft policy ### AI acceptable use policy ### 1. Purpose This policy defines how employees, contractors, and approved third parties may use artificial intelligence tools for company work. It applies to chat tools, coding assistants, browser and desktop agents, AI features inside SaaS applications, AI connectors, plugins, MCP servers, low-code agents, hosted agents, APIs, and mobile AI applications. The goal is to let teams use approved AI tools while protecting company data, customer data, credentials, intellectual property, regulated information, and business operations. ### 2. Scope This policy applies when a person uses AI for company work, whether the tool is provided by the company, embedded in another application, accessed through a browser, installed on a device, connected through an API, or used through a personal account on a company device. This policy also applies to AI agents that can read files, call tools, browse websites, write code, send messages, update records, or take actions through connected systems. ### 3. Approved tools Employees may use only AI tools approved by the company for company work. Approved tools are listed in the company AI tool catalog. The catalog identifies: * Approved users or groups. * Approved data classes. * Allowed connectors and integrations. * Allowed model or agent features. * Required approvals. * Owner and support path. * Review date. Employees must not use unapproved personal AI accounts for company work. ### 4. Account requirements Company work must be performed through managed company accounts when an approved enterprise account exists. Employees must not: * Use personal AI accounts for company work. * Upload company data to a personal AI account. * Connect personal cloud storage, email, chat, calendar, code repositories, or productivity accounts to AI tools for company work. * Share company AI accounts. * Use another employee's AI account or API key. ### 5. Training and AI literacy Employees must complete the AI training assigned to their role before using approved AI tools for company work. Training should cover the approved tools, data rules, output review, prompt injection, agent actions, incident reporting, and any use-case-specific legal or safety duties. People who approve, monitor, or conduct human review of higher-risk AI workflows need additional training and authority appropriate to that role. ### 6. Data handling rules Employees must follow the data classification rules for AI use. | Data type | Default rule | | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | Public information | Allowed in approved tools. | | Internal business information | Allowed in approved tools unless restricted by team policy. | | Confidential company information | Allowed only in approved enterprise tools with approved retention and logging. | | Customer confidential information | Allowed only when the tool and workflow are approved for that data class. | | Regulated personal data | Requires legal, privacy, and security approval before use. | | Secrets, passwords, API keys, tokens, and private keys | Not allowed in prompts, files, tools, logs, or agent environments unless a security-approved workflow explicitly requires it. | | Source code | Allowed only in approved coding tools and repositories under the required controls. | | Legal, HR, finance, health, and employment data | Requires function-owner approval and may require privacy or legal review. | When in doubt, do not enter the data into an AI tool. Ask the data owner or security team. ### 7. Connectors, plugins, MCP servers, and integrations Employees may use only approved connectors, plugins, MCP servers, browser extensions, desktop extensions, and AI integrations for company work. New integrations require review before use. Review must cover: * What data the integration can read. * What actions it can take. * Which identity it uses. * Where data is sent. * What logs exist. * How access is revoked. * Who owns the integration. Employees must not install or enable integrations that bypass company identity, DLP, logging, or approval controls. ### 8. Agents and autonomous actions AI agents must be approved before they are used for company work if they can: * Read or write files. * Browse websites. * Use signed-in sessions. * Call connectors or APIs. * Send messages. * Create, edit, or delete business records. * Run commands or code. * Access customer, employee, or regulated data. * Continue running without a person actively supervising the task. High-impact or irreversible actions require human approval unless security, legal, and the business owner approve a documented exception. Agents must have a named owner. The owner is responsible for access, instructions, data use, monitoring, and incident response. ### 9. Coding assistants Coding assistants may be used only in approved development environments and repositories. Developers must not: * Paste secrets or credentials into prompts. * Use unapproved MCP servers, plugins, hooks, or skills. * Allow agents to run commands outside approved sandbox and approval settings. * Accept generated code without review. * Add dependencies suggested by AI without normal dependency review. Generated code must follow the same review, testing, licensing, and security requirements as human-written code. ### 10. AI-generated output Employees are responsible for reviewing AI-generated output before relying on it or sharing it. Review is required for: * Customer-facing content. * Legal, HR, finance, security, or compliance work. * Code, configuration, scripts, and infrastructure changes. * Summaries of contracts, policies, or regulated records. * Decisions that affect customers, employees, applicants, students, patients, borrowers, insureds, or other individuals. AI output must not be treated as authoritative unless the workflow includes approved validation. ### 11. Prohibited uses Employees must not use AI tools to: * Bypass access controls, monitoring, DLP, or security policy. * Create malware, credential theft, evasion, or exploitation content outside an authorized security-testing or research process. * Make employment, lending, housing, insurance, healthcare, education, legal, or other consequential decisions without approved governance. * Impersonate another person without authorization. * Create deceptive synthetic media for company work. * Upload data the company is not allowed to share with the tool. * Process regulated data in an unapproved system. * Connect AI tools to personal accounts for company work. ### 12. Incidents and reporting Employees must report AI-related incidents promptly through the security reporting channel. Report if: * Sensitive data was entered into an unapproved AI tool. * An AI tool exposed, retained, or sent data unexpectedly. * An agent took an action the user did not intend. * A connector, plugin, MCP server, or extension behaved unexpectedly. * A prompt injection or suspicious instruction affected the AI workflow. * Credentials, code, customer data, or regulated data may have been exposed. * A user finds an unapproved AI tool used for company work. Do not delete evidence unless security instructs you to do so. ### 13. Exceptions Exceptions require approval from the business owner, security, and any required legal, privacy, or compliance reviewer. Each exception must include: * The approved tool and use case. * The data class. * The users or groups. * The reason for the exception. * Compensating controls. * Expiration date. * Owner. ### 14. Enforcement Violations may result in tool access removal, incident review, disciplinary action, contract remedies, or other action allowed by company policy and law. ## Implementation controls The policy should be paired with: * SSO and SCIM for approved AI platforms. * Tenant restrictions or domain controls where available. * RBAC for sensitive AI features. * DLP and secrets detection. * Connector and extension allowlists. * Sandbox, approval, and egress controls for agents. * Compliance exports and SIEM routing. * A living AI inventory. * Role-based AI literacy and use-case training. * Quarterly review. ## Common AI acceptable use policy security failures * The policy bans risky behavior that the organization cannot detect or enforce. * The policy names tools but not data classes. * The policy covers chat but not agents, coding tools, mobile apps, browser control, or connectors. * Exceptions never expire. * Employees are told to "be careful" without examples. * Legal approves the policy, but identity, DLP, and logging controls are not deployed. ## Frequently asked questions about AI acceptable use policy ### Should the policy list every approved AI tool? The policy should point to a maintained catalog rather than hard-code every tool. Tool lists change too often for a static policy. ### Should employees be allowed to use personal AI accounts for work? The default should be no. Personal accounts weaken identity, retention, DLP, audit, and legal control. If a business unit needs an exception, document the data class, user group, duration, and compensating controls. ### Who approves new AI tools? At minimum: the business owner, security, privacy or legal where data or affected-person risk exists, procurement for vendor terms, and platform or IT for deployment and support. ### How often should the policy be reviewed? Review quarterly during active rollout and after major vendor feature changes, incidents, new regulation, or new AI deployment models. ## Applicable handbook articles These links are limited to controls that the policy template expressly requires or uses to enforce its account, integration, agent, data, monitoring, and incident rules. | Handbook area | Applicable articles | Why they apply | | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | 1. Identity & access |

1.1 SSO & SCIM for AI platforms
1.2 RBAC across AI platforms
1.3 Tenant restrictions: blocking personal accounts
1.4 Domain claiming: bringing shadow accounts into enterprise
1.5 Agent and non-human identity
1.6 API keys and service accounts governance
1.7 Human-in-the-loop and approval policies

| Turns acceptable-use requirements in this domain into enforceable controls and evidence. | | 2. Connectors, extensions & supply chain |

2.1 Connectors and apps: the integration backbone
2.2 MCP servers: securing the protocol
2.3 MCP gateways and allowlisting
2.4 Analyzing skills for risk
2.5 Plugins and marketplaces
2.6 Hooks and lifecycle scripts
2.7 The supply-chain review workflow
2.9 SaaS agent-building supply-chain
2.10 Hosted-agent framework dependencies

| Turns acceptable-use requirements in this domain into enforceable controls and evidence. | | 3. Runtime, sandboxing & autonomy |

3.1 Sandbox and isolation models
3.2 Approval policies and least-privilege autonomy
3.3 Network egress control
3.4 Internet access and browser automation
3.5 Computer Use / desktop control risks
3.6 Scheduled and background tasks
3.8 File and filesystem access controls
3.9 Central hosted-agent runtime hardening

| Turns acceptable-use requirements in this domain into enforceable controls and evidence. | | 4. Data protection |

4.1 DLP for GenAI
4.2 Data classification for AI prompts and outputs
4.4 Retention and Zero Data Retention
4.6 Cross-app data flow and live artifacts
4.7 Secrets and credential hygiene in prompts and tools

| Turns acceptable-use requirements in this domain into enforceable controls and evidence. | | 5. Threats & adversarial testing |

5.1 Prompt injection: the connective risk
5.2 Data exfiltration via tools and connectors
5.3 Supply chain attacks and notable CVEs
5.4 Agent-specific threats: tool poisoning and confused deputy
5.6 Incident response for AI systems

| Turns acceptable-use requirements in this domain into enforceable controls and evidence. | | 6. Observability, audit & evidence |

6.1 The audit gap: what you can and can't see
6.3 Compliance APIs by platform
6.5 Routing AI telemetry to your SIEM
6.6 Evidence by surface and investigation paths
6.7 Continuous review cadence

| Turns acceptable-use requirements in this domain into enforceable controls and evidence. | | 7. Rollout & operations |

7.3 The security team checklist
7.4 The vendor-neutral control matrix

| Turns acceptable-use requirements in this domain into enforceable controls and evidence. | ## Further reading The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page. * [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) * [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework) * [Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng), including Article 4 on AI literacy and deployer obligations in Article 26 * [Colorado SB26-189](https://leg.colorado.gov/bills/SB26-189). The law's ADMT definition excludes specified natural-language tools when they are not intended for consequential decisions and an acceptable use policy prohibits generated content from being used in such decisions. ## Related handbook guidance * [Governance & Frameworks](/reference/governance-and-frameworks) * [1.3 Tenant restrictions: blocking personal accounts](/handbook/1.-identity-and-access/1.3-tenant-restrictions-blocking-personal-accounts) * [2.1 Connectors and apps: the integration backbone](/handbook/2.-supply-chain-and-extensibility/2.1-connectors-and-apps-the-integration-backbone) * [4.2 Data classification for AI prompts and outputs](/handbook/4.-data-protection-and-residency/4.2-data-classification-for-ai-prompts-and-outputs) * [7.3 The security team checklist](/handbook/7.-rollout-and-operations/7.3-the-security-team-checklist) # G.7 Ownership and RACI for AI security Names the owners across workspace admin, platform admin, security policy, endpoint, compliance, legal, privacy, procurement, and incident response. *Last reviewed: August 18, 2026* {% hint style="info" %} AI security fails when every team owns a slice and nobody owns the workflow. Assign owners by deployment model, data class, and control domain before rollout. {% endhint %} AI systems cross normal team boundaries. A single workflow can involve an identity provider, SaaS admin console, endpoint policy, browser session, model vendor, connector, DLP rule, compliance export, SIEM detection, and legal notice obligation. The RACI should show who can approve or reject a use, who keeps the evidence, and who responds when something breaks. Use the role names below as a template and map them to real teams. Keep one accountable role for each activity, even when several teams are responsible for the work. ## Core roles | Role | Primary responsibility | | ------------------------ | --------------------------------------------------------------------------------- | | Executive AI sponsor | Sets risk appetite and resolves cross-functional disputes. | | Business owner | Owns the use case, users, business value, and residual business risk. | | Security owner | Owns AI security controls, threat model, monitoring, and incident readiness. | | Platform owner | Owns AI platform configuration, feature enablement, integrations, and support. | | Identity owner | Owns SSO, SCIM, RBAC, tenant restrictions, groups, and access review. | | Data owner | Approves data classes, data flows, retention, and allowed AI use. | | Privacy owner | Reviews personal data, DPIA needs, privacy notices, and affected-person rights. | | Legal owner | Reviews regulatory obligations, contract terms, notices, and incident disclosure. | | Compliance owner | Owns evidence requests, control mapping, audit records, and review cadence. | | Procurement owner | Owns vendor intake, contract routing, security addenda, and renewal gates. | | Endpoint owner | Owns desktop apps, browser controls, MDM policy, and local agent restrictions. | | Developer platform owner | Owns coding agents, repositories, secrets, CI/CD, and developer tooling controls. | | SOC owner | Owns detections, triage, SIEM routing, and escalation. | | Incident response owner | Owns AI incident runbooks, evidence preservation, containment, and recovery. | ## RACI by control domain | Control domain | Accountable | Responsible | Consulted | Informed | | ------------------------------------------------- | ------------------------ | ----------------------------------------- | ------------------------------------ | ------------------- | | AI tool approval | Business owner | Security owner, procurement owner | Legal, privacy, compliance, platform | SOC, help desk | | SSO, SCIM, and RBAC | Identity owner | Identity team, platform owner | Security, compliance | Business owner | | Tenant restrictions and personal-account blocking | Security owner | Identity owner, network or endpoint owner | Legal, HR | Users | | Connector and MCP review | Security owner | Platform owner | Data owner, privacy, legal | Business owner | | Coding-agent controls | Developer platform owner | Security engineering, developer tooling | Legal for license/data issues | Engineering leads | | Browser and desktop agents | Endpoint owner | Endpoint team, platform owner | Security, privacy, legal | Users | | Data classification for AI | Data owner | Security, privacy | Legal, compliance, business owner | Users | | Retention and training-use settings | Data owner | Platform owner | Legal, privacy, compliance | Business owner | | Logging and compliance exports | Security owner | Platform owner, SOC | Compliance, legal, privacy | Business owner | | SIEM detections | SOC owner | Detection engineering | Platform owner, IR owner | Security leadership | | AI threat modeling | Security owner | Security architect, platform owner | Business, data, privacy, legal | Compliance | | Red-team and abuse-case testing | Security owner | Red team or appsec | Platform owner, business owner | Compliance | | Incident response | Incident response owner | SOC, platform owner, identity owner | Legal, privacy, business owner | Executive sponsor | | Policy exceptions | Security owner | Business owner | Legal, privacy, compliance | Executive sponsor | ## RACI by deployment model | Deployment model | Accountable owner | Required co-owners | | ------------------------ | ------------------------ | ------------------------------------------- | | Workforce chat | Platform owner | Identity, data, security, compliance | | Coding agent | Developer platform owner | Security, identity, endpoint, data | | Browser or desktop agent | Endpoint owner | Security, platform, privacy, legal | | Hosted agent | Business owner | Platform, security, data, SOC, IR | | API app | Application owner | Security, developer platform, data, privacy | | Low-code agent builder | Platform owner | Business owner, security, data, compliance | ## Minimum ownership record Every approved AI workflow should have: * Business owner. * Technical platform owner. * Security owner. * Data owner. * Identity owner. * Evidence owner. * Incident owner. * Review date. * Exception owner, if any. Do not approve production use without these names. ## Decision rights Define decision rights in writing: * Security can block a tool or feature that lacks required controls. * Data owners can block use of their data in unapproved AI workflows. * Legal and privacy can require notice, DPIA, impact assessment, or contractual changes. * Platform owners can block unsupported configurations. * Incident response can suspend an AI workflow during investigation. * Executive sponsor can accept residual risk only after control gaps are documented. ## Common AI security ownership and RACI security failures * The AI platform owner enables features but does not own data risk. * Security writes policy but cannot change platform settings. * Procurement approves a vendor without knowing the deployment model. * Business teams publish low-code agents without a named owner. * SOC receives alerts with no runbook or platform contact. * Exceptions are approved in chat and never added to a register. ## AI security ownership and RACI security controls checklist * Assign accountable owners by deployment model. * Assign responsible owners by control domain. * Keep a system-of-record for owners and review dates. * Define who can approve, reject, suspend, and accept risk. * Review ownership after reorganizations, vendor changes, and incidents. * Include ownership in the AI inventory and control matrix. ## Frequently asked questions about AI security ownership and RACI ### Who should own AI security overall? Name one executive who can resolve control gaps and accept or escalate risk. The CISO often fills that role for the security program, while broader enterprise AI governance may be accountable to another executive or committee. Document the boundary and the escalation path. ### Should legal own AI governance? Legal should own legal interpretation and regulatory advice. Security should own technical controls and evidence. The business owner should own the use case and residual business risk. ### Who owns low-code agents built by business users? The platform owner owns the builder controls. The business team owns each published agent. Security owns the approval rules and monitoring requirements. ### Who owns AI incidents? Incident response owns the process. Platform, identity, endpoint, data, legal, privacy, and the business owner support containment, evidence, notification, and recovery. ## Applicable handbook articles These links are limited to control domains for which this RACI assigns an owner, operating responsibility, or decision right. | Handbook area | Applicable articles | Why they apply | | ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | 1. Identity & access |

1.1 SSO & SCIM for AI platforms
1.2 RBAC across AI platforms
1.3 Tenant restrictions: blocking personal accounts
1.5 Agent and non-human identity
1.6 API keys and service accounts governance
1.7 Human-in-the-loop and approval policies

| Assigns accountable and responsible owners for this control domain. | | 2. Connectors, extensions & supply chain |

2.1 Connectors and apps: the integration backbone
2.2 MCP servers: securing the protocol
2.3 MCP gateways and allowlisting
2.4 Analyzing skills for risk
2.5 Plugins and marketplaces
2.6 Hooks and lifecycle scripts
2.7 The supply-chain review workflow
2.9 SaaS agent-building supply-chain
2.10 Hosted-agent framework dependencies

| Assigns accountable and responsible owners for this control domain. | | 3. Runtime, sandboxing & autonomy |

3.2 Approval policies and least-privilege autonomy
3.4 Internet access and browser automation
3.5 Computer Use / desktop control risks
3.8 File and filesystem access controls
3.9 Central hosted-agent runtime hardening

| Assigns accountable and responsible owners for this control domain. | | 4. Data protection |

4.1 DLP for GenAI
4.2 Data classification for AI prompts and outputs
4.4 Retention and Zero Data Retention
4.5 Training opt-out and data usage
4.6 Cross-app data flow and live artifacts
4.7 Secrets and credential hygiene in prompts and tools

| Assigns accountable and responsible owners for this control domain. | | 5. Threats & adversarial testing |

5.5 Red-teaming AI systems
5.6 Incident response for AI systems
5.7 Threat modeling AI systems

| Assigns accountable and responsible owners for this control domain. | | 6. Observability, audit & evidence |

6.1 The audit gap: what you can and can't see
6.3 Compliance APIs by platform
6.5 Routing AI telemetry to your SIEM
6.6 Evidence by surface and investigation paths
6.7 Continuous review cadence

| Assigns accountable and responsible owners for this control domain. | | 7. Rollout & operations | 7.4 The vendor-neutral control matrix | Assigns accountable and responsible owners for this control domain. | ## Further reading The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page. * [NIST AI RMF GOVERN function](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) * [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework) * [Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng), especially Articles 4, 26, and 27 ## Related handbook guidance * [Governance & Frameworks](/reference/governance-and-frameworks) * [7.1 Roll out by risk: the phased plan](/handbook/7.-rollout-and-operations/7.1-roll-out-by-risk-the-phased-plan) * [5.6 Incident response for AI system](/handbook/5.-threats-and-adversarial/5.6-incident-response-for-ai-system) * [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence) * [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) # G.8 ISO/IEC 42001 AI management system How the handbook supports an AI management system certification effort with clause mapping, control ownership, and evidence artifacts. *Last reviewed: August 18, 2026* {% hint style="info" %} ISO/IEC 42001 is a management-system standard for AI. Use it when the organization needs a repeatable AI governance system, not only a set of one-time AI security controls. {% endhint %} ISO/IEC 42001 defines requirements for establishing, implementing, maintaining, and improving an AI management system. It is useful for organizations that develop, provide, or use AI systems and want a formal governance structure around AI risk. The handbook can support an ISO/IEC 42001 effort, but it is not a substitute for the standard. The full ISO text is licensed. Use this page as a preparation map, then validate clause-level requirements against the licensed standard and your certification body. ## What ISO/IEC 42001 adds The handbook is control-focused. It tells security teams what to do for identity, data, runtime, supply chain, threats, evidence, and rollout. ISO/IEC 42001 is management-system focused. It asks whether the organization has a sustained system for AI policy, leadership, planning, support, operation, performance evaluation, and improvement. Together, they should show that: * AI risks are governed at the organization level. * Roles and responsibilities are defined. * AI risks are assessed and treated. * AI controls operate consistently. * Evidence is reviewed. * Failures are corrected. * The program improves over time. ## Control preparation The handbook can help prepare evidence in the following areas. This list is not a substitute for the controls and guidance in the licensed standard. Prepare evidence in these areas: * AI policy and acceptable use. * Roles, responsibilities, and approval rights. * AI system inventory. * Data and model lifecycle controls. * AI impact assessment process. * Human oversight rules. * Third-party and supplier review. * User and affected-party information. * Monitoring and measurement. * Incident response and corrective action. * Review and continual improvement. ## AI impact assessment Use a repeatable AI impact assessment process to support the management system. Scale it to the risk, and confirm the formal requirements against the licensed standard. The assessment should consistently cover: * Intended purpose. * Deployment model. * Users and affected people. * Data classes. * Data sources. * Model or vendor dependencies. * Human oversight. * Possible harms. * Security and privacy controls. * Monitoring and review. * Owner and approval. This can reuse work from EU AI Act fundamental rights impact assessments, DPIAs, threat models, and vendor risk reviews. ## Certification preparation Before pursuing certification, make sure the organization can show: * A defined AI management-system scope. * Leadership-approved AI policy. * AI inventory and risk classification. * Defined owners and responsibilities. * Risk assessment and impact assessment process. * Operational controls for approved AI systems. * Supplier and third-party controls. * Monitoring, measurement, internal audit, and management review. * Corrective-action process. * Evidence that the process runs, not only that it is documented. ## Common ISO/IEC 42001 AI management systems security failures * The organization treats ISO/IEC 42001 as a document project instead of an operating system. * The AI inventory excludes embedded SaaS AI features and low-code agents. * The AI policy exists, but platform settings do not enforce it. * Impact assessments are done only for model development, not deployment context. * Supplier review ignores connectors, plugins, telemetry, and agent runtime. * Internal audit checks policy presence but not control evidence. ## ISO/IEC 42001 AI management systems security controls checklist * Define the AIMS scope. * Build or update the AI inventory. * Approve an AI policy. * Assign owners for all control domains. * Create a repeatable AI risk and impact assessment process. * Map handbook controls to system records. * Keep evidence for control operation. * Review metrics and incidents through management review. * Track corrective actions to closure. ## Frequently asked questions about ISO/IEC 42001 AI management systems ### Is ISO/IEC 42001 only for AI developers? No. Public ISO material describes it as applicable to organizations that develop, provide, or use AI-based products or services. Deployers can use it to govern how AI is adopted and operated. ### Can ISO/IEC 42001 replace NIST AI RMF? They serve different purposes. ISO/IEC 42001 specifies requirements for an AI management system and can be used for certification. NIST AI RMF provides voluntary AI risk-management guidance. An organization can use both, but should document how they fit together. ### Does certification prove every AI system is safe? No. Certification can show that the organization has a management system. It does not prove that every model output, agent action, or business decision is correct or harmless. ### What should security prepare first? Prepare the AI inventory, control matrix, evidence map, incident runbook, and owner register. Those are the pieces that turn management-system language into proof. ## Applicable handbook articles These articles support general AIMS preparation. ISO/IEC 42001 does not make every technical control universally applicable. Select additional handbook controls through the organization's scoped AI risk assessment and treatment process, then validate the selection against the licensed standard. | Handbook area | Applicable articles | AIMS support and example evidence | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1. Identity & access | 1.7 Human-in-the-loop and approval policies | Leadership and operation: defines human oversight and approval authority. Evidence includes role assignments, approval records, and exceptions. | | 2. Connectors, extensions & supply chain | 2.7 The supply-chain review workflow | Operation and third-party control: provides a repeatable review and risk-treatment workflow. Evidence includes intake records, assessments, treatment decisions, and change records. | | 3. Runtime, sandboxing & autonomy | 3.2 Approval policies and least-privilege autonomy | Operation: applies risk-based human oversight to autonomous actions. Evidence includes approval policy, action logs, and override tests. | | 4. Data protection |

4.2 Data classification for AI prompts and outputs
4.6 Cross-app data flow and live artifacts

| Support and operation: documents data classification and traceable cross-system data flows. Evidence includes classification rules, flow maps, approved purposes, and owner decisions. | | 5. Threats & adversarial testing |

5.5 Red-teaming AI systems
5.6 Incident response for AI systems
5.7 Threat modeling AI systems

| Planning, performance evaluation, and improvement: supports risk assessment, testing, incident learning, and corrective action. Evidence includes threat models, test results, incident records, and action tracking. | | 6. Observability, audit & evidence |

6.1 The audit gap: what you can and can't see
6.4 Analytics and usage APIs
6.6 Evidence by surface and investigation paths
6.7 Continuous review cadence

| Performance evaluation and improvement: records measures, evidence gaps, audit paths, and review cadence. Evidence includes metrics, audit samples, management-review records, and corrective actions. | | 7. Rollout & operations |

7.1 Roll out by risk: the phased plan
7.2 Pilot design and success metrics
7.3 The security team checklist
7.4 The vendor-neutral control matrix

| Context, planning, and operation: supports scope, inventory, objectives, rollout gates, and control selection. Evidence includes the scope statement, risk-treatment plan, pilot metrics, readiness record, and control matrix. | ## Further reading The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page. * [ISO/IEC 42001:2023](https://www.iso.org/standard/42001). ISO identifies the current publication as Edition 1, published in December 2023. * [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) * [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework) ## Related handbook guidance * [Governance & Frameworks](/reference/governance-and-frameworks) * [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) * [G.7 Ownership and RACI for AI security](/reference/governance-and-frameworks/g.7-ownership-and-raci-for-ai-security) * [6.7 Continuous review cadence](/handbook/6.-observability-audit-and-evidence/6.7-continuous-review-cadence) * [7.4 The vendor-neutral control matrix](/handbook/7.-rollout-and-operations/7.4-the-vendor-neutral-control-matrix) # G.9 HIPAA controls for AI systems handling PHI HIPAA security and privacy controls for AI systems handling PHI, including BAAs, access, data flows, de-identification, evidence, and incident response. *Last reviewed: August 18, 2026* {% hint style="info" %} HIPAA does not create a separate approval path for AI products. When a covered entity or business associate uses an AI service to create, receive, maintain, or transmit protected health information, the existing Privacy, Security, and Breach Notification Rules follow that data flow. {% endhint %} An AI vendor's claim that a product is "HIPAA compliant" is not enough. HHS does not recognize business-associate self-certification or third-party HIPAA certification. The regulated organization still has to determine its role, confirm that the use or disclosure is permitted, execute the right contract, assess the risks, configure safeguards, and keep evidence. This page is an implementation guide for security teams. Privacy and legal counsel should confirm whether HIPAA applies to the organization, the information, and the specific use. ## Start with scope Answer these questions for each AI workflow before allowing PHI. | Question | Why it matters | Evidence to keep | | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | | Is the organization a covered entity, business associate, or business-associate subcontractor? | HIPAA does not apply to every employer, consumer health app, or organization that handles health-related data. | Written role analysis and responsible privacy owner | | Does the workflow create, receive, maintain, or transmit PHI? | Prompts, uploaded files, retrieved records, transcripts, outputs, embeddings, support logs, and backups can all carry PHI. | End-to-end data-flow diagram and data inventory | | Is the information electronic? | The Security Rule applies to ePHI. The Privacy and Breach Notification Rules also cover PHI in other forms. | Data-format and storage inventory | | Is the use or disclosure permitted? | Treatment, payment, health care operations, authorization, and other Privacy Rule bases have different conditions. | Approved purpose and legal basis | | Is the AI provider acting on behalf of a covered entity or business associate? | A provider that creates, receives, maintains, or transmits PHI on that basis is generally a business associate or subcontractor. | Vendor-role decision and signed BAA where required | | Has the information been de-identified under a HIPAA method? | Removing a name or replacing it with a token does not by itself make data de-identified. | Safe Harbor checklist or documented Expert Determination | | Will AI output become part of a designated record set or another official record? | Access, amendment, accounting, retention, and integrity obligations may follow the resulting record. | Records-management decision and system of record | ## Privacy Rule controls Define the permitted purpose before selecting a tool. Then limit the workflow to that purpose. For uses and disclosures subject to the minimum necessary standard: * Send only the fields needed for the approved task. * Remove unrelated notes, identifiers, attachments, and historical records before submission. * Restrict retrieval and connectors to the approved patient population and record types. * Keep PHI out of personal AI accounts, consumer tiers, and unapproved browser extensions. * Prevent prompts, outputs, and feedback from being reused for model training or unrelated product improvement unless the use is specifically permitted. * Apply the same restrictions to transcripts, telemetry, human review, and support access. The minimum necessary standard has exceptions. It generally does not apply to disclosures to or requests by a health care provider for treatment. Do not turn data minimization into an absolute legal claim. Record the applicable purpose and exception instead. ## Business associate and contract controls The relationship and data flow determine whether an AI provider is a business associate. Buying software alone does not create that relationship when the vendor has no access to PHI. A hosted AI service that processes or stores PHI on behalf of a covered entity or business associate will usually fall on the other side of that line. Before the provider receives PHI, confirm that the BAA applies to the exact product, account, region, features, and support model in use. The contract should address: * Permitted and required uses and disclosures. * Security Rule safeguards for ePHI. * Security-incident and breach reporting. * Subcontractors and downstream model or infrastructure providers. * Return or destruction of PHI when the service ends, where feasible. * Support access, human review, and administrative access. * Retention, deletion, backups, and recovery. * Availability and access to ePHI. * Use of customer data for training, evaluation, abuse monitoring, or product improvement. Encryption, zero-data-retention settings, and a vendor's inability to read the data do not replace the BAA analysis. HHS states that a cloud provider maintaining encrypted ePHI can still be a business associate even when it lacks the decryption key. ## Security Rule controls for AI Include the full AI data path in the HIPAA risk analysis. Do not stop at the visible chat window or API endpoint. Inventory and assess: * Prompts, files, images, audio, and structured records. * Model responses and generated documents. * Retrieval indexes, embeddings, vector stores, and caches. * Conversation history, audit logs, safety logs, and support records. * Connectors to EHR, claims, scheduling, collaboration, and storage systems. * Model providers, hosting providers, subprocessors, and human reviewers. * Backups, disaster recovery, exports, and deletion queues. * Administrative tools, service accounts, API keys, and machine identities. Map the current Security Rule to concrete controls: | Security Rule area | AI implementation | Evidence | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------- | | Risk analysis and risk management | Assess every system that creates, receives, maintains, or transmits ePHI, including vendor and connector dependencies. | Risk assessment, treatment plan, accepted exceptions | | Assigned responsibility and workforce controls | Name the security official, privacy owner, platform owner, and trained users. | RACI, training records, access approvals | | Access management | Use managed identity, role-based access, least privilege, and rapid deprovisioning. | SSO settings, role exports, access reviews | | Audit controls | Record and examine access, configuration changes, exports, connector activity, and administrative actions. | Audit-log samples, SIEM rules, retention settings | | Integrity | Protect ePHI from unauthorized alteration and verify AI-generated information before it changes a clinical or administrative record. | Validation tests, human-review rules, change history | | Person or entity authentication | Authenticate users, services, connectors, and workloads before they reach ePHI. | MFA policy, workload identity, key inventory | | Transmission security | Protect ePHI moving between users, AI services, connectors, and downstream systems. | Encryption configuration and network diagrams | | Security incidents | Detect, contain, investigate, mitigate, and document suspected or known incidents. | Runbook, exercises, incident records | | Contingency planning | Preserve access to ePHI and critical operations during provider outages, corruption, or ransomware. | Backup tests, recovery plan, exit procedure | | Evaluation and documentation | Reassess after model, feature, vendor, architecture, or threat changes and retain required records. | Review history, decision log, current procedures | An "addressable" implementation specification is not optional. If a regulated entity decides that a specification is not reasonable and appropriate, it must document that decision and implement an equivalent measure when reasonable and appropriate. ## De-identification before AI use The Privacy Rule recognizes two methods for de-identifying PHI: * Expert Determination: a qualified expert determines and documents that the risk of identification is very small. * Safe Harbor: specified identifiers are removed and the covered entity has no actual knowledge that the remaining information could identify a person. Do not treat masking, tokenization, pseudonymization, or synthetic-data generation as automatic de-identification. Dates, free text, rare diagnoses, locations, images, and combinations of attributes can identify a person. Keep the determination with the data set, the intended recipient, and the approved use. When only properly de-identified information reaches a provider, the provider is not a business associate solely because it maintains that data. Other privacy, contractual, research, consumer-protection, and security duties may still apply. ## Incident and breach response Route suspected AI disclosures into the existing HIPAA incident process. Examples include PHI entered into an unapproved AI account, an overbroad connector, support access outside the BAA, output shown to the wrong user, or PHI retained after the approved period. The response should: 1. Stop further disclosure without destroying evidence. 2. Preserve prompts, outputs, access logs, configuration, account details, and vendor correspondence. 3. Notify the privacy, security, legal, and incident-response owners. 4. Determine what PHI was involved, who received it, whether it was acquired or viewed, and what mitigation occurred. 5. Document the breach risk assessment or the reason an exception applies. 6. Meet contractual and regulatory notification deadlines. An impermissible use or disclosure is presumed to be a breach unless the regulated entity demonstrates a low probability that PHI was compromised or an exception applies. A business associate must notify the covered entity without unreasonable delay and no later than 60 days after discovery. Contracts should set a much shorter operational deadline so the covered entity has time to investigate and notify affected people. For breaches of unsecured PHI, individual notices are due without unreasonable delay and no later than 60 days after discovery. Notice to HHS is due on the same timeline when 500 or more individuals are affected. Breaches affecting fewer than 500 individuals may be reported to HHS annually, no later than 60 days after the end of the calendar year in which they were discovered. ## Current Security Rule and the proposed update HHS issued proposed Security Rule modifications on December 27, 2024. HHS still describes those changes as proposed and states that the current Security Rule remains in effect while rulemaking continues. Track the proposal, but do not present its requirements as current law. Build controls that can absorb stricter requirements without confusing a proposed safeguard with a binding one. ## Common HIPAA controls for AI systems handling PHI security failures * A vendor has a BAA, but it does not cover the product tier or feature that handles PHI. * The team approves the model provider but misses subprocessors, retrieval stores, logs, and support systems. * Employees paste PHI into personal AI accounts because the enterprise tool is slower. * Zero retention is treated as a substitute for permitted-use analysis and a BAA. * The risk analysis covers confidentiality but ignores output integrity and service availability. * Audit logs exist but do not identify the user, connector, patient context, export, or administrative change. * Names are removed and the remaining free text is incorrectly labeled de-identified. * The incident plan waits for the vendor's 60-day outer deadline. * A model or feature changes materially, but the team does not repeat the risk assessment. ## HIPAA controls for AI systems handling PHI security controls checklist * Confirm the organization's HIPAA role and the workflow's permitted purpose. * Map every place PHI and ePHI enters, moves, persists, or can be viewed. * Approve the exact AI product, account, region, features, and subprocessors. * Execute a BAA before a business associate receives PHI. * Limit data to the approved purpose and apply minimum necessary where required. * Block personal accounts and unapproved AI tools from receiving PHI. * Enforce managed identity, least privilege, connector scoping, and credential controls. * Configure audit, retention, deletion, encryption, backup, and recovery. * Validate output before it changes an official record or drives consequential action. * Test incident evidence collection and notification paths. * Reassess after model, vendor, feature, data-flow, or threat changes. * Keep the approval, risk analysis, contracts, configuration, tests, and reviews together. ## Frequently asked questions about HIPAA controls for AI systems handling PHI ### Can employees put PHI into ChatGPT, Claude, Copilot, or another AI service? Only when the organization has approved the exact service and configuration for that purpose, the use or disclosure is permitted, the correct BAA is in place where required, and the Security Rule safeguards are operating. A BAA alone does not approve every feature or data use. ### Does a vendor's HIPAA certification prove the tool is safe to use? No. HHS states that business associates cannot self-certify or be certified by a third party as HIPAA compliant. Security and privacy teams still need to review the contract, architecture, data flow, configuration, risks, and evidence. ### Does encryption mean the AI vendor is not a business associate? No. HHS cloud guidance says a provider that maintains encrypted ePHI on behalf of a covered entity or business associate can still be a business associate even if it lacks the decryption key. ### Can we use de-identified data without a BAA? If the provider receives and maintains only information de-identified under the Privacy Rule, it is not a business associate solely because it handles that information. Document the de-identification method and consider other laws and contractual duties. ### What should security own? Security should own the technical risk analysis, access controls, logging, connector review, architecture, testing, monitoring, and incident evidence. Privacy and legal should own HIPAA role, permitted-use, minimum-necessary, BAA, de-identification, and notification decisions with the business owner. ## Applicable handbook articles *This table applies only to a covered entity, business associate, or subcontractor using AI to create, receive, maintain, or transmit PHI or ePHI.* HIPAA is technology-neutral. These links identify generic safeguards and AI-specific risk-analysis inputs for a workflow handling PHI or ePHI. Add surface-specific controls when the architecture and risk analysis call for them; a link does not make an implementation a standalone HIPAA requirement. | Handbook area | Applicable articles | Why they apply | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | 1. Identity & access |

1.1 SSO & SCIM for AI platforms
1.2 RBAC across AI platforms
1.3 Tenant restrictions: blocking personal accounts
1.5 Agent and non-human identity
1.6 API keys and service accounts governance
1.7 Human-in-the-loop and approval policies

| Supports HIPAA identity, authentication, least privilege, and workforce access when the workflow handles PHI or ePHI. | | 2. Connectors, extensions & supply chain |

2.1 Connectors and apps: the integration backbone
2.7 The supply-chain review workflow
2.10 Hosted-agent framework dependencies

| Supports HIPAA approved vendors, business-associate review, data paths, and tool authorization when the workflow handles PHI or ePHI. | | 3. Runtime, sandboxing & autonomy |

3.2 Approval policies and least-privilege autonomy
3.3 Network egress control
3.8 File and filesystem access controls
3.9 Central hosted-agent runtime hardening

| Supports HIPAA technical access, integrity, transmission, availability, and audit safeguards when the workflow handles PHI or ePHI. | | 4. Data protection |

4.1 DLP for GenAI
4.2 Data classification for AI prompts and outputs
4.3 Data residency and regional inference
4.4 Retention and Zero Data Retention
4.5 Training opt-out and data usage
4.6 Cross-app data flow and live artifacts
4.7 Secrets and credential hygiene in prompts and tools

| Supports HIPAA PHI identification, minimum-necessary handling, retention, and disclosure controls when the workflow handles PHI or ePHI. | | 5. Threats & adversarial testing |

5.1 Prompt injection: the connective risk
5.2 Data exfiltration via tools and connectors
5.3 Supply chain attacks and notable CVEs
5.6 Incident response for AI systems
5.7 Threat modeling AI systems

| Supports HIPAA risk analysis, safeguard testing, and security-incident response when the workflow handles PHI or ePHI. | | 6. Observability, audit & evidence |

6.1 The audit gap: what you can and can't see
6.3 Compliance APIs by platform
6.5 Routing AI telemetry to your SIEM
6.6 Evidence by surface and investigation paths
6.7 Continuous review cadence

| Supports HIPAA audit controls, activity review, and investigation evidence when the workflow handles PHI or ePHI. | | 7. Rollout & operations | 7.4 The vendor-neutral control matrix | Supports HIPAA risk-based approval, safeguard validation, evidence, and reassessment when the workflow handles PHI or ePHI. | ## Further reading The links below are the primary framework, law, regulator, standards-body, or official maintainer sources used for this page. * [HHS summary of the HIPAA Security Rule](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html) * [HHS minimum necessary guidance](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html) * [HHS guidance on HIPAA and cloud computing](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html) * [HHS business associate contract guidance](https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html) * [HHS business associates FAQs](https://www.hhs.gov/hipaa/for-professionals/faq/business-associates/index.html) * [HHS guidance on de-identification of PHI](https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html) * [HHS HIPAA Breach Notification Rule](https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html) * [HHS HIPAA Security Rule notice of proposed rulemaking](https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html) ## Related handbook guidance * [Governance & Frameworks](/reference/governance-and-frameworks) * [4.2 Data classification for AI prompts and outputs](/handbook/4.-data-protection-and-residency/4.2-data-classification-for-ai-prompts-and-outputs) * [4.3 Data residency and regional inference](/handbook/4.-data-protection-and-residency/4.3-data-residency-and-regional-inference) * [4.4 Retention and Zero Data Retention](/handbook/4.-data-protection-and-residency/4.4-retention-and-zero-data-retention) * [6.6 Evidence by surface and investigation paths](/handbook/6.-observability-audit-and-evidence/6.6-evidence-by-surface-and-investigation-paths)